The Column You Write But Do Not Own

The previous pass through this codebase found three defects with one shape: a hand-authored file described behavior, code implemented something adjacent, and nothing compared them. This pass found four more, and they rhyme — but the rhyme is sharper than "two artifacts drifted." In each of these, one side of a boundary wrote a value the other side owned. Nobody was confused. Everybody was doing their job. The defect lived in the space where two correct jobs overlapped and neither one had been told it was sharing.

A framework that nothing verifies

Sixteen modules ship a quality framework — the JSON that says what a generated ICP or persona must satisfy before a human is asked to lock it. Two of them, compass_diagnostic and customer_interviews, ship a complete, carefully authored framework that no handler ever calls verifyFramework against. The file is real. The tests inside it are real. The checks resolve. It is simply never run.

This is not a bug you can find by reading either side. The framework author's work is correct and complete. The handler author's work is correct and complete. The absence only exists in the join, and the join was a convention: "modules of this kind get verified." A convention is a thing you can forget on a Tuesday.

So the convention became a registry — an explicit list naming which module types are gated — plus a sibling assertion test that reads every framework file and fails when one exists that nothing verifies. A framework nobody runs is now a red CI job instead of a file that looks like a gate.

Three writers, two shapes, one row

The /personas module persists one module_items row per tier (p1, p2, p3) plus a handful of anti_persona rows. That is the live shape. It is also what the module's readers, its check functions, and its UI all expect.

Three separate code paths write those rows: the persona-builder skill handler, the shared persist-module-draft tool, and the GTM survey's apply-to-modules seeder. Two of them wrote the live shape. One still wrote a legacy nested structure — a single item_type: "persona" row with the whole PCG matrix folded inside it — inherited from a design that predated the tiers.

The consequence was not a crash. It was worse: the module's registered checks scored what they could find and silently declined to score the rest, and the previous wave had to declare a gap in the framework rather than wire the check ids, because wiring them against a shape half the writers didn't emit would have flipped the skill to fail and broken persona persistence outright. The gap was honest. It was also a placeholder for a convergence nobody had done.

The convergence is done: every writer emits the tier shape, the persist tool now refuses the legacy row outright, and the declared gap is retired. The guard is a source-assertion test that reads all three writer files and fails if any of them ever emits item_type: "persona" again — comments stripped first, so the docblock recording this history doesn't trip it.

Four documents claiming authority they didn't have

A skill brief is a document handed to a frontier model. Its verification section says: here is how your output will be judged. When that section names checks that were never registered, the model is being told to satisfy a gate that does not exist — and a human reading the same brief believes the product enforces something it doesn't.

Four briefs were doing this, and each was wrong in a different way:

• compass-diagnostic listed "Evidence trace" and "Calibration" as code checks. Neither is registered. Bunched scores — the actual failure mode a calibration check would catch — are detected nowhere in the pipeline. The brief now says that, in those words.
• growth-calculator-coach promised the user an app_ask_user turn to adjust the computed results. There is no adjust turn. It also claimed lever targets "sum to or exceed" the ARR delta; the real check is a 90% coverage tolerance.
• growth-stage-assessor claimed in its frontmatter to set profiles.growth_stage. It writes an assignment item and an assessment row. A different path entirely stamps that column.
• persona-builder's verify table named design-intent tests — sentences describing what ought to be checked — where check ids belong.

Every one of these was verified against the runtime before the prose was touched. The rule was absolute in one direction: the document changes to match the code, never the reverse, unless the code is separately found wrong. And the persona-builder table now has a test that parses it out of the markdown and fails when it names an id that doesn't resolve in the check pack.

The column you write but do not own

The last one is the cleanest statement of the whole shape.

Prompt text lives in files now — one markdown file per key, a manifest carrying each row's metadata and two hashes, and a seeder that applies the difference. The seeder owns prompt content. An administrator, working in a completely different surface, owns whether their override of that content is served: a single boolean, is_active, that decides whether the text they wrote wins over the seeded default.

That boolean was in the seeder's metadata list. So it rode the content hash, it was captured into the manifest whenever a row was exported, and it was written back by is_active = EXCLUDED.is_active in the upsert. Every re-seed of a key restored whatever flag the manifest had recorded — turning an override an admin had deliberately parked back on, and putting the parked text back in front of the default that same run had just seeded.

I measured the exposure before fixing it: 304 of 726 keys had a manifest flag that disagreed with the live row. One full re-seed would have re-activated all 304 in a single pass, silently, with no output naming a single one of them.

The fix is one line of SQL removed and one field removed from a list. is_active is set on insert, so a brand-new row is servable, and never touched on update. And it leaves the hashed payload entirely, because the other half of the bug was that an admin flipping a switch made the key look like a pending seed — pressure to re-run the very thing that would undo them.

What I would take from this

The previous entry's lesson was about documents drifting from code. This one narrows it: the highest-risk line in a system is the one where a writer touches a field it does not own. Not a shared file — a shared field. Both parties are behaving correctly. Neither sees the other. The write succeeds, no error is raised, and the loser of the race is a human whose deliberate decision quietly evaporated.

You cannot find these by reading either side, because neither side is wrong. You find them by asking, of every column a job writes: who else decides this? If the answer is "a person, in a different surface, for a different reason" — then that column belongs on an insert, never on an update, and the test that says so should read the SQL.