The PRD registry that makes concurrent AI sessions safe to run

Seventy-four commits landed in one week. The team closed 44 tickets. One 16-minute window alone produced 22 commits, each one resolving a separate finding from a single day’s review batch that reached REV0726-30.

Those numbers aren’t the story. AI-assisted development is already capable of that kind of velocity. The more interesting question is what has to exist around that velocity once you stop running one AI session on one task and start running several sessions concurrently against a shared backlog.

That shift changes the engineering problem completely. The interesting part isn’t the speed—it’s the registry that makes that speed trustworthy.

 

From one session to several

A portfolio of 61 PRDs sits behind this work: 58 numbered specifications running from P4 to P61, plus three tracked outside the numbering. Each PRD defines a single feature or fix.

During that week, the unit of work was no longer “one agent, one task, one commit.” Several AI sessions worked on different PRDs at the same time. Each landed changes into the same shared codebase.

A single registry makes that possible.

Every PRD claims its number from one authoritative source. There’s no folder-by-folder guessing.

The same commit both allocates and records the PRD number, so allocation and use happen together instead of as separate steps someone can forget.

The registry exists because of a real failure, not a hypothetical one. Before it existed, different authors assigned the same PRD number four separate times simply by choosing the next available number by eye.

That’s the real win: a problem that occurred four times now can’t happen at all.

 

Two kinds of collision — and only one needed solving

Running several AI sessions simultaneously increases the number of moments where independent processes can disagree about the state of the world. That week exposed two very different kinds of disagreement, and each deserves different credit.

Naming collisions are solved

Authors used to choose PRD numbers by eyeballing whichever folder they happened to have open. There was no shared allocator and no single place to see which numbers were already taken.

After four collisions, the registry eliminated that problem completely. It works exactly as any mature ticketing system’s auto-incrementing ID would.

That’s good engineering. It isn’t novel engineering, and it’s worth saying so plainly.

Live-state races are the harder problem

Live-state races are where the process earns its keep.

Two sessions committed changes close enough together that neither saw the other’s work. One commit dropped three fn_T() translation keys as a result. The team detected the problem during the next audit and restored the missing work within the hour.

The audit also found that two unrelated PRDs had claimed the migration filenames K107, K108 and K112. It caught the conflict while another session was still actively adding files to the working tree.

An ID allocator can’t prevent either failure. These aren’t naming clashes—they’re races over shared, live state. Preventing them requires a different layer of governance: one that observes the live system while multiple processes are changing it, not simply a larger pool of identifiers.

 

Trust the ticket, not the document

The governing rule is simple.

• A PRD never has the final word about its own status. The live ticket system does.
• A Markdown header isn’t timestamped or queryable.
• A ticket is.
• When the two disagree, the ticket wins.

The status report follows that rule consistently. It never accepts a PRD’s “Complete” status at face value. Instead, it verifies every claim against the live ticket before reporting success.

That discipline uncovered perhaps the best example in the dataset: a PRD that the team had genuinely finished and deployed, but whose tracking ticket had never been closed.

• The code was correct.
• The paperwork wasn’t.

Only a process that checks reality instead of trusting documentation catches a discrepancy like that.

 

The insight

None of this is unique to AI. Human teams encounter exactly the same two classes of failure. They simply tend to discover them over weeks instead of within a single afternoon.

Naming collisions already have a well-understood solution: one shared allocator. Every mature ticketing system ships with one. Building the registry wasn’t a breakthrough—it was adopting an established engineering practice.

Live-state races are different because they were never about identifiers in the first place. They happen when two processes modify the same files or branches close enough together that neither sees the other’s work.

That’s why the audit layer matters more than the allocator. It provides one authoritative source of truth and verifies “done” against the live system instead of accepting a document’s word for it.

The same principle sits behind running twenty-six review personas instead of one. Build a process that catches what any single pass—whether human or AI, one session or many—will inevitably miss.

In this case, that process turned four concurrent AI sessions, a 61-item backlog, and a week of overlapping work into 74 commits with no surprises left undiscovered beyond the next audit.

If more than one AI session touches your codebase this week, ask two questions.

What is the single source of truth when two sessions disagree about the state of something?

And what verifies that source of truth, instead of simply trusting it?