Day 3 of 14 — Structure Over Vigilance. Pete Gypps, COR Intelligence.
The first law in this series was the drift law — guarantees live in shape, not in memory. This is the second, and it's the one people nod along to and then break within the hour, because the thing it warns against feels exactly like being sensible.
The signal law: nothing gets lost silently.
Sounds almost too obvious to bother saying. Of course you shouldn't lose things silently. And yet the single most common instruction given to AI systems — "just summarise it" — is silent loss, dressed up as efficiency and waved straight through.
The instinct to compress
Here's how it goes. You're working with a model, and the context gets long. A big document, a long conversation, a pile of notes. The working memory fills up. And the obvious, reasonable-looking move shows up: compress. Summarise the document. Condense the thread. Keep the gist, bin the detail, carry on with something smaller and easier to handle.
It feels like good hygiene. Feels like tidying up. And in the moment it costs you nothing — the summary reads fine, the important-looking points are all there, the work carries on.
The bill turns up later. It always turns up later. It turns up at the exact moment you reach for the detail you compressed away and find it's not there anymore.
You don't know what mattered until later
This is the heart of it, and it's worth sitting with, because it's the bit the "just summarise it" instinct completely misses.
A summary is a bet about what matters, placed at the wrong time.
When you summarise, you have to decide — now, in the moment — which parts are important enough to keep and which are noise you can drop. But you're making that call before you know what you'll need. Importance isn't something you can read off a piece of information at the time. It gets assigned later, by events, by the question that turns out to matter, by the thing that goes wrong.
So the summary keeps what looked important at the time. Reality decides what was important afterwards. And those two lists are, reliably, not the same. The detail you drop to save space has an uncanny habit of being the one that comes back to bite: the offhand caveat that turns out to be the whole story, the single exception to the rule, the number tucked in a footnote that flips the conclusion.
You compressed to be efficient. What you actually did was throw away the answer to a question nobody had asked yet.
Prevention versus compression
The signal law draws a hard line between two things that look alike and are opposites: prevention and compression. Both are trying to solve the same problem — too much context, a working memory that can't hold everything. They solve it in completely different ways.
Compression says: I'm overloaded, so I'll throw things away and hope the important bits survive. It's reactive. It waits until there's too much, then discards, then prays.
Prevention says: I won't get overloaded in the first place. It loads only what's relevant to the task in hand, and keeps everything else intact and pointed-at — one reference away, complete, losing nothing. When you need the rest, it's right there. You didn't have to guess in advance what would matter, because you didn't throw anything away. You just didn't drag it all into the room at once.
Same goal: a manageable amount of working context. Opposite mechanism. One discards and hopes. The other never had to discard, because it never let the noise in to begin with. Prevention is the disciplined move; compression is the lazy one wearing the disciplined one's clothes.
And notice how it ties back to the law. Under prevention, nothing's lost — the unloaded material still exists, still reachable, still whole. Under compression, things are lost, and lost silently: no record of what got dropped, no count of what was excluded, no way to tell later what used to be there. That silence is the violation. If you have to exclude something, the exclusion has to be a visible, counted, recorded event — so that "we don't have that detail" is a fact you can see, not a hole you fall into.
Why more context isn't more intelligence
There's a stubborn belief under all of this that needs dragging out, because it pushes people to do the wrong thing on purpose: the belief that more context means more intelligence. Stuff it all in. Give the model the whole pile. It's clever, it'll sort out what matters.
It won't, and this is where Karpathy's line cuts both ways. His machines don't get bored and don't forget — true, and it's why they're so good at the tedious, thorough work people skip. But they do degrade when you bury them in irrelevant context. A model swimming in noise makes worse calls, not better ones, for the same reason a person handed a four-hundred-page brief to answer a one-line question makes worse calls: the signal's in there somewhere, drowned.
Less noise beats more. For the machine exactly as for the person. Which means the goal was never "get everything in front of the model". The goal is to get the right things in front of it and nothing else — which is prevention, precisely, arrived at from the performance side instead of the safety side. The discipline that stops you losing information silently is the same discipline that makes the model sharper. They're not a trade-off. They're the same move.
The test
Every claim in this series carries a test, because a claim you can't check is just a slogan. Here's the test for the signal law, and you can run it on any system you own today:
When your system drops something, does it tell you?
Ask it plainly. When context gets trimmed, when history rolls off, when a summary replaces the source — is there a record? A count of what was excluded? A way to see, after the fact, what used to be there and now isn't? Or does the system just quietly get smaller and rely on you not noticing?
If it tells you — if every exclusion is counted and visible — you've got a memory you can trust, because you know its edges. If it doesn't, you haven't got a memory at all. You've got a slow leak you've agreed not to look at, and one day you'll reach for the thing that leaked out and it won't be there, with no record it ever was.
So across everything I build, the rule stays the same: keep the whole thing, load only the relevant part, and make every exclusion something you can see. I'm still working it into corners of my own systems where the old compress-and-hope habit is hiding. That's the ongoing job.
Pete Gypps — COR Intelligence. Next: stop fetching your data into the AI — put the AI inside your data.
