A second, independent application of the Architecture Ladder — this time to a component that does not exist yet.
The first case study used the ladder to evaluate replacing a working system. This one uses it to evaluate building one: a state machine that sequences long-running care programmes, proposed as a design document, with no implementation and no incumbent.
The interesting result is methodological. Sixteen of the seventeen rungs need no channel, no person, and no language model. The whole ladder runs offline, deterministically, in under a second. That is not a shortcut around the hypothesis — the design's central claim is that the component knows nothing about the outside world, so being able to fake the outside world completely is itself evidence for the claim, and there is a mechanical test for it.
A care-coordination platform runs multi-step sequences of interactions with a person over a messaging channel: a welcome sequence, a structured intake, a recurring wellbeing check-in, an emergency-information collection flow. Call each one a Loop.
The platform runs any single step well. What it cannot do is hold the thought:
"This person is in the wellbeing Loop, on its fourth occurrence, and their answer decides whether the emergency-information Loop starts next."
No object anywhere represents a Loop, in progress, for one person. So every cross-step decision — chain, branch, eligibility, trend, on-demand trigger — has no home, and each one gets hard-wired separately.
A design exists for the missing engine. It promises to stay small: "it is thin", "it is the conductor, not the instruments", "resist turning it into a general workflow engine."
Every workflow engine ever built started with a sentence like that. Most did not keep it.
The connecting logic of every pilot care Loop can be expressed as data, in a vocabulary of at most eight task types and at most ten operators, such that adding a new Loop costs one row and no code.
That can be wrong, which is the point of phrasing it that way. You can go and count.
The design can fail in two opposite directions, and the interesting thing is that both feel reasonable while they are happening:
| The language is too weak | The language is strong enough | |
|---|---|---|
| What happens | Each awkward Loop gets a small bespoke function, and the declaration becomes a decorative wrapper around code that was written anyway | It absorbs every case by growing, until it is a programming language stored in a JSON column with no type checker, no debugger and no stack trace |
| What it feels like | Pragmatic. "Just this one Loop needs a hook." | Elegant. "Look, it can express anything." |
| Which number catches it | Loop cost | Operator count |
The ladder has a hard ceiling on the operator count, declared before any rung runs, so it cannot be moved later to accommodate a result.
The instrument is different, and had to be. The first case study measured control paths against capability surface — the right split for a request router. That split does not apply here. This ladder measures two growth axes (the cost of a new Loop, and the cost of a new kind of step) against two containment metrics (how large the condition vocabulary grew, and how many surprising rules correctness cost). Redesigning the five numbers per domain is part of the method, not a deviation from it.
It runs entirely on paper. Time is an injected parameter, so ninety simulated days of a recurring programme execute in under a millisecond and the regression suite is a byte-diff of deterministic traces. The person is a scripted file that says what they answer, how late, and when they stay silent. There is no model in the core at all — an orchestrator that made non-deterministic decisions could not be regression-tested by trace diffing, and trace diffing is the whole instrument.
The overshoot is three rungs, not one. METHOD.md §6 requires climbing one rung past the north star, into a capability the design was never drawn for. Here the north star is followed by three, because three real requests arrived from outside the design and they vary different things, owned by different people, with different lifetimes. They are stated in full before the climb starts.
One of them tests a boundary rather than a mechanism. Deployments delegate clinical judgement to the platform — that is why they are customers. So the condition-specific part of care is centrally authored, and condition variants are counted per clinical module, not per deployment. Whether that boundary holds under pressure is a sharper question than whether a grid stays small, and it produces a sharper measurement: the number of definition fields that two variation axes both want to write. Zero means they compose by construction.
| File | What it holds |
|---|---|
| case-study/01-the-problem.md | The control-surface analysis: three levers, three worked change requests, the two failure modes, and four honest reasons not to over-read a good result. |
| case-study/02-the-ladder.md | Seventeen rungs, the offline simulation design, the gates, and the kill criteria. |
The method itself is not repeated here. It lives in mkvakin/architecture-ladder, and this repository is an application of it.
Specified, not climbed. As with the first case study, that ordering is deliberate: the test, its gates, the operator ceiling, the overshoot capabilities, and the conditions under which the design would be abandoned are all fixed before any result exists.
A negative result here is a successful use of the method, and it selects a real alternative that is already drafted: write by hand the two or three cross-step transitions the pilot actually needs, skip the engine, and have one place to look instead of two.
The case study is anonymized. Organizational and partner identifiers, file and symbol names, internal defect and feature identifiers, the clinical domain, vendor configuration, and unpatched failure modes have been removed or generalized. The quantities are real.