Put a ledger under it: event sourcing for AI pipelines

Eighteen months from now, someone — legal, a customer's auditor, a regulator, your own incident review — will point at an asset your product published and ask: which model made this, from what inputs, on whose infrastructure, and can you prove it? If your system's memory of that generation is a database row reading status = succeeded, the honest answer is no. The row remembers that something happened. It has forgotten everything about what.

Rows forget. That's what UPDATE means.

The standard integration stores generations as mutable state: a jobs table, updated in place as things progress. Every update is a small act of amnesia. The retry overwrote the error that triggered it. The migration backfilled a column and now nobody knows which values are original. The provider's raw response — the only artifact that could settle a dispute about what the model actually returned — was parsed, its interesting fields extracted, and the body dropped on the floor.

For most CRUD, fine. But a generation record is testimony: it exists to answer questions about the past, faithfully, under skeptical examination. Mutable state is structurally the wrong tool for testimony — anything that can be updated can be disputed.

The ledger alternative

The alternative is old, boring, and proven everywhere money moves: record what happens as immutable events, append-only, and derive current state from the sequence. For a media pipeline:

job.submitted     capability, normalized input, candidate plan
job.dispatched    provider=A, model, mapped params, raw request
job.failover      cause=rate_limited, raw provider response preserved
job.dispatched    provider=B, re-normalized input
job.completed     raw provider response, output URLs
asset.stored      sha256, byte count, storage key — custody taken

Three properties do the work. Append-only: events are never updated or deleted, so the record can't be quietly revised. Raw payloads preserved: the provider's actual response is in the ledger, not a summary of it — disputes end by reading, not by reconstructing. State is a fold: the job's current status is computed from its events, so the convenient row still exists — as a cache of the truth rather than the truth itself.

Billing, dashboards, and status pages should be projections of the ledger — never a second source of truth that can learn to disagree with it.

You get the audit trail. Engineering gets everything else.

The compliance story sells the ledger; the day-two operations story is why nobody uninstalls it:

• Debugging becomes replay. A weird job is a sequence you can read top to bottom — including the failover and its recorded cause, which a status field would have overwritten.
• Idempotency falls out. Webhooks arrive twice, out of order, or not at all. A fold that's idempotent and convergent under duplicated, reordered, and dropped deliveries turns delivery chaos from a bug class into a test suite. (Ours is property-tested for exactly those permutations.)
• Cost attribution is a query. Every dispatch and failover is an event with a provider and model attached — per-job cost is a projection, recomputable and arguable-with only by arguing with the ledger itself.
• Lineage comes free. When one job's output feeds another — still → animation → dub — the events already reference the chain. That DAG, from published asset back to original prompt, is precisely the artifact transparency regulation keeps asking for.

One hard rule: terminal means terminal

A ledger only earns trust if its semantics are ruthless. A job that reached succeeded or failed never transitions again — no exceptions for convenient cleanup scripts. The moment a terminal state can un-happen, every downstream consumer (billing, notifications, exports) inherits a class of bugs that are nearly impossible to reason about, and your audit trail acquires an asterisk. Corrections are new events, not edits to old ones — the same way accountants have fixed mistakes for five hundred years.