Structure Over Vigilance

Why AI systems rot, and how to build ones that don't

Pete Gypps — COR Intelligence

The line that started it

Andrej Karpathy has a line about why documentation written by a language model beats documentation written by a person: "LLMs don't get bored, don't forget to update a cross-reference." It's a throwaway observation. It also happens to name the exact problem I'd been circling for two years, from the wrong side.

Here's the thing that bothered me. If the machine doesn't get bored, doesn't forget, doesn't skip the boring step — then why do the systems we build with these machines still rot? Why does the config drift? Why does the "single source of truth" quietly stop being true? Why does the thing that was correct on Tuesday get subtly, invisibly wrong by the following Thursday, with no single person having done anything obviously wrong?

The answer took me a while to see, because it's embarrassingly simple.

We keep putting the guarantees in the wrong place. We put them in vigilance — in remembering, in checking, in "make sure you always…", in the discipline of the person or the process. And vigilance always, eventually, fails. Not because people are careless. Because vigilance is expensive and boring and infinite, and anything expensive and boring and infinite gets skipped the moment there's pressure.

The alternative is to put the guarantees in structure — in the shape of the thing itself. So that the right thing is automatic and the wrong thing is hard, or impossible, because of how it's built. Not because someone remembered.

I've started calling this structure over vigilance. This paper is what it means, why it matters more for AI systems than for anything we've built before, and how you actually do it.

What "vigilance" looks like when it fails

Let me make it concrete with an invented example, because the real ones are all under NDA.

Imagine a business that keeps its master record of a company — the legal name, the company number, the registered address — in one verified place. Good. That's the source of truth. Now imagine that somewhere, to make a bit of work go faster, someone copies the legal name into a project file. Just the name. Harmless.

Six months later the master record gets a correction — a typo in the legal name is fixed. The master updates. The copy doesn't. Nobody notices, because nobody was watching the copy. There was no alarm, because a copy going stale isn't an event — it's an absence of an event. The wrong name now sits in the project, drifting further from the truth with every day, and the first time anyone finds out is when it lands on a legal document.

No one was careless. The person who copied the name was trying to be efficient. The person who fixed the master did their job perfectly. The system rotted anyway, because the guarantee — "the legal name is correct everywhere" — was living in vigilance. It depended on someone remembering that a copy existed and updating it. And vigilance, given enough time, always loses.

The structural version is boring by comparison, which is the point. You don't copy the name. You point at the master record. There is one copy of the fact, and everything else references it. Now the guarantee lives in the shape: there's nothing to keep in sync, because there's only one of it. The drift can't happen, because the structure won't let it.

That's the whole idea, in one example. Everything else is applying it relentlessly.

The two laws

When I pushed on this, it resolved into two rules that turn out to underpin everything. I state them plainly because plain is the point.

The drift law: guarantees live in shape, not in memory. A rule you have to remember is a rule that will eventually be forgotten. So encode the rule as structure — a folder boundary, a file that must exist, a check that runs — such that the shape itself makes the rule true. The strongest version is uncommittable-by-physics: put your secrets in a folder that sits above your code repository, and they cannot be committed to that repository, ever, no matter how careless anyone is — not because there's a rule against it, but because they're physically outside the boundary.

The signal law: nothing is lost silently. Every log is append-only. Every move is verified. Every exclusion is counted and visible. If information is dropped, that dropping is itself a recorded, visible event — never a silent gap. This is the difference between prevention and compression. When context gets long, the lazy instinct is to compress it — summarise, squeeze, hope the important bit survives. But you don't know which bit was important until later, and by then it's gone. The disciplined move is to prevent the overload in the first place: load only what's relevant, keep the rest intact and pointed-at. Karpathy's machines don't get bored — but they do degrade when you bury them in irrelevant context. Less noise beats more, for a model exactly as for a person.

Two laws. Neither is clever. Both are the kind of thing that sounds obvious right up until you notice how much of what you've built violates them.

Why this matters more for AI

You could argue these laws apply to any system, and you'd be right. Good engineers have practised versions of this forever — the Unix philosophy, information hiding, single source of truth, idempotency. None of it is new.

But it matters more now, for a specific reason. When you hand work to an AI agent, you are handing it to something with no memory of your intentions, no institutional knowledge, and an infinite willingness to do exactly what the structure tells it to do — including the wrong thing, at scale, without hesitation, if the structure points that way. A human picks up your slack. They notice the copied name looks off. They hesitate. An agent doesn't hesitate; it executes. Which means the structure has to be right, because the structure is now the only thing carrying your intent.

This is the inversion people miss. The better the AI gets, the more the structure matters, not less — because a more capable agent will follow a flawed structure more effectively into the wall. The intelligence isn't the risk. The intelligence sitting on top of vigilance-based scaffolding is the risk.

So the discipline isn't "watch the AI carefully." That's vigilance again, and it doesn't scale — you cannot watch a system that works faster than you can read. The discipline is: build the structure so that the AI cannot do the wrong thing, and then you don't have to watch. Put the guarantee in the shape.

Connected data, and why it's the terrain

Here's where it stops being defensive and starts being the actual product.

Most AI tooling treats your data as something you fetch into the model. You have a chat window; the model reaches out, grabs a document, pulls it into the conversation, answers, forgets. The data is passive. The AI is the centre of gravity.

Structure-over-vigilance inverts that. Your data isn't something you fetch — it's the terrain the AI moves through. Every entity is a node. Every relationship is a stated, meaningful link. The AI doesn't pull your data into a window; it navigates your data where it lives, reading the map that your structure already is. As someone building in this space put it, "the data becomes the agent" — you're not instructing an assistant, you're giving it coordinates in a landscape it can read.

This is only possible if your data is genuinely connected — if the relationships between things are explicit, stated, and one-way (A points at B, B doesn't point back, so nothing goes circular). That's not a nice-to-have. It's the precondition. Disconnected data — facts copied and scattered, relationships living only in someone's head — can't be terrain, because there's no map. It can only be fetched, one lonely document at a time.

Connected data is the first pillar. It's what makes the AI an inhabitant of your world instead of a tourist you keep sending on errands.

Visualisation, and why you can't skip it

The second pillar is the one people treat as decoration, and it's not.

You cannot manage what you cannot see. If your estate — your projects, your clients, your systems, your knowledge — exists only as folders and files, then its shape is invisible to you. You can't see which things are connected, which are drifting, which are orphaned, which are on fire. You navigate it the way you navigate a house in the dark: from memory, slowly, bumping into things.

The moment you make the structure visible — render the connections, show the clusters, watch the activity move — something changes that's hard to overstate. The estate stops being a filing cabinet and becomes a place. You glance at it and know things you'd have had to go digging for. Problems that were invisible-by-absence — the orphaned node, the stale link, the thing nobody's touched in a year — become obvious, because now there's something to look at.

And here's the part that connects it back to the whole thesis: the visualisation is a derived view. It's rebuilt from the structure every time; it holds nothing itself; delete it and regenerate it and nothing is lost. Which means it can be as rich and beautiful as you like without ever becoming a liability, because the truth lives in the structure underneath, and the picture is just the structure, seen.

Connected data is the terrain. Visualisation is the light you turn on to see it. Strategy — knowing what to do with what you can now see — is the third pillar, and it's the one only a human supplies. Which is the whole point of the arrangement: AI first, human second. The machine holds the structure and moves through it tirelessly; the human, freed from the vigilance, does the part that actually needs a human — deciding what matters.

I'm not the only one who found this

I want to be careful here, because the honest thing strengthens the case rather than weakening it.

I didn't invent the core. I named a particular framing of it, and I've pushed it further in a particular direction — but the core idea has been arrived at, independently, by several people coming from completely different angles. There's a methodology called Interpreted Context Methodology that reaches the same conclusion from the workflow-automation side: replace the coordination framework with filesystem structure, because "if the prompts and context for each stage already exist as files in a well-organised folder hierarchy, you do not need multiple agents or a coordination framework." That's the drift law, stated by someone who'd never heard me say it. Google shipped something called the Open Knowledge Framework — markdown files with structured metadata as a semantic layer over data — and reached the same place from the data side. The people building the most capable agentic coding tools split their systems along exactly this line: structure that holds versus vigilance that's asked to. Folder-based "second brain" practitioners found it from the personal-knowledge side.

When several people invent the same thing separately, from different starting points, without coordinating, you're not looking at an opinion. You're looking at something closer to a law — something true about how information and reliability actually work, that keeps getting rediscovered because reality keeps enforcing it. The Marquis de Condorcet worked out in 1785 that a jury of independent, better-than-chance judges converges on the truth as it grows — provided their errors are independent. Independent rediscovery is that theorem in the wild. The convergence is the evidence.

My contribution isn't the core. It's three things: extending it from a static workflow to a living estate with a time dimension — because some faults only appear over time, and you catch those with scheduled checks, not with structure alone; making the laws testable, so that "nothing is lost silently" isn't a slogan but an assertion that runs and goes red when it's violated; and building the instrument that applies the laws and renders the result, so you can actually see your structure hold.

Make it able to be wrong

The last piece is the one that separates a methodology from a manifesto, and it's the one I care about most.

A theory you can't disprove isn't a theory, it's a belief. Karl Popper's whole point. So the version of this that I trust is the version where every claim carries the test that would prove it false. "A model update should never break this system" is a claim — and it's testable: update the model, and if anything breaks, you built at the wrong layer and the claim is disproved. "Nothing is lost silently" is a claim — and it's testable: it's an assertion that counts what went in, what came out, and what was excluded, and screams if they don't reconcile. "Secrets are uncommittable" is a claim — and it's a test that tries to commit one and must fail.

The reason this matters isn't academic. It's that a methodology built on running tests finds its own mistakes — including the mistakes of the person who built it. I've watched this method turn its own lens on work I'd done and surface real problems I'd left sitting there, invisible, for months. That's not a comfortable experience. It's the most convincing evidence I have that the thing is real, because a method that only confirms what you already believe is worthless, and a method that catches you out is doing its job.

Where this goes

Structure over vigilance is not a productivity hack. It's a claim about where reliability comes from, and a bet about what survives.

The bet is this: models will keep changing. Every few months there's a better one, and the honest test of your system is whether that's exciting or terrifying. If a new model breaks your carefully tuned prompts and your fragile scaffolding, you built on sand. If a new model just slots in and your system is quietly better — because the guarantees were never in the model, they were in the structure — then you built on rock. Your data, structured and connected and visible, outlives every vendor cycle. The intelligence is a tenant. The structure is the building.

That's the whole thesis. Put the guarantees in the shape. Connect your data so the AI can inhabit it. Make it visible so you can see it hold. Keep the human for the strategy and hand the vigilance to the structure, where it can't get bored and can't forget — not because the machine is watching, but because there's nothing left to watch.

Gravity doesn't need reminding to hold the planets. The best systems we build won't either.