Map Your Case: The Grant–Mandate Delta, Mapped By Its Owner
The dev pack for Map Your Case, written after the thing it specifies: v1 shipped on 20 August, the project lead's corrections arrived within hours, v2 shipped the next day — so half of this pack is capture (the thirteen principles, the library, the model and the architecture as built, with their reasons) and half is specification, expanded in documents first so v3 is built from pages rather than memory. Two v0.33.61 programme briefs land here as first-class documents: levels and variants as two axes — five scenarios ordered by grant size, everybody starts at level one, and the three sets whose third row (held and never used) is the product — and the synthetic-reader tabletop, where the screenshot boundary is the instrument, the patience budget comes from outside the model, and the two 9 August simulation rules are carried verbatim. Document 12 is the extra one a hindsight pack owes: what v1 got wrong, the six bugs that became principles, and what was verified before each ship — the receipts behind every rule the pack states.
The documents
| Document | Role |
|---|---|
| 00 — The leading brief | What the tool is, the inherited vocabulary, five positions on one axis, and the concession made first |
| 01 — Principles | Thirteen invariants, each with its reason and the check that would catch a violation |
| 02 — The library | The single data file: what it holds, the rules its entries obey, and why the honesty lives here rather than in the code |
| 03 — The model | Choices to delta in six stages — and the three places the obvious implementation is wrong |
| 04 — Architecture | Web components without shadow DOM, one state owner, and storage that treats its own absence as a case |
| 05 — Workflows and user stories | Five users, twenty stories with tests that can fail, seven workflows, and the honest feature column |
| 06 — The screens | The page in order, the rendering rules, the load-bearing strings, and the four v3 screens |
| 07 — Levels and variants | The explanation programme: a grid not a ladder, five grant-ordered scenarios, the three sets, and the stopping rule |
| 08 — Synthetic readers | The tabletop: pixels only, fixed artefacts, exogenous budgets, defects not preferences — and the two rules kept verbatim |
| 09 — Sharing | The fragment as the channel, identifiers as the payload, and the drift a pinned version makes sayable |
| 10 — Wardley maps | Four maps: the scarce components are all editorial, none mechanical |
| 11 — Build order | Five phases; documents before code; tabletop before build; every definition of done a run or a check |
| 12 — The first MVP | v1 and v2 as they actually happened: the corrections, the six bugs that became principles, and the verification discipline |
| Appendix — Change control | Four corrections, eighteen decisions, and the relationship to the sibling register where the tool grew up |
Below the pack: the synthetic readers
The pack is an argument about a tool. The readers area is the instrument that tests it — and it sits outside the pack on purpose, because it feeds the pack rather than belonging to it, and because its output is simulated material that must never be shelved beside the documents it tested as though it were the same kind of thing.
Two agents: one is a browser and nothing else; one is an archetype that receives pixels and nothing else — no page text, no structure, no source, no knowledge of the project — and points spatially at where to go next. Patience is set from outside the model, so abandonment is a measured event rather than a story the model tells about itself. One run has been performed and its findings are already in change control as MC5–MC9.
| Where | What it holds |
|---|---|
| The readers area | The programme, the run index, the schedule of what has not been run, and the findings so far |
| The three archetypes | The shipping founder, the agent-security practitioner, the adoption executive — property lists, not portraits |
| The fixed instruments | The elevator pitch, and the expectation, comprehension and closing questions — fixed wording, all four |
| Simulated run 001 | Six screens, verbatim reactions, the budget ledger, seven findings — and a pre-registered prediction that turned out wrong |
| Run 001 — informed analysis | The type B pass: the same run read by an agent that has read the pack |
Why it is on this site
This pack owns the first thing on this site that is built: the workflow at /assess, which the registry MVP pack describes from the outside as its document 14 and its one shipped consumer. Its constraints are the site's published positions — grant is not mandate, the three-tier control test, store the choices, not the answers — and its two programme documents operationalise the levels-and-variants brief and the screenshot-boundary brief, both captured verbatim under documents.