Found and Proven

Everyone is telling you to read your skill files. Fine. It’s good advice, as far as it goes. Walk a workflow end to end, mark every place the file tells the agent to stop and wait for a human, and there — the argument goes — is your map of the AI–human division of labor. The pause points are where the organization decided judgment can’t be delegated. Write them down. Your best operators already drew the line; you’re just making it legible.

All true. And it smuggles a claim so quietly that no one checks it: that the boundary is something you find.

Two floors

There are two ways a boundary comes to exist in a system, and they are not interchangeable.

A discovered boundary is located by inspection. You watch the process run, you see where competent people stop, you mark the spot. It is empirical. Its warrant is observation: this is where the line appears to be.

A derived boundary is located by argument. It sits where it sits because it cannot sit elsewhere — the structure of the problem forbids it. Its warrant is proof: this is where the line must be.

The skill-file exercise produces the first kind. It is a survey, not a proof. It tells you where the floor appears to be, given who happened to be walking and how good the tools were on the day you walked.

The line appears vs. the line holds

Here is where the difference gets expensive.

A discovered floor moves. It has to — it was only ever a reading, and every reading is provisional. Improve the tool and the survey reopens. The line you marked last quarter is now just a claim awaiting re-inspection, and you will re-inspect it, and each re-inspection is an occasion to talk yourself past it. A discovered floor gives you no defense against your own optimism, because nothing in the discovery says the floor should hold. It only says where the floor was.

A derived floor does not move, because it never rested on the state of the tool. Its proof doesn’t weaken when the tool gets stronger — the proof was never about the tool’s weakness in the first place. Take the strongest case: the signatory floor. A file needs a human signature not because the model can’t yet produce the words, but because accountability requires a locus of comprehension that can be held to account — and that requirement is indifferent to how capable the model becomes. You cannot improve your way past it. It is not a survey result. It is a structural fact about what accountability is.

Discovered floors are hostage to the very thing they are meant to constrain. Derived floors are hostage too — but that is not the flaw it sounds like, and it is the real reason to prefer them.

A derived floor can fail — but only if one of its premises fails, and that is the whole advantage. A discovered floor depends on the tool, and the tool improves silently; the day your survey stops describing reality, nothing announces it. The floor drifts, and you learn of it downstream, by the bill. A derived floor is hostage to its premises — but a premise is a named proposition, enumerated when you did the derivation, and when it breaks, it breaks at an address you can point to — a break with an address is detectable, not silent. The trade is not fragility for permanence. It is invisible, continuous drift for visible, discrete failure. Derivation doesn’t make the floor unbreakable; it tells you exactly what would have to be true for it to break — and names them in advance.

The receipt

You can watch the difference get billed. The companies now quietly rehiring the people they cut in the name of AI — the reversal isn’t a sentimental story about missing the human touch. It is what walking-to-your-floor costs when the floor was only ever discovered. They had a survey, or they had nothing. The tool looked capable, and nothing in their map said stop here, for a reason that survives the tool getting better — because a discovered floor cannot say that. So they cut through it, and the structure invoiced them for the crossing.

Be precise about what the invoice was for. If the tool simply underperformed, that is a survey error — they overrated the model — and it is not the interesting case. The reversals that matter are the other kind: the tool did the work fine, and something the task-view never counted went missing anyway — the part of the job that could be answered for, not just done. That part does not come back when the model improves, because it was never a capability in the first place.

They did not misjudge the model. They misjudged what kind of boundary they were standing on.

Where this sits

This is not staffing advice. It’s the test that separates a constraint you can build on from one you’re only borrowing until the tool improves. And it applies to itself:

The frameworks worth keeping are the derived ones. Coherent approximation under irreducible complexity is not a boundary anyone walked to; nobody surveyed a retrieval system and observed that optimality was out of reach. It was derived — from the hardness of the search. That is why it holds. A discovered version of the same claim would already be stale: someone would have “found” a faster index and announced that the boundary had moved.

Monday

So — Monday. Read your skill files. But read them twice.

The first pass is the one everyone is selling: find the pause points. The second pass is the one that matters. For each pause point, ask the question the advice skips — is this stop here because someone observed it should be, or because it provably must be?

Sort them. The pause points you can only defend by pointing at experience are hypotheses about where the floor might be; you will defend them again next quarter, a little weaker each time, until some capability release talks you across one. The pause points you can defend by pointing at structure are the floor. Those you defend once.

Most of your boundaries will land in the first pile. That is fine — discovery is how you find candidates, and you cannot derive what you never noticed. The discipline is not to stop discovering. It is to stop trusting a discovered floor as if it were a derived one — and, wherever the derivation is available, to do the work of promoting the floor from found to proven.

The error runs both ways, though. As readily as teams trust a discovered floor too far, they will paint one as derived to stop having to re-examine it — structural is a convenient word when you would rather not move. So carry the same test for both directions: name the premise the floor rests on, and check whether that premise is independent of the tool. A floor whose premise you can name, and whose premise the tool cannot touch, is derived. A floor you can’t name a premise for is not structural — it is only one you have decided to stop questioning.

Discovery locates. Derivation settles. Know which kind of floor you are standing on before you decide how much weight to put on it.