Ulitsojeus
Decision systems
The decision log that survives a reorg
A decision log dies when it stores people instead of calls. This note describes a six-field row that a stranger can still read after the team is split, renamed or absorbed.
The problem
The first log I kept in 2026 looked complete. It had a title, a date, a link to a slide deck and a column labelled owner. Two months later the team was reorganized. The owner column pointed at mailboxes that no longer existed. The slide links still opened, but they opened a narrative about alignment, not a record of the call. When a neighbouring team asked why a vendor had been kept, nobody could reconstruct the options that had been on the table. The log had become a graveyard of names.
The failure was not a lack of diligence. People had filled the rows. The failure was the unit of storage. A log that stores “who was in the room” is a meeting minutes file. A log that stores “what was decided, against which options, under which constraint, and when it must be looked at again” is a decision system. After a reorg you still have roles. You do not still have the same sitting arrangement. If the row cannot be read without the original circle, it will not survive the first org-chart change.
This note is the structure that replaced that file. It has been used on intake calls, vendor keep-or-cut calls and scope cuts. It is not a culture speech. It is a row definition, a filling rule and a list of places the row still fails. If you need a template you can hand to a team, that file sits in the Library. The argument for the fields stays here.
The structure
- Write the decision as one sentence before you open a table. The sentence names the call, not the meeting. “Keep vendor A for search in Q2” is a decision. “Align on search tooling” is a meeting title. If you cannot write the sentence, you do not yet have a row. Capture the raw words from the room first — the Four-Pass Method calls this Capture — and only then frame the sentence. Early paraphrase is how a log inherits the slide title instead of the call.
- Store options as a short list, including the option that was not chosen. A log that only records the winner teaches nothing after the people who remember the loser have left. Two or three options is enough. Each option is a noun phrase plus one constraint it would have accepted. “Build in-house — accepts a six-week delay” is an option. “Do nothing” is a valid option and should appear more often than it does. If the list has one item, you held a briefing, not a decision.
- Record the constraint that actually bound the call. Time, money, a policy, a dependency, a legal limit. Pick the one that, if it had been different, would have changed the winner. Multiple constraints can be true; only one is usually binding. Teams like to list every pressure because it feels complete. Completeness here is a way to hide the trade-off. After a reorg, the new reader needs the binding constraint, not a mood board of pressures.
- Assign fields to roles, never to given names. The row has a requester role, a facilitator role, an owner role and a reviewer role. People occupy roles; roles occupy the log. When the org chart moves, you update a roster, not fifty historical rows. If a company insists on a name for audit, put it in a side column that is not required to understand the call. The public-facing row stays role-based so a stranger can still read it.
- Put a revisit trigger on every row that has a horizon past two weeks. A trigger is a date or a condition: “15 Apr 2026” or “when error rate crosses 4%”. Without a trigger the decision pretends to be permanent, which is how logs fill with zombies. The two-week horizon rule in a later note is the same idea in shorter form. If the call only matters inside fourteen days, the trigger can be “none — expires with the sprint”. Write that. Silence is not an expiry policy.
The fields
Six fields. If a seventh is tempting, it usually belongs in the source ticket, not in the log. Example entries are invented for the table; they are not a client story.
| Field | Why it exists | Example entry | Who fills it |
|---|---|---|---|
| Decision ID | A stable handle after titles change. | DEC-2026-014 | Facilitator role |
| Decision sentence | The call, in one line, with no meeting verb. | Keep the current search vendor through 30 Jun 2026. | Owner role |
| Options considered | Shows the loser, so the row teaches after the room is gone. | Keep vendor; switch in Q2; freeze new queries. | Requester role |
| Binding constraint | Names the pressure that, if changed, would flip the winner. | Migration window closed until July change freeze. | Owner role |
| Rationale (four lines max) | Records the argument, not the vibe of the meeting. | Switch cost sits past the freeze; freeze option blocks a launch. | Facilitator role |
| Revisit trigger | Stops the row from pretending the call is eternal. | 01 May 2026 or p95 query time above 800 ms. | Reviewer role |
Where it breaks
It breaks when the owner role is vacant and the facilitator fills the sentence anyway. The row looks complete and nobody is bound to the revisit trigger. After the next reorg the trigger is an orphan. The counter is mechanical: a row without an owner role cannot be marked decided. It stays in “framed” and does not enter the weekly four-column review as a decision.
It breaks when options are written as slogans (“innovate”, “be bold”, “stay lean”). Those are not options; they are tones. A later reader cannot tell what was refused. The test is whether each option could be handed to a different team as a brief. If it cannot, rewrite the option list before you record a winner. This is the usual place Test fails in the Four-Pass Method.
It breaks in programmes that want one log for twelve workstreams. The table then grows columns for every local exception and the stranger test fails. Split the log by decision type, not by org chart: intake, vendor, scope. Cross-links are cheap. A universal row that pleases every workstream is how the first log died. The method does not scale by adding columns.
Template
The Library file is a blank six-column table plus a one-page prompt sheet for the facilitator role. It includes the role roster, the “framed / decided / expired” states, and the rule that a seventh column must be argued in writing before it is added. The public note is enough to rebuild the table by hand; the file is there so a team does not spend a week redesigning the headers.
Related notes
- A metric tree you can actually defend — the measurement counterpart; a log without a tree still guesses at outcomes.
- Scoring intake requests without a committee — uses the same role rule on inbound work.
- The two-week horizon rule — the trigger policy in shorter form.