An append-only table rejects an unplanned write

An append-only audit table makes every permitted change part of its contract. Our Muniment Cloud code broke that contract with one late observability write.

The database rejected the write as designed. Its shared transaction then erased the user message and model reply that the evidence should have recorded.

One update settles an attempt

Muniment Cloud keeps model-routing evidence in an append-only table protected by a database trigger. A request first writes a provisional attempt when it calls a provider.

Exactly one update may move that attempt to its terminal state. The trigger checks the state transition and compares the new row with the old row.

That comparison excludes an allow-list of columns which the terminal update may change. Every other update raises an error.

The design held for three weeks. A later feature added two columns for provider prompt-cache token counts on each attempt.

Its code settled the attempt, then issued a second update for the cache columns. That second write had no valid route through the trigger.

Two guards rejected the late write

Two independent checks rejected the cache update:

1. The transition branch required the old row to remain provisional, but the first update had already settled it.
2. The allow-list omitted both cache-token columns, so the row comparison also found prohibited changes.

Either guard could reject the write. Together, they exposed two separate mistakes in the same design change.

An immutability trigger is an application contract written in database code. Its allow-list names every field the system may learn during the permitted terminal update.

An evidence failure became a message failure

The evidence write shared one transaction with the user message and the model reply.

The trigger error therefore rolled back all three records.

The request had already paid for the provider completion. Its caller received a generic save failure and retained neither chat message.

An observability field created a data-loss path in the feature it observed. Transaction boundaries made that result predictable, even if the feature code did not.

Late facts need a sanctioned route

An append-only design needs a sanctioned channel for facts that arrive after settlement. Muniment Cloud already had a separate amendments table for that purpose.

That table already used the cache-token field vocabulary. A reconciliation job wrote those late values through the amendment path, while the new code bypassed it.

The direct update should never have existed. New late-arriving fields belong in an amendment, unless the trigger contract explicitly admits them during settlement.

Parser coverage never met the trigger

Tests covered the parser that reads cache-token counts from the provider stream. No test ran the evidence write against a real PostgreSQL instance.

The suite therefore never exercised the trigger, the terminal transition, or the allow-list. Parser coverage could not test a database contract.

We found this defect while reading the merged diff during a scheduled review, not through a user report. The note reports no production error count.

We did not measure how often providers report cache tokens. We also did not benchmark the amendment path against the direct update.

This evidence comes from our Muniment Cloud note pinned to commit 41f55921d9d3c5838e2f186548b889b4a2e39f44.

Append-only evidence stays trustworthy only when every late fact takes a route the schema permits.