Manual sections
The Same Room
Many doors, one room.
Every door opens into the same room.
Many doors, one room.
- Where ambiguity gets in
- Structure: entry points that disagree
- In the tunnel
- Every entrance leads into the same tunnel
- Enforced by
- Headless components
The principle
A process can be started from many places. Whichever door starts it, it ends in the same state, with the same records, meaning and obligations. The work behind the doors is split into components, and each one leaves the process valid, never half-done. Many doors, one room.
The Tunnel is the operating model: how work is done. The Same Room is that mindset applied to systems engineering: how the platforms, integrations and AI that carry the work are built.
What it asks of a design
- Split the process into components that can run alone. Each has one job, and none needs a particular user interface to do it. That is Headless-First: the component is the capability, and every screen, API or schedule is only a way in.
- Define the room first. Before building any entry point, write down what exists when the process has run: which records, which relationships, which facts.
- Every door must produce that room. An entry point may gather its inputs differently: a form, an API call, a schedule, a file on disk. It may not produce a different outcome.
- No component leaves the process half-done. Running any one component alone leaves the process valid. Valid is not the same as complete. If a component cannot leave the process valid, it is not a component; it is a fragment of another one.
- The scope is declared."Same start, same end" holds within the boundary you define, not across the organisation. Name that boundary.
The test
For any action that can start from more than one place, ask:
If you start this from door A and again from door B, can anyone tell afterwards which door was used?
What a second room looks like
- The same noun, created empty from one door and populated from the others.
- A record that exists without the evidence every other path gives it.
- An action embedded in another domain's screen, reachable only there, and behaving slightly differently there.
- A shortcut that skips a step the other doors perform. It usually looks like convenience.
- A fallback that is usually right. It passes every check until the one case where the door matters.
A worked example
In PreviouslyUpcoming, a context is where work gets filed. Contexts came into being through four doors:
| Door | The room it produced |
|---|---|
| A push from a repository | A context, with a session and a remote |
| An answered call | A context, with the call filed in it |
| An attached transcript | A context, with the meeting filed in it |
| A name typed on a to-do | A context, with nothing in it |
The fourth door opened into a different room. The fix was not to validate the fourth door harder. It was to recognise that creating a context does not belong in the to-do domain at all. A to-do points at work, and a context is created by work. The one legitimate early door, registering a repository by its remote, moved to the contexts page, because a remote is evidence of the same kind the other doors bring.
Where it comes from
- Systems thinking from integration work. An integration is only correct if it holds end to end, whichever system initiates.
- Headless-First. Components that run without a surface are the precondition for doors being interchangeable.