Login screen to persona-complete MVP, in the order it gets built.
ADR-018 records the through-line for UI development on the “shell out, fill in” principle: start with the smallest piece of recognizable software, then progressively fill in operational depth. Each step preserves the work of prior steps. Each step advances the demo answer to a different question.
Three pressures converge to make sequencing a decision worth recording: Matt joining the team needs design targets, the workflow engine is large and blocks most operational UI, and Ryan reads a working demo more reliably than a planning document. The arc has to answer all three.
The principle has two halves. Shell out means the earliest steps put recognizable software in front of a stakeholder: a login screen, a list, a navigation pattern. Nothing differentiating, but tangibly real. Fill in means each subsequent step adds operational depth to the same shell — intake forms, custody display, the workflow engine, document gates, persona-specific surfaces — without throwing the prior work away.
“Each step preserves the work of prior steps rather than replacing it. Each step advances the demo answer to a different question Ryan or a prospective customer would ask.”
The midpoint of the arc is the workflow engine. The three steps before it ground the team in Kearney’s actual paperwork. The four steps after it deliver persona-specific surfaces in deliberate sequence, each consuming engine data the prior steps could not have produced.
Steps grouped by what each one lands. Step 4 is the architectural reveal — the workflow engine — and sits at the midpoint by design. Step 3.5 is the smallest step on the chart, inserted to give Margaret a calendar view before the engine begins writing scheduled events.
Each card names the build, the demo question Ryan can answer after it ships, and the dependencies that block it. Steps 1 through 6 use Ryan-as-audience as the exit criterion; from Step 7 onwards, persona-specific surfaces are additionally reviewed with the corresponding Kearney staff member.
—
Forms registry complete and analysed against the eventual workflow catalogue. Persona interviews conducted with each of the five Kearney personas. Matt onboarded through B1–B5. Design system v0 in place — tokens and primitives, not finished components.
Nothing user-facing ships at Step 0. The deliverables are inputs to every step that follows: Step 2 needs the forms registry, Step 4 needs forms-vs-engine analysis, Steps 7–10 need persona interviews.
Is this real software?
The existing scaffold re-skinned against design system v0. No new functional capability — just a recognizable application: log in, see your cases, click into one.
The point of Step 1 is to make every subsequent demo feel like progress on a real product rather than a series of experiments.
Can someone actually take a first call?
The intake form modelled on Kearney’s first-call sheet from the forms registry. The structure of the form, the field names, the required-vs-optional split — all grounded in the paper instrument Kearney actually uses today.
This is the first step where a Kearney staff member could plausibly perform an operational task on the platform.
Is the case interactive after intake?
Edit deceased and family-member records on an open case. Display the custody timeline as a read surface. Allow manual creation of custody events — not via QR scans yet, but via the underlying API.
The custody timeline appears here as a display surface ahead of Step 6 wiring it to real scans. Reading and writing custody events at this step exercises the data shape Step 6 will activate.
Can Margaret see what the business is doing this week?
Calendar view (week and month) plus manual event creation scoped to admin and director roles, plus an event detail view. No resource assignment, no conflict detection, no staff-availability overlay.
Step 3.5 exists because Margaret will not perceive RequiemOS as a complete product without a calendar view of operations, and the workflow engine’s scheduled-event writes do not begin until Step 4 lands. Deferring all scheduling to Phase 2 risks Kearney leadership treating the MVP as incomplete regardless of how good the engine is.
Does the system know what a case is and what happens next?
The architectural reveal. ADR-010 implemented end to end — schema, services, API surface. The standard_burial template seeded. Pipeline view component lands on the case detail page. Document-gate modules ship as “mark acknowledged” placeholders ahead of Step 5. System-event modules ship as envelope-only stubs ahead of Step 6. No AI modules.
Step 4 is the largest single step and dominates the arc’s risk profile. Placing it earlier means months of engine work with no visible progress for Ryan; placing it later means operational UI built against an engine that doesn’t yet exist. The midpoint placement gives three preparatory steps to ground the team in Kearney’s workflows before engine commitments lock in.
This is where RequiemOS stops looking like any other case management tool and starts looking like the product the team has been describing.
Does the system enforce compliance, not just suggest it?
DocuSign integrated per ADR-019. The five locked document_gate modules — removal authorisation, contract execution, embalming decision, cremation auth, remains return — become real gates that block downstream modules until signed envelopes return. Form submissions and signed documents flow through DocuSign envelopes back into S3 via the existing Storage:: service.
This is the first regulatory hero moment: the system refuses to advance until the right thing has been signed by the right person.
Does the system make chain of custody tangible?
QR code generation for cases and assets. Scan and lookup endpoint. The coc_scan_* system-event modules wire to real custody_events writes. The custody timeline shipped at Step 3 now shows actual scan events with location and actor.
The second regulatory hero moment. The timeline that has been a read surface for three steps now fills with events from the floor.
Does the system reconfigure for a specific user?
A filtered pipeline view across all active cases, scoped to the admin role, sorted by case urgency and module age. Jessica gets a single screen that surfaces every task currently waiting on admin attention across the whole branch.
Jessica is the first persona-specific surface for three reasons: her tech comfort (8/10) is the highest of the five personas, her primary device is desktop (the most-tested surface in the scaffold), and the pipeline-filtering pattern her console establishes is reused by David’s mobile view at Step 8 and Rob’s print sheet at Step 9.
Does the persona-adaptive UI thesis hold?
A mobile-optimised pipeline view scoped to the director role. One-handed operation, single active case focus. Built on the pipeline-filtering pattern Jessica’s console established at Step 7.
Step 8 is the test of the persona-adaptive UI thesis. The same underlying engine data renders entirely differently for David than for Jessica, with no per-persona code branching at the data layer.
Can the system serve users who don’t use the system?
The prep_task_list_generate module produces print-styled HTML and PDF containing the active prep modules for a deceased, with instructions, container information, and cosmetology notes. High contrast, no chrome, no auth required at the point of reading.
Rob does not log in. He works from paper that the system prints for him. Step 9 proves the persona-adaptive thesis at its hardest case: the user whose primary interface is not a screen at all.
Does the system tell the owner whether the business is running?
Calendar widget from Step 3.5 embedded. Aggregated metrics. SLA breaches. Branch comparisons. Printable. The full owner view, possible only now that the engine, the gates, and the persona surfaces have produced enough operational data for aggregation to mean something.
Margaret’s calendar need arose at Step 3.5; her aggregate-metrics need arises here. Splitting her deliveries reflects this two-stage need rather than forcing both into a single late delivery or pretending the calendar isn’t urgent.
Persona-specific surfaces are concentrated in the back half of the arc by design. Margaret gets a partial early delivery at Step 3.5 because her calendar need cannot wait for the engine. Sophie does not get a dedicated surface at all — her needs are met by the union of the pipeline view from Step 4 and the mobile view from Step 8.
| Persona | Primary surface | Step landed |
|---|---|---|
|
Jessica
Admin / Case Coordinator
|
Filtered pipeline view across all active cases, scoped to admin, sorted by urgency and module age. | Step 7 |
|
David
Senior Funeral Director
|
Mobile-optimised pipeline view scoped to director, one-handed, single active case focus. | Step 8 |
|
Rob
Prep Staff / Embalmer
|
Printed task list generated by the prep_task_list_generate module — no login, paper-first. | Step 9 |
|
Margaret
Owner / GM
|
Calendar widget first, full dashboard later. Aggregate metrics and SLA breaches require accumulated engine data. | Step 3.5Step 10 |
|
Sophie
Young Funeral Director
|
Union of Step 4 pipeline view and Step 8 mobile view. No dedicated surface at MVP. | Step 4Step 8 |
The arc is the architectural commitment and is treated as firm. The revision posture is not piecemeal amendment. If a step changes shape, that’s a step-level adjustment. If the arc itself turns out to be wrong, the response is a successor ADR.
“If the arc itself proves wrong — not that a single step needs tweaking, but that the through-line is misordered or based on faulty assumptions — the response is to rewrite this ADR in full as ADR-018-v2 or supersede it with a new ADR, not to amend it piecemeal. Piecemeal amendments to a sequencing ADR produce incoherent plans.”
Four checkpoints are scheduled into the arc. At each one, the question asked is: does the remaining arc still hold? If yes, proceed. If no, draft a successor ADR before continuing.
Five decisions the ADR explicitly defers. Each has a specific observation that will produce its answer and a likely resolution window. These are kept visible rather than handed off into a follow-up document.
This is the build order, not the workflow design. The architecture of the workflow engine itself lives in ADR-010; its companion context-envelope decision lives in ADR-011. The four-layer audit architecture that Step 4’s module state changes integrate with lives in ADR-014. The e-signature provider decision that Step 5 depends on lives in ADR-019. The forms-registry analysis that Step 2 and Step 4 both consume lives in docs/discovery/forms-registry/.
Out of scope here, and out of scope for the ADR itself: the family-facing portal, billing and payment processing, AI modules, a full scheduling system, tenant self-serve workflow template editing, crematory and cemetery management as first-party features, and native mobile applications. Step 8’s mobile view is responsive web, not native.
Read the full decision at docs/decisions/ADR-018-UI-Sequencing-Arc.md.