T5E6 · The Six-Layer Content Schema

Transcript

LeoTwo teams tell me the same sentence this week: "We have the data." So I go look. Team one hands me a folder of folders. Tasks in one place, logs in another, a spreadsheet of test results, screenshots of reviews in somebody's chat. It's all there. And it's useless — because I asked one question. Show me every run where the agent wrote an over-broad patch that still got merged. Nobody could answer it. Not without a week of grepping.

MayaBecause the answer to that question lives in four different folders that don't know about each other.

LeoTeam two hands me one file format. Every run, same shape, same fields, and a key on each one tying the failure note to the merge decision to the trajectory. I typed the question once. Eleven runs came back in a second.

MayaSame data. Same six categories of information. One team has a swamp, the other an asset. The only difference is shape.

LeoThat's the episode. We've spent this whole topic opening drawers one at a time. Today's the last one, and it's the one that makes the other five worth anything — the schema. The shape you'd actually hand a team.

MayaLast time we argued about governance — where a record is allowed to go, the wall between training and test. Today's the wider question sitting over all of it: what shape does the record have to be in for governance, or training, or anyone, to even use it.

LeoRight.

MayaAnd I want to be careful with one word, because it's the whole point. We keep saying "schema" like it means "a list of the things we collect." It doesn't — a list is what team one had. A schema is a contract: for every single record, here are the fields that must exist, here's what type each one is, here's how they connect. Same shape, no exceptions. And that — same shape, no exceptions — is what turns a pile into something you can query.

LeoSo the curriculum's been calling it a six-layer content schema all topic. Say the six, fast — people have heard them — but I want them as the spine this time, not a tour.

MayaFast. Task — what was asked. Environment — where it ran. Trajectory — what happened, step by step. Verification — was it any good. Failure-and-safety — how it broke, and whether it was dangerous. Governance — are we allowed to use it, and which pile it goes in. Six layers, every record, every time.

LeoWe've done six episodes on what's inside those. So what's left? What does "schema" add that "six drawers" didn't?

MayaThree things, and none of them are the contents. Call them the teeth, the wiring, and the lenses. Start with the teeth — the boring part everything rests on. Required versus optional, and types.

LeoMeaning some fields you can leave blank and some you can't.

MayaRight — but stricter than a preference. A schema enforces it. The commit pin in the task layer isn't "please include it." It's "a record without a commit pin is not a valid record — the system rejects it at the door." Same with the grading command, same with the run identifier. "Required" means the schema won't let a broken record in to begin with.

LeoPush on that. Why enforce at the door? If a field's missing, I'll notice later.

MayaYou won't, though. That's the trap. A record with a missing commit pin looks fine — prompt, patch, green check. It sits in your pile for eight months looking healthy. Then someone replays ten thousand of them for a training run, a third are dead on arrival, and now it's a forensic project to figure out which third and why. Enforcing required fields turns a silent eight-month problem into a loud one-second rejection.

LeoHuh.

MayaAnd types do the quieter version of the same job. A verification outcome isn't free text — it's one of a fixed set: merged, rejected, edited-then-merged. The moment someone writes "looks good?" in that field, every query that counts merges silently undercounts. Types stop a thousand people from spelling the same fact six different ways.

LeoOkay — that's the teeth. Required fields and types, the contract bites back. Now the wiring. What's that one?

MayaThis is the one I actually love, because it's invisible in the drawer picture and it's the entire reason team two could answer my question. The layers aren't six separate piles. They're wired together — keys that stitch one layer to the next.

LeoKeys. Like what.

MayaThink about what my over-broad-patch question actually needed. The failure-and-safety layer — which run had the "over-broad patch" tag. And the verification layer — which runs got merged. Two different layers.

LeoAnd nothing connects those two layers on its own.

MayaRight — the only way to cross them is if both carry the same run identifier. One ID, stamped on every layer of one record, so the failure note and the merge decision both say "I belong to run number four-seven-one-two." Cross-reference on that ID and the question answers itself.

LeoSo the run ID is the thread, and the six layers are beads strung along —

Maya— along the one thread, yeah. That's a good way to hold it. And there's a second thread underneath — the commit pin we made such a fuss about. The task layer says "repo at commit X." The environment builds from commit X. The trajectory's diffs apply against commit X. So the commit isn't just a field in the task drawer — it's a reference three other layers point back to. Pull it and three layers lose their meaning at once.

LeoRight, we said that — load-bearing.

MayaBut here's the new part. In the schema view, "load-bearing" stops being a metaphor and becomes a literal rule. The schema can say: the trajectory's commit reference must match the task's commit. If they disagree, the record is invalid. The wiring isn't just there — it's checked. A trajectory run against a different snapshot than the task declares is a corrupt record, and a real schema catches that the way a database catches a foreign key pointing at nothing.

LeoSo the schema isn't a form you fill in. It's a form that argues back when you fill it in wrong.

MayaThat's the cleanest way anyone's put it all topic. Yeah. The schema argues back.

LeoAlright. Teeth, then wiring — required fields, types, and the keys that thread the layers. That leaves the lenses.

MayaOne schema, many readers. The same record gets read by completely different teams, each wanting only a slice of it — but it has to be the same underlying record, or the slices disagree.

LeoUnpack that. Who's reading.

MayaTake our one bug-fix card. The training team reads the trajectory and the verification — the work and whether it was good. The eval team reads the task, the environment, and the grading command — a replayable problem — and deliberately doesn't look at the trajectory, because they don't want the answer. The safety team reads failure-and-safety and the secret-scan in governance — the dangerous ones. The product team reads the merge outcome and post-merge survival — did it actually help a user.

LeoFour teams, four different views of one card.

MayaAnd the magic is that they're views, not copies. Nobody forked the data. One record, and the schema lets each team project the columns they care about. Which matters enormously, because the second you let four teams keep four copies, they drift — safety's version says one thing, training's says another, and now you can't trust any of them.

LeoSo the schema is also what keeps everybody arguing about the same facts.

MayaOne source of truth, many lenses. That's the last of them. And those three together — teeth, wiring, lenses; required typed fields, keys that wire the layers, one record many readers — that's what the word schema means here. Not the contents of the drawers — the contract the drawers obey.

LeoLet me say it back, because this is the one I'd blur into the overview. Six drawers is what you collect. The schema is the rules every record follows — fields you can't skip, a fixed vocabulary for each, threads tying the layers together so you can ask a question that crosses them, and one shared copy four teams read differently. Filing versus the filing system.

MayaFiling versus the filing system. Steal that.

LeoOkay. Now I want to fight you, because there's a real argument buried in here that I don't think is settled.

MayaGood. Where's the cut?

LeoHow strict should this contract be. You've spent ten minutes selling me on enforcement — required fields, fixed types, rejected at the door, the schema argues back. I'll take the other side. I think a rigid, locked-down schema is exactly wrong for a field moving this fast, and I'll defend a loose one.

MayaThen defend it, because I think loose is how you got team one's swamp.

LeoHere's my case. You design this beautiful normalized schema today. Fixed set of failure tags — localization, hallucinated API, over-broad patch, test gaming, the five we know. Locked. Now next quarter agents get a new tool — say they start spawning sub-agents — and there's a brand-new failure mode that fits none of your five columns. So what happens? Either you drop the signal on the floor, or you do a painful migration and break every record you've already —

MayaSo your fix is, what — let every team throw whatever JSON they want into a blob field?

LeoLet me finish — my point is a rigid schema is a bet that you already know every field you'll ever need. In this field, that bet is insane.

LeoMy fix is flexibility. A store that lets you append new kinds of signal as you discover them, without a committee meeting and a migration every time. Schemas should grow.

MayaAnd that is precisely how you get a swamp. The moment "append whatever you want" is the rule, team A logs the failure as `failure_type`, team B as `error_category`, team C stuffs it in a free-text note — and the over-broad-patch question I opened with can never be answered again, because the fact's recorded six different ways. Flexibility isn't free. You pay for it in queries you can no longer run.

LeoFine, but rigidity isn't free either — you pay for it the first time reality invents a field you didn't predict, and reality does that every quarter here. You're optimizing for queries against a world that's already moved on.

MayaOkay. That one lands, and I'm not going to wave it off. You're right that a frozen schema is a bet you can't win in a field this young. The failure taxonomy will grow. Pretending I can name every failure mode for the next two years up front — that's the arrogant version, and it breaks.

LeoThank you.

MayaBut here's the concession I want back. The answer to "the schema will change" is not "so don't have one." It's versioning. You stamp a schema version on every record — this card was written under version three. When the world invents sub-agent failures, you ship version four, and old records stay perfectly valid under their own version. You don't break them, you don't migrate them in a panic — you just know which contract each one was born under.

LeoSo the spine stays fixed and the edges grow.

MayaThat's the resolution, and it's a real one. There's a stable core — the six layers, the join keys, a small set of required fields that have to be true forever, like the commit pin and the run ID. You lock that down hard, because that's what makes this year's records joinable with records from two years ago. And then there's an extension area — a place for evolving signal, new tags, new tool types, allowed to grow under a version number without breaking the core.

LeoSo I was right that a frozen schema can't survive the field, and you were right that "append anything" is a swamp. The thing that satisfies both is a hard spine and a versioned soft edge.

MayaA typed spine, a versioned extension. You hold the line exactly where joinability lives — the keys, the required fields — and stay loose exactly where discovery lives — the failure modes nobody's seen yet. Lock the part that has to compare across time. Let the rest breathe.

LeoI'll take that.

MayaAnd notice what just happened, because it's the meta-lesson of the whole topic. The argument wasn't really about software. It was about which facts you're betting will still matter in two years. The commit pin will. A run ID will. The exact name of next quarter's failure mode won't. A good schema is mostly a good guess about what's permanent.

LeoNow the honest limitation, because we've made this sound like a solved problem and it isn't.

MayaIt isn't. Two real cracks. The first — a schema enforces shape, not truth. It can guarantee every record has a verification outcome and that it's one of the legal values. It can't guarantee the human who typed "merged" was right. You can have a perfectly valid, fully populated, beautifully joined record that is confidently wrong in every field, and the schema waves it through, because every field is the right type. Shape is not correctness.

LeoSo a valid record and a true record are —

Maya— different animals. Completely. The schema is necessary and nowhere near sufficient. It's the grammar. It doesn't make the sentence true.

LeoAnd the second crack?

MayaThe cost lands before the payoff. Designing the contract, enforcing it at the door, wiring the keys, versioning it — that's real work, and you do it up front, before you have a single record, when the swamp would've been faster and looked identical for the first six months. The team that skips the schema ships sooner and demos the same. The bill comes due exactly when you try to use the data at scale — the worst possible time to discover you can't.

Leo[sigh] So the schema is a tax you pay early to avoid a bankruptcy you'd hit late.

MayaAnd nobody thanks you for the bankruptcy that didn't happen. That's the whole drawer, really — and the whole topic. We started by saying the deliverable isn't code, it's a replayable record of the work. Today's the shape that record has to take so six teams, two years apart, can all stand on it and trust it holds.

LeoHere's what I'd hand the listener to walk out with. Forget agents for a second. Think about any system you run that quietly produces valuable traces — support tickets, deploys, incidents, whatever yours is.

MayaGo.

LeoYou almost certainly have the data. So here's the one I'd leave you with — and it's the hard version of everything we've said today. If you had to pick the three fields that would still have to be true two years from now for any of those traces to be worth querying, which three would you lock down today?