A case action's event and its patch are two writes with no transaction — and the run path can lose the event

[Taleef7]

Two related gaps found by the 2026-09-07 review. Accepted on 2026-09-08, unchanged since, no issue until now.

1. An operator action is two writes with no transaction

backend-ts/src/case/case-actions.ts records the event (:138) and then applies the patch (:150). A failure between them leaves an action recorded but not applied.

The direction is deliberate and should stay: it can never produce an unaudited state change, which is the hard rule in CLAUDE.md. What is missing is the primitive — there is no applyCaseAction({ patch, action, audit }) that makes the three one unit.

2. The run pipeline is the other way round, and CAN lose the event

This is the part the review's framing understated and the follow-up assessment corrected. run-pipeline.ts upserts the case and then best-effort audits it, catching an audit-insert failure and logging a run WARN rather than aborting. That ordering is also deliberate — it exists so a transient audit_events failure cannot strand an otherwise-complete run as RUNNING after the case was already mutated.

But it means the system-wide claim is false as stated. Carry the narrower true statement:

"Every state change writes an audit_event" holds for operator actions. It does not hold for the run-created case transition, which can mutate and lose the event.

That belongs in DATA_MODEL_CONTRACTS §4 next to the best-effort note, rather than being discoverable only by reading the pipeline.

What was decided about the fix

A reconciliation job was proposed and qualified: it is not magic — it needs durable operation identity, an expected version, a deadline, and a visible failure state, or it is a second unreliable thing checking the first. Before any real operational reliance, the state change, the action record and the audit row should be one transaction, including the run-created case transition.

Partial progress already exists and is worth building on rather than around: recordCaseEvents is a batch atomic dual-write, added for bulk assign and reused for panel backfill. Bulk assign deliberately audits before it mutates — the same side of the trade as the single-action path.

Related: ADR-076, ADR-080, CLAUDE.md hard rules.

[Taleef7]

The mutate-before-audit shape is not one path — swept, 2026-09-21

While correcting the always-loaded claim (#607), the first cut said "operator actions audit first and
cannot lose the event". Codex caught that as still too broad, so the paths were enumerated by a sweep
for the shape rather than from memory. Recording the result here so the remaining work is against a
list rather than an impression.

Audit first — cannot produce an unaudited state change:

• every case action (case/case-actions.ts) — recordCaseEvent makes the action row and the audit
  row one transaction, and the patch follows
• rerun-to-verify's case patch (case/case-rerun.ts), which says so at the call site
• bulk assign and panel backfill, through the batch recordCaseEvents

Mutate first — can apply a change and lose the event:

path	sites
run-created case transition (run/run-pipeline.ts)	best-effort audit after the upsert — the one deliberate trade, since the alternative strands a complete run as RUNNING
measure lifecycle (measure/measure-lifecycle.ts)	createMeasure :54, approveMeasure :69, deprecateMeasure :87, transitionStatus :118
segment create (routes/segments.ts)	:172
terminology-mapping create (measure/value-set-governance.ts)	:335

Only the run's ordering is a considered trade. The other six are simply the order they were written
in — there is no reason not to flip them to audit-first, which is strictly the safer side and needs
no new primitive.

That makes the remaining work in this issue two separable pieces:

1. Flip the six to audit-first. Cheap, no seam required, removes most of the exposure.
2. The primitive, applyCaseAction({ patch, action, audit }), which still needs a transaction
   seam spanning CaseEventStore and CaseStore and wants local Postgres to verify — the SQLite
   floor cannot catch Pg-only SQL.

The sweep was a heuristic over admin, case, measure, quality, program, compliance and
routes, so treat the list as what it found rather than as proof of completeness.

[Taleef7]

Correction to the comment above: it is four, not six — and the other two need a store change

I wrote that the six mutate-first paths could simply be flipped, "cheap, no seam required". That was
asserted from the shape of the call sites without opening each one. Having done so:

Flippable today — everything the audit needs exists before the mutation:

path	why it works
approveMeasure (measure-lifecycle.ts:69)	the MeasureRecord is fetched before the transition
deprecateMeasure (:87)	same
transitionStatus (:118)	same
createTerminologyMapping (value-set-governance.ts:335)	crypto.randomUUID() mints the id before the insert, and the audit uses that id

NOT flippable without a store change — the entity id is minted by the insert:

path	why not
createMeasure (measure-lifecycle.ts:54)	the audit is keyed on r.versionId, which does not exist until createMeasure returns
segment create (routes/segments.ts:172)	SegmentStore.createSegment returns a HydratedSegment; the caller never sees an id beforehand

For those two the options are to mint the id caller-side (as the terminology mapping already does) or
to use the intent-then-completion pattern this codebase already runs for compaction — ADR-073 d4
writes OUTCOMES_COMPACTION_STARTED before the delete and OUTCOMES_COMPACTED after, precisely so
nothing is destroyed without a ledger entry. Either is a real change rather than a reorder.

The question the flip actually raises

Auditing first means a mutation that then fails leaves an event describing a change that did not
commit. The case-action path already takes that side and softens it by writing an case_actions
row in the same transaction, so "recorded but not applied" is explicit and recoverable. The measure
lifecycle has no action table, so the trade there is starker: an over-claim in the ledger versus a
missing entry.

The hard rule picks a side — "every state change writes audit_event" constrains missing entries and
says nothing about extra ones — but this is an evidentiary ledger for an ACO, and over-claiming is
not obviously the lesser fault. Flagged for an owner decision rather than assumed.

[Taleef7]

The enumeration was wrong twice. Replacing it with a reproducible sweep and an explicit triage list.

Codex caught attachValueSet / detachValueSet (value-set-governance.ts:165-174) missing from the
"complete" list I posted above. They are now flipped — everything the event needs is known before the
link is written.

More importantly: the list was wrong because the tool was. The first sweep matched a verb
whitelist (create|update|set|insert|delete|upsert|…), so valueSets.link(...) and unlink(...)
never matched anything. It also attributed the identity writes to a local helper named audit, so
they read as false positives until opened.

Rebuilt without a whitelist — find the audit write, then report every preceding await in the
same function that is not obviously a read — and committed as
backend-ts/scripts/audit-order-sweep.py so this is reproducible rather than a claim in prose.

Verified and flipped

measure approve · measure deprecate · measure status transition · terminology-mapping create ·
value-set attach · value-set detach

Known mutate-first, reason recorded at the call site

• run-created case transition — deliberate; the alternative strands a complete run as RUNNING
• createMeasure, segment create, identity link × 3 — the store mints the entity id

Untriaged candidates from the broadened sweep

Each needs opening before it is called anything. Listing them so the work is against evidence:

path	the await that precedes the audit
admin/waivers.ts:109 grantWaiver	waivers.insert
case/appointment-service.ts:64 scheduleAppointment	appointments.insert
case/evidence-service.ts:130-131 uploadEvidence	bucket.put, evidence.insert
case/panel-assignment.ts:223	upsertPanelAssignment
case/case-rerun.ts:181	patchCase, before the CASE_RESOLVED audit at :203
routes/runs.ts:899-1068	the import-driven finalize path, several
quality/materialize-run.ts, measure/measure-seed.ts, case/case-outreach.ts, audit/audit-packet.ts	likely reads/pure — check

One finding that changes the shape of the answer

A function can be on both sides. rerunToVerify records its action audit-first
(recordCaseEvent, with a comment saying so) and then writes CASE_RESOLVED after the patch. A
per-path binary list cannot express that, so the contract now states the rule per write rather
than per function.

DATA_MODEL_CONTRACTS §4 now says plainly that it is not a complete inventory and that this issue
does not close on §4 alone.

[Taleef7]

#612 merged. The sweep's output is now fully accounted for — every hit opened rather than named from
the tool's summary — which is not the same as this issue closing.

Flipped today, each needing a one-field seam change rather than a reorder: createMeasure, segment
create, segment update (three writes moved, and its 404 relocated), segment delete, and
uploadEvidence — which now audits before the bucket write too, because an object in storage the
ledger never mentions is harder to notice than a missing row. CreateMeasureInput, CreateSegmentInput
and InsertEvidenceInput accept the value the event keys on, optional and store-defaulted.

src/audit/audit-order.test.ts is new, and it exists because nothing tested the rule. Nine call
sites had been flipped across three commits and no test could tell: every existing test asserts the
event EXISTS after a succeeding operation, which is equally true in either order. Each case now makes
the MUTATION fail and requires the event anyway. Ten cases, all mutation-confirmed.

Two review rounds found six defects in that work, three worth naming here because they are the shape of
thing this issue is about:

• the PUT's relocated 404 dropped a guard that also protected two later writes — a concurrent delete
  gave a 500 or an HTTP 200 with body null, where the old order returned a clean 404;
• the audit payload was merged from a pre-read, i.e. a guessed post-state — under two admins the
  event reports the value that lost. It records what the request changes now, with a changed list;
• §4's completeness claim was wrong for the third time. It now carries the count (55 hits across 20
  files) and the one-line command that re-derives it, because each time the prose was plausible and the
  arithmetic was not done.

What remains, and none of it is ordering

1. The primitive. There is no applyCaseAction({ patch, action, audit }), and there cannot be one
   inside a single store: the action and audit rows belong to CaseEventStore while the patch belongs
   to CaseStore, so a real fix needs a transaction seam spanning both. Wants a local Postgres — the
   SQLite floor cannot catch Pg-only SQL.
2. dispatchOutreach — the one path that puts something OUTSIDE the system before the ledger.
   channel.send() dispatches the message and the payload is built from the delivery result, so there
   is nothing to record beforehand and nothing to retract after. Needs ADR-073 d4's
   intent-then-completion pair, which adds an event type consumers read. Owner decision.
3. The three identity-link writes — upsertLink returns the EXISTING row's id on conflict, so a
   caller-minted id is not the id the event would name. Keying them on the pair works and changes
   what entity_id means. Owner decision.
4. EVIDENCE_UPLOADED now reaches an operator surface. The case timeline is
   audit_events WHERE ref_case_id = ?, so a failed bucket write leaves a permanent "Evidence
   uploaded — " row with nothing to download. The rule picks the over-claim side for the
   ledger; whether a clinical-ops read inherits it for a named file is a separate call.

Deliberately mutate-first and staying that way: the run-created case transition, the import-driven
finalize, recover-stuck-runs, batch-evaluate-scale, and the three backfill/CLI seeding tools — each
with the reason at its own call site.

Tracked alongside the rest of the remaining work in #614.