The Floor Is Inherited. The Ceiling Is Uncompiled.
On the boundary between the guarantees a pipeline can enforce and those it cannot yet prove
On day one of the run, the 5th guide — Dentists — failed its first adversarial audit at 8.1, below the 8.5 ship bar. The defect: Lesson 2.2 told dental practices to complete a patient’s predetermination narrative — tooth numbers, clinical findings, radiographic findings, treatment plan, payer context — in “a separate Word or Google Doc.” A real PHI-handling defect, presented as a workflow instruction.
On day seventeen, the 60th guide — Tree Service Companies & Arborists — failed its first adversarial audit at 8.66. Its problem wasn’t a privacy leak. It was that a credential-gate rule the pipeline already had hadn’t been confirmed complete across all thirteen lessons that needed it, plus two smaller consistency gaps in a pricing template and in jurisdiction-specific language.
Both cleared the bar for “first-round FAIL.” They are not the same kind of gap.
Fifty-five guides have shipped Guide 5. Build time fell from a 4.0-hour single-guide build on June 28 to roughly 1.0 hour per guide by July 12, when three guides shipped in 2.95 hours combined (cs20-data-pull.md, §2, “The speed curve”). The July 5 rendering-gap lint is the clearest instance of what a deterministic gate does once it exists: it found and remediated 114 instances across 23 of the then-43 live guides the same day, and once wired as a blocking gate, that specific check runs on every subsequent build in its declared scope (BUILD-STANDARD.md, gate #4). That’s what “encoded” means in practice — not that every mechanical error class stops recurring, only that the specific pattern a gate was built to catch does, within that gate’s scope.
First-round audits continued to fail anyway, on defects outside those encoded classes.
The floor is what repetition inherits
Every gate, constraint, and catalog norm a pipeline has ever earned arrives before the next build starts. By guide 60, a July 14 count found seven mechanical gates live in import_course.py and fifty-one dated constraint sections in constraints.md running before a single word of new content was judged (cs20-data-pull.md, §4, “The mechanism inventory”) — including a generic credential-gate rule, already in place across prior guides, requiring any credential, license, or insurance claim to carry a verification clause. Write a deterministic rule once, and every time it’s triggered, it decides the case the same way. What it doesn’t do on its own is find every place it should have triggered. A rule existing and a rule finishing the job are two different things.
Guide 60’s credential-gate rule has its treatment compiled: verification-clause language was correct everywhere the rule fired, already established in prior guides and independently reconfirmed clean on an untouched sibling guide the same week. What’s still manual is everything upstream of that — a person read all thirteen lessons, decided which ones raised a credential claim (ISA certification, TCIA membership, contractor’s license, insurance, bonding), and confirmed nothing was missed. Treatment is compiled. The rest isn’t, and the pipeline can’t yet tell how many separate things “the rest” is made of.
For this PHI-handling pattern, guide 5 has nothing compiled at any abstraction level the pipeline has tried. No rule fires on a workflow instruction that moves protected health information. No rule specifies what to do about it if one did. Nothing checks that every PHI-touching instruction in a guide got reviewed. Four Healthcare guides after Dentists hit different PHI vectors the same way — a worksheet that didn’t inherit a course-level privacy fix, a placeholder pattern that read as an invitation to fabricate clinical findings, a de-identification gap where a name-only swap left real dates and findings intact, a missing credential gate on one outward-facing prompt — each with the same total gap, at the abstraction level the pipeline has tried so far. That’s five data points about what hasn’t compiled yet at that level. It isn’t proof that a broader rule — trace where patient data moves, require an approved system and documented review at every stop — couldn’t compile all four in a single pass, the way the credential-gate rule already compiles every guide-60-style credential claim once it fires. It’s only proof nobody’s built and tested that broader version.
Two audits, two different shapes of gap. Guide 60 kept one piece — the rule fires correctly once triggered — and lost the rest. Guide 5 kept nothing. Naming what “the rest” is made of:
Treatment is whether the system knows the right action once triggered.
Applicability is whether it can spot the trigger in the first place, unit by unit, without a person reading first.
Coverage is whether it can prove every unit in a scope actually got checked, whether the checking itself is automated or still done by a person.
Guide 60 has treatment. Whether its remaining gap is applicability, coverage, or one undifferentiated piece of both is something the pipeline can’t answer yet, because neither exists as a running check — a person reading all thirteen lessons doesn’t separate “did I spot the right ones” from “did I check all of them.” Guide 5 has none of the three, at any abstraction level tried.
A decision joins the inherited floor only when treatment, applicability, and coverage are all compiled — meaning each one produces a checked result the pipeline itself stands behind, not a person’s unverified word for it — once each has been built and tested. Above that line is wherever one or more hasn’t compiled yet. The quality of the manual sweep does not change the pipeline’s compilation status — that’s a property of the pipeline, not of who’s currently standing in for the missing piece. It remains uncompiled until the corresponding pipeline guarantee is built and tested.
TIE had a name for the floor side of that boundary. The corresponding boundary is the Uncompiled Ceiling: the point at which one or more required guarantees still lacks a tested artifact the pipeline can enforce against its declared scope.
Venkatesh Rao’s The Taste Essay (Contraptions) distinguishes connoisseurship — inherited, learnable, auditable discernment — from taste: a self-authored choice that departs from that inherited culture and carries real risk because someone else didn’t want it made. Rao’s open question is how a model might be taught taste, not whether — and that question is his, not TIE’s to answer here.
What TIE is testing sits at a much lower bar. A constraint file reproduces inherited judgment the way connoisseurship reproduces an inherited taste culture, once applicability, treatment, and coverage are all built and tested. It hasn’t been shown to do Rao’s second kind — a choice made because of who the operator is and what they’re willing to risk. Guide 60’s uncompiled sweep and guide 5’s absent PHI rule are gaps in automation, not gaps in expertise. That’s not Rao’s taste. It’s the smaller claim this essay can support: which side of a governance file’s compiled line a case falls on, right now.
The Uncompiled Ceiling: for a given decision, the current boundary at which one or more required guarantees — treatment, applicability, or coverage — still lacks a tested artifact the pipeline can enforce against a declared scope. The triad classifies the missing guarantee; the term names the resulting boundary.
Guide 60’s manual sweep identifies a missing mechanism: applicability, coverage, or both must be implemented and tested. The boundary itself isn’t a defect; it’s what’s left after everything currently compiled has been applied, and more volume doesn’t compile it by itself.
Earlier drafts treated encoded judgment as if treatment, applicability, and coverage transferred together. Guide 60 shows that they do not. Its credential-gate mechanism transferred its treatment; it didn’t transfer applicability or coverage — which of a new guide’s specific claims trigger the rule, and whether every lesson carrying one actually got checked, was still something a person had to work out fresh. Across those five guides, first-round audit still found defects outside the pipeline’s compiled checks.
The classification test is component-specific, not a measure of how hard a decision is or how often it recurs. An artifact counts only if the pipeline produces an inspectable output against a new guide’s inputs and enforces the criterion specific to that component. A standalone checklist doesn’t qualify unless the pipeline itself can prove every unit in the declared scope was presented for disposition and blocks shipment on any omission. For treatment: an encoded rule tested to emit the correct action for every trigger class it’s supposed to catch. For applicability: a classifier tested to correctly flag trigger versus non-trigger, unit by unit, without a person making that classification during the run. For coverage: mechanical proof that every unit in a declared scope actually went through whatever applicability process is required — a manifest of every unit and a recorded disposition for each, with nothing skipped. Those dispositions may be automated or human, as long as the pipeline itself enumerates the scope and blocks shipment if any unit lacks one; what coverage rules out isn’t a person’s involvement, it’s a person’s unverified say-so that they checked everything. An automated classifier that’s accurate on every lesson it’s given, but only gets pointed at twelve of a guide’s thirteen lessons, has applicability compiled and coverage still missing — the same gap would exist if a human reviewer, not a classifier, worked from a list that silently dropped the thirteenth lesson. Guide 60 has neither: nothing enumerates its thirteen lessons and forces a disposition on each one, and nothing classifies which carry a credential claim without a person reading first. A person reading all thirteen lessons doesn’t separate “did I spot the right ones” from “did I check all of them” — both get answered, or missed, in the same unverifiable pass. Guide 60 has the treatment artifact, already established in prior guides and reconfirmed clean on a sibling guide that week. It doesn’t have anything else built yet. Guide 5 has none of the three, at any abstraction level tried so far. A component joins the inherited floor only when its artifact has passed a declared test against a declared scope.
After an audit failure, “write a rule” is not a sufficient classification. It’s treatment, applicability, coverage, or some combination — and nothing gets marked compiled until the matching artifact exists and has passed its own test against a declared scope.
The Honest Part
Rao distinguishes an inherited grammar of judgment from a self-authored one, bearing real risk. This essay establishes only the narrower boundary between guarantees the governance system can enforce and those it cannot. An earlier draft called it “earned” — that borrowed weight the evidence doesn’t carry. The quality of a manual review does not determine whether the review is compiled. That classification depends on what the pipeline itself can produce and verify.
The harder problem is what an uncompiled part actually proves about whether it can be compiled at all. The four Healthcare PHI failures after guide 5 don’t mean PHI judgment resists automation. They show that each pattern sat outside the compiled checks that governed the affected surface at the time: a course-to-worksheet inheritance gap, a placeholder pattern that invited fabrication, an inadequate de-identification rule, a missing credential gate. The evidence here doesn’t yet separate treatment, applicability, coverage, or some mixed failure for each one — Guide 60 already shows a working treatment can coexist with a missing applicability or coverage piece. A broader rule — trace every place patient data moves, require an approved system and documented review at each stop — might compile all four in a single pass, the way the credential-gate rule already compiles every guide-60-style credential claim once it fires. That’s the hypothesis this essay is proposing to test, not a diagnosis it has already made. If the rule passes its test, that component moves to the inherited floor within the rule’s declared scope — a testable prediction, not a hedge. If it catches only three, that implementation has failed to establish the four as one operational class.
This pipeline has not yet demonstrated an applicability-and-coverage mechanism that flags a previously unseen PHI vector, in approved-system terms, before adversarial review. The first test should use a guide whose PHI pattern was absent from the mechanism’s development and test sets. Before a human audit ever sees that guide, score three predeclared outcomes separately: whether it flags the instruction, whether it prescribes the required handling, and whether it produces a complete manifest. One pass would establish a first held-out result, not proof for the whole class. That’s a pass/fail event this pipeline hasn’t run yet, on either the credential-gate applicability check or a PHI applicability check, because neither exists.
Guide 60’s manual sweep did get done — a person read all thirteen lessons and confirmed every credential claim now carries the required treatment. But nothing in the pipeline can repeat that check on guide 61 without a person doing it again from scratch, and nothing yet enumerates a guide’s lessons and forces a recorded disposition on each one either. The completed sweep establishes the result only for guide 60; it doesn’t compile applicability or coverage there or for the next guide. Compiling either takes a tested mechanism, not a one-time result, and until one exists, both remain above the line — even though the treatment rule itself already existed before guide 60 shipped and was independently reconfirmed clean on an untouched sibling guide that same week.
The next build decision is whether to implement applicability or coverage first for the credential gate. The broader PHI rule supplies the next empirical test: run it against a held-out pattern and determine whether the four Healthcare failures form one operational class or four separate ones.