ADR 0059: Interrupt to prevent, expand to attest — the ceremony rulings

Status: Accepted Date: 2026-08-14 Issue: #1545 Related: #1532 (epic), ADR 0058 (inline expansion is the default container), #687 (hazard ceremonies), #688 (Review & Sign), ADR 0010 (interlock bypass), ADR 0034 (permission tiers)

Context

ADR 0058 made inline expansion the default container and left the ceremony dialogs to per-dialog founder rulings. The founder ruled on all eleven on 2026-08-14, from a proposal set that rendered each dialog as it ships. Ten were ruled on those renderings. The batch-command dialog was ruled on a side-by-side pair, the shipping modal against a rendered inline mockup, after the founder declined to rule on prose alone.

One ruling was revised inside the same session, before #1545 closed: the founder reopened delete/withdraw with an operational argument from DeltaV practice. Completed batches are deleted routinely to keep execution lists clean, their durable record is the batch production record in the historian, and a typed-name ceremony per completed batch is hostile to a daily task. The ruling below splits that dialog by target.

The eleven split into two kinds, and the split is the doctrine this ADR records. A friction ceremony guards an irreversible action on equipment, a batch, or infrastructure. Its interruption is the protection: taking the screen forces a stop, and the consequence text is the content the moment needs. An attestation ceremony signs or reviews a thing: a record, a recipe, a change, a prompt response. A modal fights that purpose, because it obscures the thing being signed. Review & Sign showed the tell before this epic existed: #688 required "show what is being signed", and the modal satisfied it by embedding a summary of the record it covers.

Decision

Interrupt to prevent. Expand to attest. Per-dialog rulings, each the founder's:

Dialog	Helper	Ruling
Delete / withdraw of authored content (recipes, formulas, charts, every template kind, physical model, IOModules, controllers, alarm definitions, simulation presets)	DcsConfirmDelete	Modal — the only copy is being destroyed
Delete of execution artifacts (batches and ad-hoc runs in terminal states)	DcsConfirmDelete today	Inline, bare confirm — no typed name, no reason; the audit trail records actor and action, and the BPR in the historian is the durable record
Node + site-outage verbs (18 actions)	DcsReasonPrompt (impact tier)	Modal
Interlock bypass	DcsInterlockBypass	Modal
Controller failover	DcsFailover	Modal
FB hot-swap override	DcsHotSwapOverride	Modal
Re-authentication prompt	offerReauth → DcsModal.confirm	Modal (an authentication interruption, whatever raised it)
ISA-88 batch commands (Abort/Stop/Hold/Reset)	DcsConfirmCommand	Inline (ruled on the mockup pair)
Change-request sign (approve/reject/withdraw)	DcsReasonPrompt (reason tier)	Inline, on the CR detail
Recipe lifecycle + revert	DcsReasonPrompt (reason tier)	Inline, on the recipe detail
Review & Sign (batch record e-signature)	DcsReviewSign	Inline, at the foot of the record itself
Operator prompt respond (HMI)	hmi-prompts.js	Inline (the phase view's #phasePromptSection is the precedent)
Promote (change control)	DcsPromote	Inline, a full-width panel on the recipe detail

Three conditions bind every migration:

1. Every rung survives, with one ruled exception. Reason fields, typed names, acknowledgements, attestation statements, signer identity lines, and re-authentication all render in place exactly as they render in the modal today. A migration that drops a rung is a defect, and 21 CFR Part 11 constrains the ceremony's content and manifestation while saying nothing about its container. The exception is the terminal-batch delete, where dropping the typed name and the reason is itself the founder's ruling: routine disposal of an executed batch is not a hazard ceremony.
2. The status quo governs until the migration lands. A ruled-inline dialog keeps its modal until its implementation issue ships, per ADR 0058.
3. Each migration passes the epic's ruling-5 rendering gate before its issue closes, and declares capture staleness per ruling 4.

DcsModal (#704) remains the permanent container for the six ruled-modal ceremonies. A new ceremony added to the product picks its side by this ADR's doctrine and records the choice in its own review.

Alternatives Considered

Migrate all eleven. Rejected by the rulings. The friction ceremonies protect exactly by interrupting, and an inline delete confirm rewards muscle memory in the one place muscle memory destroys the wrong thing.

Keep all eleven modal. Rejected by the rulings. The attestation ceremonies hide the thing they sign, and the largest dialog in the product (Promote) is a review surface that outgrew its container long ago.

Defer the split to each implementation. Rejected. The epic's ruling 2 demanded recorded per-dialog rulings, and eleven implementations re-litigating one doctrine would have produced eleven local answers.

Consequences

• Seven implementation issues carry the migrations, one per inline ruling, each pairing with a re-shoot issue when it declares capture staleness. An eighth issue adds multi-select bulk deletion of terminal batches on the same bare confirm, because routine cleanup is the stated use. The heaviest capture costs are Promote (1 shot, 4 clips) and Review & Sign (3 shots, 2 clips), and the batch commands touch 4 clips.
• The first-batch quickstart flagship films three recipe-lifecycle reason cycles and re-shoots when that migration lands.
• The mockup-then-rule path is worth repeating: the batch-command ruling reversed the written recommendation once the founder saw the pair rendered, which is evidence that container questions are decided on pixels.
• views/recipes.js hosts the recipe-lifecycle and Promote migrations plus #1539's small-prompt item. They are one co-session cluster.