Showing which parts of a build carry no decision yet

A design document cannot show the difference between a decision, a proposal, and something nobody has considered. All three look the same on the page, and only one of them is a problem. The build is a sales process with many interdependent automations, reshaped repeatedly as real records tested it. Every adjustment risked rework elsewhere, […]

A design document cannot show the difference between a decision, a proposal, and something nobody has considered. All three look the same on the page, and only one of them is a problem.

  • The build is a sales process with many interdependent automations, reshaped repeatedly as real records tested it. Every adjustment risked rework elsewhere, and the person directing it needed to see the current state rather than read it.
  • The map stacks horizontal lanes across one shared axis, so a column means the same thing in every lane. Reading down a column shows the step, what it spawns, how it can be interrupted and where it can exit. A missing exit then appears as a blank run across the lanes instead of a paragraph someone has to notice.
  • Every cell carries two codings: who decided it, and whether the fact was read from the live system or asserted in a document. Cells are addressed by a stable key rather than a position, because positions renumber whenever a step is inserted and quietly invalidate every reference written before.
  • The diagram is generated from a data file, and a script runs each cell's claim against the live system. A cell that claims to be live without an executable check is reported as malformed. That check has already corrected a figure which had been stated twice in prose.