# The Conflict Table Is Empty

The schema knew what was supposed to go wrong. bridge-db, the shared SQLite store that three AI systems on my machine read and write, ships a dedicated table for write conflicts: durable receipts for rejected or raced writes, filed under four status buckets, open, resolved, acknowledged, ignored. Whoever designed it (me) looked at three concurrent writers sharing one store and built the instrument for the obvious failure, [two agents grabbing the same key in the same moment](/interleaving-explorer.html) and one of them losing.

I pulled all four buckets, fifty rows each. Zero. Not zero open conflicts sitting on a healthy pile of resolved ones. Zero rows total, across every status, in a store whose activity-log row IDs run past five thousand.

The easy reading is that coordination is going fine. The rest of the pull says otherwise, and this essay is about the gap between those two facts.

## Three writers, no boss

The store's principal writers are Claude Code, Codex, and Claude.ai, with two smaller services behind them. It holds [an activity log](/fleet.html), long-lived context sections (career, capabilities, research, speaking), cross-agent handoffs, and cost records. Two earlier essays set up this one. Trust doesn't survive a handoff, so you instrument the seam instead of trusting the narration. And the coordination platform you don't need: two agents passing work turned out to require nothing more than a branch as the lock and a plain-text receipt as the proof.

Both of those are stories about a baton. One agent holds the work, then the other does, and the interesting failure lives in the exchange. This is the next case up, and as far as I can tell it is mostly unwritten territory: no baton. Three systems mutate one store concurrently, none of them owns it, no orchestrator sits above them deciding who writes what, and each writer is an unreliable narrator of its own writes. Nearly every published account of an agentic setup assumes a single mind at the top. This store has a schema, whatever discipline the schema enforces, and nothing else.

To be fair to the arrangement: the happy path is real. One weekly-review entry describes the pattern the bridge exists for, working exactly as designed. Claude Code diagnosed a wrapper-drift bug in a shared automation layer, filed a handoff, and Codex shipped three merged PRs against it within 48 hours. Diagnose in one system, dispatch, land in another. That is the baseline the rest of this essay deviates from.

And the deviations never once took the shape the conflict table was built to catch. No documented race, ever. What the receipts document instead are four failure shapes of a different species entirely, and every one of them is quieter than a race.

## Nobody agrees what a project is called

The largest single coordination effort in the pulled window was not a feature. It was a migration whose entire purpose was to establish what things are named. A Claude Code activity entry ("Lane C identity migration") describes ratifying `repo_full_name` as the one canonical project key bridge-wide, then backfilling 67 existing activity rows that carried null or divergent keys. The same entry logs 206 residual identity-linter findings, traced almost entirely to Codex's automation deriving project identifiers from prompt slugs and working-directory names rather than from repo identity. Those residuals were filed as a follow-up handoff, not fixed inline. Agreeing on names was too big for one session.

It gets stranger inside a single writer. Even after that migration shipped, dozens of Codex rows in the same window carry `project_name: "portfolio-code-health"` in the human-readable field while `canonical_key: "acme/portfolio-health"` sits underneath. One writer, one session family, two different strings for what is presumably one project.

Here is why no lock would ever have fired on any of this. A race requires two writers to contend for the same key. These writers never touched the same key; they each derived their own, from whatever was nearest to hand, and wrote it once. The disagreement is real and consequential, and it is invisible to any mechanism that watches for collisions, because identity fragmentation is a conflict about what the key *is*. The intra-row version, one writer's label disagreeing with its own enforced key, is the raw material: the moment a second system starts keying off the other field, that private inconsistency becomes a cross-agent conflict, and it still won't look like one in any table.

## Corrections are narrated, not made

The activity log is append-only. No edit, no delete. So when a writer gets an entry wrong, the only fix available is to write another entry. Codex did this three times in a single day: three consecutive rows whose entire content was correcting prior rows, one framed as "supersedes activity_id=5464," another "supersedes activity_id=5462," a third superseding 5464 again, each restating a closeout state the original had botched. One of them confesses that the "prior correction over-declared memory=updated even though no new memory note was created in the correction lane." A correction of a correction, in prose, by ID reference, with the hope that every future reader follows the chain.

Read that against the empty table and the shape snaps into focus. A durable, queryable record that one claim supersedes another is precisely what the write-conflicts table was built to hold. The formal mechanism sits at zero rows while the informal version of the same workflow runs constantly, in free text, one narrator patching its own story.

The same decoupling shows up between the log and the structured handoff queue. The identity-migration entry says its residual findings were "documented in handoff 024, holding for dispatch." I queried the pending-handoffs table in the same pull: zero rows. So "is there open cross-agent work?" has two answers, depending on which surface you ask, and they disagree. The narrative layer remembers a handoff the structured layer no longer holds. Neither surface is lying, exactly. They have simply stopped describing the same world.

## Recency is a lie told by the loudest writer

Twelve near-identical "CC session ended" rows for the same project appear back-to-back in the feed, timestamped roughly five seconds apart. Housekeeping noise from one writer, flooding a shared chronological view in under a minute.

Scale that up and it becomes a structural property. A 40-row pull of Codex activity in this window is almost entirely a multi-day dependency-hygiene sweep: merge this PR, hold that one, close as superseded, re-check a blocked lockfile. Routine, and voluminous. The equivalent 40-row pull of Claude Code activity is session-boundary pings plus a handful of `SHIPPED`-tagged entries for actual feature work. Same feed, same window, wildly different signal density. "Recent activity" as a shared view privileges whichever writer produces the most rows, not whichever produced the most consequential change, so a reader scanning it, human or agent, has to filter by tag rather than trust recency at all. Nothing conflicted here. Nothing even went wrong, row by row. The feed degraded anyway, purely from differential write rate.

## The one seam that held

There is exactly one place in the pull where the store overrode a writer, and it is worth staring at. When Claude.ai populated the capabilities and research context sections from a pasted document, it requested `source_trust=operator` on both writes. The bridge's provenance gate clamped both to `source_trust=agent`, because the `claude_ai` caller role cannot self-assert operator trust; only the human can grant that. The write went through, downgraded, no negotiation, no error.

Notice what the gate did not do: it did not read the content and decide whether the claim was plausible. Trust in this store is a property of who wrote, enforced server-side, regardless of what the write says about itself. And notice the correlation: the one class of write where the store refuses to take the writer's word for a field is the one class of write with zero documented failures.

## The counter: this is a solved problem

Anyone with a distributed-systems background has been shouting the same thing for five sections now. Concurrent writers on shared state is the most solved problem in computing. Use a real database with transactions and serializable isolation. Use a CRDT. Stand up a lock service. This was settled in the 1970s; the essay is describing amateur-hour schema design and calling it a research finding.

Partly right, and I'll concede the strongest version first. A validated, non-null canonical-key constraint enforced at write time would have prevented the 67-row backfill and most of the 206 residual findings outright. The identity migration is the itemized bill for not having a schema constraint, and the boring answer wins that point without a fight. The trust clamp proves it from the other direction, because the trust clamp *is* the boring answer: a dumb server-side check the writer cannot talk its way past, and the cleanest surface in the store.

But look at what the classical toolkit actually solves. Transactions and locks arbitrate between writers who agree on the key and contend over the value. The receipts show writers who disagree about the key itself, about their own past claims, and about what deserves to be in the feed at all. Nobody raced; they diverged. A CRDT merges concurrent edits to one register and has no opinion when one writer calls the register "portfolio-code-health" and the schema calls it "acme/portfolio-health." Serializable isolation guarantees the history is equivalent to some serial order, and every write in this store already is serial. Order was never the problem. Meaning was.

Two things about these writers genuinely fall outside the classical frame. First, they are probabilistic and they narrate: a conventional service writes what its code computed, while these writers record what they believe they did, the belief is sometimes wrong, and the fix is more narration, which is how you get a correction chain three rows deep in one day. Second, the store doubles as the audit trail. You cannot rewrite bad rows in place without destroying the evidentiary property that makes the store worth keeping, so append-only is a feature, and that feature converts every correction into a citation chain by design. No isolation level touches either problem.

I'll pre-register the falsifier, since the whole argument leans on an absence. If the write-conflicts table starts filling as writers multiply or write rates climb, then genuine races are real here, the boring toolkit gets its seat back, and this essay's emphasis inverts; I would rewrite it. As of this pull, the count is zero.

## Where the store should own the words

The scope, stated plainly: one operator's machine, one store, one pull of receipts, and the receipts were assembled by one of the three writers under discussion. What I'm claiming are the failure shapes, not their universality. But two of them, identity fragmentation and volume asymmetry, don't depend on anything local to this schema. They follow from having multiple probabilistic writers that each derive names from local context and log at rates set by their own workloads. Any shared store with more than one LLM-shaped writer should expect both. Whether it also gets a trust clamp depends on whether somebody builds one.

The portable rule is sitting in the correlation from five paragraphs back: every seam that held is a seam where the store refused to take the writer's word for something. Trust held because a role gate owned it at write time. Identity is *becoming* reliable exactly as fast as an enforced canonical key replaces free-derived names, and the residual drift lives precisely where enforcement doesn't reach yet, inside one writer's automation. The failures cluster wherever a writer supplies its own vocabulary, its own project names, its own correction semantics, its own sense of what matters, and the store transcribes it faithfully.

So reread the empty table one last time, because it isn't a gap in the data. It is the finding. The schema instrumented the collision and got the drift. Three writers with no boss did not fight over the state; they quietly stopped meaning the same things by it, and the instrument built for the fight recorded nothing while the meanings came apart in full view of the log. The fix is not a bigger lock. It is more places where the store, not the writer, owns the words.

## Postscript, 2026-07-11

Four days after this published, the store grew teeth in the places the receipts pointed. Schema v13 added a claimant identity column to pending handoffs, and clearing one now requires being the agent that claimed it, so the log and the table can no longer quietly stop describing the same world. Write conflicts surface in the health report. Prunes leave audit receipts. Rows tagged as durable are retention-exempt, which means the loudest writer can no longer age the important ones out of the feed. Even the correction chains got a schema: closeouts now supersede prior claims by structured receipt, bound to the superseded row's ID, instead of free prose. I re-pulled the conflict table before writing this. Still zero rows. The falsifier stands unfired, and the store owns a few more of the words.