A discovery engagement produces more paper than software. The pattern here is what happens to that paper: one table becomes the single source of truth, and everything else is either evidence or generated from it.
A note on the example before we start. The technique here is real and came out of real engagements. The client it came from is not something I can publish, and a thinly disguised version would only invite the actual firm to read itself into it, so the worked example below is Moreton Fiduciary, which is fiction: it belongs to this blog’s Casebook, where the same engagement is told as a story. The Highlighter and the Death Notices is the fortnight of storming that produced the walls, and One Table, One Row Per Card is the fold itself from the other side of the room. The domain is rebuilt to match. The technique is not.
Moreton administers deceased estates. It holds the wills, applies to the court for probate, collects the assets, pays the debts, distributes what’s left, and closes the file. Sixty-one people, a fire safe of about four thousand wills, and at the far end of several flows a probate registry and a births-deaths-and-marriages web shop with no purchasing interface a computer could use, so a person sits and buys the certificate like anyone buying a jumper.
The domain has a genuinely strange shape in places. Of eleven hundred open estates, four hundred and thirty were waiting on a grant of probate: not slow, not backlogged, but frozen by law until a court said otherwise, some of them for five months. You cannot touch a dead person’s money until a court says you can. The files wait for the paperwork to catch up.
Two weeks of event storming, run the way the Big Picture and Process Level playbooks describe, produced what those sessions always produce: walls. Photographs of walls. Transcripts of the conversations in front of the walls. And the familiar question of what happens next, because the default answer is a wiki page per session, each one a snapshot of what one room believed on one afternoon, all of them quietly diverging from each other and from reality. That’s the moment discovery work usually starts to die.
This time everything folded into one document instead. One table. It ran the whole engagement, and it’s the most reusable thing I took away.
One table, one row per card
The table holds the entire domain in one sequence. Every sticky note from every storm becomes one row, in timeline order. Reading top to bottom walks the whole business, from “a name in the death notices” to “the file is closed”, and the happy path needs no arrows or annotations: it is simply the next row. Branches, edge cases, and open questions sit in place, right where they belong in the flow, rather than in an appendix.
The columns: ID · Section · Type · Name · Actor · Caused by · Data · Notes · Causes. Causation reads left to right: who acted, what came before this card, what it consulted, what it leads to. Type is just the storm colour, and every reference to another card carries its colour square, so a row reads the way the wall reads:
| ID | Section | Type | Name | Actor | Caused by | Data | Notes | Causes |
|---|---|---|---|---|---|---|---|---|
| C014 | Probate | 🟦 | Lodge probate application | 🟨 Y003 | 🟪 P009 | 🟩 D002 | deceased, will, asset schedule | 🟧 E021 |
| E021 | Probate | 🟧 | Application Lodged 📍 | 🟦 C014 | pivotal: the court now has it | 🟪 P011 | ||
| P011 | Probate | 🟪 | Grant issued or requisitioned? | 🟨 Y005 | 🟧 E021 | 🟩 D004 | ||
| ↳ | grant issued | 🟦 C016 | ||||||
| ↳ | requisitioned | back to the firm to answer | 🟦 C017 | |||||
| C017 | Probate | 🟦 | Draft requisition response | 🟨 | 🟪 P011 | 🟧 E024 | ||
| H009 | Probate | 🟥 | Who drafts it? | 🟦 C017 | officers say the lawyer; the lawyer says the officers |
Six conventions are visible in that excerpt.
Addresses that can’t go stale
Every card gets an ID when it’s created: a letter for the type (E for events, C for commands, P for policies, D for data, H for open questions, Y for actors) and the next number from a counter that only ever goes up. The identifiers are global across the whole domain rather than per-storm, because the storms flow into each other and make up one domain.
The ID is coined once and never changes. The obvious alternative is to renumber positionally, so the numbers read in order down the page. Renumbering breaks the one job the ID has. An email from last month citing 🟧 E021 doesn’t come back as an error when the card it meant became E024; it comes back pointing confidently at a different card. Nothing in the document can detect that, because the reference is out in someone’s inbox.
So: numbers are never reused, a deleted card’s number stays retired, and an insert in the middle of the timeline takes the next number off the counter rather than the next number on the page. Sequence lives in the row order, which is free to change; the ID says only which card. A script checks the invariants after every edit: IDs unique, none reused, every reference pointing at a card that exists.
The cost is that after a few rearrangements the IDs no longer read in order top to bottom, which looks untidy and briefly bothers everyone. The payoff is the thing that matters: “🟧 E021” is citable in a meeting, in a commit message, in an email to the client, and it still means the same card a year later, when the wall around it has been rebuilt twice.
The grammar is a machine’s job
Event storm walls obey a grammar, the one set out in the Process Level playbook: actors issue commands; commands cause events, past tense, one event per card, named specifically enough to identify alone on a wall of a hundred; events trigger policies; policies decide commands and consult data. In the room, the facilitator enforces this by walking over and asking questions. In the table, a script enforces it, mechanically, after every edit.
Events never cause events. Commands never cause commands. Actors never cause events directly; they act through commands. And a policy is consulted because of an event rather than caused by one. That distinction does more work than it looks like it should.
It removes two exceptions I used to carry. “Every night at six” isn’t a policy at all: something is acting on a schedule, so it models as an actor, 🟨 Cron, issuing a command exactly the way a person does. “Only proceed when all three are done” isn’t an exception either; it’s an ordinary policy consulting a 🟩 data card to find out whether all three are done. Both had been sitting in the grammar as tolerated variants. Every variant is one more case the script has to be told to ignore, and a grammar full of those stops catching anything.
And the rule that does the most work: a policy exists only where a real decision is made. One event leading to one command with no condition between them is just a command; writing a policy card there is ceremony. Purple belongs where the flow could genuinely go two ways, or where something has to be checked before the next command goes out: a 🟩 data card consulted, a state confirmed, a threshold tested. P011 above is the first kind: granted one way, pending the other. The “all three are done” gate is the second. It shows no branch on the wall, but it reads something before it lets the work through, and that read is the decision.
The point of machine enforcement isn’t purity. Every grammar violation is a missing card. An event that appears to cause an event means somebody, or some rule, in between hasn’t been named. A command with no issuer means the room never said who does this. The script doesn’t fix these; it points, and each one becomes a proposed card plus a question. Which brings us to the reds.
Nothing is ever blank
The table has a rule: no cell that should have content is ever empty. An unknown actor is a bare 🟨 square. Unknown data is a bare 🟩. A rule everyone senses but nobody has stated is a 🟪 marked (proposed). An outcome nobody could name is a ?. Look at row C017 above: somebody adds the job to the waiting room, and nobody in three sessions could say who, so the actor cell holds a bare yellow square rather than a guess or a blank.
And every one of those placeholders gets a 🟥 row directly beneath the card it questions, stating the question. That’s H009 in the excerpt.
There is no separate questions register. The reds are the register, held in place, each question physically beside its impact. A questions list in its own document goes stale the way all satellite documents go stale, and it strips the context off every entry; a red row under C017 needs no explanation about what it refers to. When a question is answered, the red comes off and a dated note goes onto the card it questioned, so the answer’s provenance survives.
The red count is the progress measure, by design rather than by accident. The directors asked how discovery was going. The red count answered them, and it told me where the next session needed to focus and how close we were to understanding the domain well enough to start building. It was 143 after the first fold, 61 when the workshops wound down. A number that only goes down when a real person answers a real question is a far more honest progress measure than a percentage on a slide, and it gave the client a reason to chase answers between sessions, because their number moved when they did.
Seams
The domain ends up looking like a state machine of state machines: a dozen flows, each with its own states, handing off to each other. Every handoff in the table follows one pattern: an event in the upstream flow lands in a queue, and the downstream flow starts with an admission policy that reads the queue. Probate emits 🟧 Grant Issued; the estate lands in the collection queue; the collection flow’s first card is a policy deciding which institution to write to first.
The queue is a green card, a read model. A queue between two flows is data one side writes and the other side consults, which is exactly what a green is. Moreton’s whole operation turned out to be a chain of pools: the grant-wait pool, the collection queue, the ready-to-distribute pool, the queues in front of each institution. Ask an estates officer what they do all day and they tell you they wait on other organisations, which is another way of saying they watch pools drain and fill.
Collecting every seam into a small table of its own (upstream event, carrying queue, downstream policy) produced the integration contract list for free. When the build starts, those seams are the published events between modules, and the seams table is the list a team argues about instead of discovering the arguments one integration at a time.
Aggregates arrive late on purpose
Nobody storms an aggregate, the same way nobody in an event storm says “bounded context”. What happens instead is that greens accumulate at decision points. The same cluster of facts (the deceased’s identity, the will and any codicils, the asset schedule, the beneficiary list) kept being consulted by policy after policy, under different casual names. That recurring green cluster is the aggregate.
So the sequence is: storm the flow, let the greens pile up where decisions get made, cluster them afterwards, and then run an Example Mapping session on the definition, because “what exactly is a site record?” is a rules question, and concrete examples settle rules questions better than definition debates do.
Everything else is generated
The table is the source of truth, and it’s a wide markdown table, which is a poor thing to project in a workshop. So a script generates the wall from it: a portrait canvas, one card per row, timeline running top to bottom the way the table reads, commands in one lane, events on the line, data and reds in side lanes beside their subject, sections stacked as bands. Where a link would stretch across metres of wall, it becomes a seam marker instead: “→ E057” at the source and “⇢ from E038” at the destination. Scroll the wall and you’re reading the table; edit the table and the next scroll shows the edit.
The status report is generated from the same documents by one command. Later the C1 and C2 diagrams (the C4 ramp) are generated from structured data too.
Nothing hand-drawn survives contact with an engagement that changes daily. A hand-edited diagram is wrong within a week, and a diagram known to be sometimes-wrong is worse than no diagram, because people stop checking. Hand-edited diagrams are how documentation dies. Generate the views, regenerate after every fold, and the pretty artefacts stay exactly as current as the truth they’re drawn from.
The ramp to build
Discovery that doesn’t reach the code is theatre, and the table is built to feed the ramp.
The names get ratified first: the glossary of terms the domain branches on goes back to the room, and the room’s words win. Then the bounded contexts fall out of the model rather than the org chart: a context is a stretch of the table that owns its data, speaks its own language, and moves at its own pace, with the seams table already saying what crosses between them. That’s the same test Drawing the Boundaries applies, arrived at from a table instead of a whiteboard.
The decisions that will be expensive to reverse become ADRs while the reasoning is fresh. The one I enjoyed writing most applied the ledger test from Event Sourcing the Ledger context by context: source events where history is the product and the record must be defended years later (the estate ledger, every dollar in and out, which a beneficiary or a court may want walked through years afterwards; the oversight register, where “how long has this sat and who owned it” is the question being asked), and state with published events everywhere else, so two contexts carry the machinery and the rest stay boring.
Then C1 and C2, generated. Then the Musts get story-mapped under the pivotal events, the backbone a story map needs having already been marked 📍 in the table. Each story gets example-mapped, the examples become Gherkin, and the double loop takes it from there, starting with a walking skeleton through the riskiest seam.
Every step of that ramp consumes the table. Nothing gets re-elicited, and nobody opens a blank page.
The table also changed how the workshops themselves ran: projecting the generated wall and auditing it with the room turned out to be a session format of its own. The Workshop: Walking the Wall is the playbook. Publishing in a wiki or on a digital whiteboard has problems of its own, and those get their own exploration in Living Documentation.