The Situation Room

Decisions aren't won in the doc. They're won in the room. The Situation Room maps the people behind any decision and shows you how to move them. The political layer, finally made visible.

Comment

Inspiration

Everyone who's worked inside an organization has lost a decision they were right about. Not because the work was wrong, but because the room wasn't mapped. The real blocker is rarely the plan; it's the VP who feels threatened, the peer who needs to be asked before they're told, the quiet stakeholder whose silence reads as agreement until it isn't. That work happens in people's heads and scattered DMs. I wanted a private place to make it explicit. A war room for the decisions that actually matter.

What it does

The Situation Room turns plain notes about any decision into a structured map of the people behind it, then helps you plan how to move them. You write naturally: "Priya owns the budget but she's lukewarm" — and the system extracts the structure. Three lenses read the same room differently:

  • People: who's involved and where they stand
  • Grid: power vs. interest, so you spend energy where it counts
  • Network: who influences whom

It's command-first by design: @note, @grid, @network, @map. Not a chatbot. A tool with intent.

How I built it

Solo, on Firebase (Auth, Firestore, Hosting, and Functions )with a React single-page app on the front end. The intelligence is a constrained, multi-role LLM pipeline running server-side through a Firebase Function. Instead of one model doing everything, the work is split across specialised roles and dispatched as a sequenced state machine. No free-form model-to-model loops:

  • Controller owns intent and the user-facing voice.
  • Mapper is an English specialist: it transcribes prose into a strict structured-update contract. People, stances, and relationships.
  • Strategist is the topic specialist: it grounds every placement in established frameworks — Mendelow's power/interest grid, SCARF, Thomas-Kilmann.

Splitting the roles keeps each prompt small, cheap, and testable, and stops the model from inventing structure it wasn't asked for. Reliability comes from the architecture, not from throwing a bigger model at it.

Challenges I ran into

The hard part was reliability, not features. Getting the Mapper to act on clear intent instead of bouncing clarifying questions took a dedicated extraction effort. Privacy shaped the architecture from the start: users write notes about real colleagues, so raw traces are off by default and analytics carry no names or note content. And I held the line on scope. No fourth lens, no personality quizzes, no generic chat.

What I learned

Constraint is a feature. The command-first surface and the deliberate refusal to become open-ended chat are exactly what make the product trustworthy with sensitive material. The ambition showed up in the discipline, not the surface area.

What's next

Overall: Work on traction to gather as much user feedback and data analytics as possible. On precision/reliability: open-ended coaching grounded in the mapped room, an eval flywheel built from production traces, and per-user learning.

Built With

  • and-functions-?-with-a-react-single-page-app-on-the-front-end.-the-intelligence-is-a-**constrained-llm-relay**-running-through-a-firebase-function:-one-role-transcribes-prose-into-a-strict-structured-update-contract
  • another-grounds-placements-in-established-frameworks-?-mendelow's-power/interest-grid
  • anthropic
  • api
  • auth
  • claude
  • firebase
  • firestore
  • functions
  • haiku
  • hosting
  • javascript
  • llm-pipeline
  • multi-role
  • not-free-form-model-loops
  • novus.ai
  • on-firebase-?-auth
  • pendo
  • react
  • scarf
  • thomas-kilmann.-dispatch-is-a-sequenced-state-machine
Share this project:

Updates