Truthfulness infrastructure
Stopping a system from asserting more than its data supports.
- Type
- System · Python
- Period
- September 2026
- Status
- Live behind the design path; policy default is deliberate and recorded.
One plan generated against the pilot nursery's real catalog was deterministic, passed six guards, and was published. It was also 44.9% over the customer's stated budget, specified eleven of a shrub with one in stock, silently dropped the two trees she had asked for, and carried a design its own scorer had already measured as lopsided. Every one of those facts was computed before publication. Nothing consulted them.
| 6 | guards passed on the bad plan | so it shipped |
| 0 | human-verified plant rows in the catalog | which is why tightening the policy would be an outage, not a safety improvement |
| 3 | generation modes | standard, constrained, unable |
The challenge
A generated plan can be internally valid and externally worthless. Every number in that production plan was correctly derived. The budget overage was computed. The stock shortfall was computed. The dropped requests were recorded. The lopsided composition had already been scored.
The system had all the evidence it needed to know it should not present that plan as ready, and no mechanism for checking it.
What I built
Three connected pieces.
A publishability gate. It computes nothing new. It reads the plant list, the request records, the design score, the guards and the pattern contract, and decides whether the result may wear the word ready. A plan that fails is still generated, still persisted and still carries its full diagnostics — it simply may not be presented as a purchase-ready recommendation. It does not quietly fix anything, because a gate that silently repairs things hides exactly the signal the product needs.
A named evidence policy. Every plant row carries a verification status: a human checked it, or a model estimated it. The default code path had always used the permissive branch — not by decision, but because a command-line flag's default value was the string `dev` and nobody ever passed the argument. The policy is now a named, recorded choice that travels on the plan and appears in the staff record.
A constrained-generation ladder. When the catalog is thinner than the design pattern wants, the plan is no longer simply refused. Composition targets are loosened in a fixed, recorded order until a defensible palette exists, and the plan is labeled constrained rather than standard.
My approach
I measured the thresholds rather than guessing them, and two of my instincts died in the measurement. A recurrence score of zero turned out to be common — four of six sample plans, including perfectly standard ones — so an absolute recurrence rule would have blocked most of the catalog's output. And occlusion did not discriminate the bad plan at all: the production plan's layering score was better than a standard woodland plan's. Any threshold tight enough to catch it on occlusion would have blocked almost everything.
Then I measured again, because the first measurement stopped being true. A change to which container size wins a tie changed which rows were selected, which changed placement, which moved the composition scores a long way.
The line that is not crossed
Every rung of the constrained ladder varies a composition target — how many species a role keeps in reserve, how often one may repeat, how wide the palette should be. Not one of them touches the strict data policy, under which an unrecorded moisture tolerance rejects a candidate outright.
Loosening that would turn nobody has verified this into this is suitable for your site — a plan that passes because the catalog is incomplete rather than because the plants fit. Zone, exposure, moisture, identity, stock and price are not negotiable from that file, and the test suite proves that after every rung has been applied the only remaining reason a role can block is that it has zero eligible species.
Why the obvious fix is wrong
The catalog currently contains zero rows a human has verified. Switching production to verified-only would not tighten the plans; it would end them — every design would decline for want of a single eligible species, on a nursery inventory that is real, in stock and perfectly plantable.
So the default stays where it is, and what changed is that it is now a decision with a name on it rather than the fallback value of an argument nobody passed. The day the catalog has verified rows, tightening it is a configuration change, not an archaeology project.
The result
Staff see why a plan needs them, in plain language, before a customer does — that the plant data is AI-estimated and mature heights should be checked; that a quantity sits near the inventory threshold. The customer-facing plan carries an honest state badge rather than an implied endorsement.
The lesson I keep: a gate can be individually correct on every rule and still decline every plan. I now keep a known-good control and a blunt incidence count beside every gate I write.
