The harness has its canon. Its open questions have answers.

The harness discussion has a canonical text now. Birgitta Böckeler’s «Harness engineering for coding agents» does for this discipline what the best of that catalogue has always done: it takes a practice everyone was improvising and gives it a stable vocabulary. An agent is model + harness. The harness steers with guides — feedforward controls that raise the odds of good output before generation: architecture docs, convention files, skills — and corrects with sensors — feedback controls that fire after: linters, tests, structural checks, review agents. Sensors split into computational (deterministic, cheap, milliseconds) and inferential (an LLM judging semantics: richer, slower, probabilistic). And above the whole thing runs a steering loop: whenever an issue happens twice, a human improves the guides and sensors so it happens less.

We adopt this vocabulary entirely. It is better than the one we were using, and a shared canon lowers the cost of every conversation that follows. When our previous post argued that the harness governs the verb and names no subject, it argued against the harness literature of benchmarks and wrapping layers. Böckeler’s frame is stronger — which makes the gap it leaves sharper, because the canon itself names it. Three times.

The canon’s open questions

The article closes with the honesty that distinguishes good engineering writing from advocacy. Three of its open problems, in its own terms:

1. Coherence — how do guides and sensors stay synchronized as the harness grows? A guide that promises one architecture while the sensors enforce another is worse than no harness at all.
2. Coverage — how do you evaluate what the harness actually checks? There is no established way to measure whether your sensors watch what matters or merely what is easy to watch.
3. Silence — when a tool reports nothing, is the code clean or is the sensor blind? Tool silence is uninterpretable without knowing what the tool was pointed at.

These are not implementation details left as an exercise. They are the structural questions — and they share one root. A harness is a set of controls around an act: this generation, this diff, this session. Coherence, coverage and silence are all questions about a subject: what this project has declared itself to be, and whether that declaration can be checked over time. You cannot answer them from inside the act, no matter how good the controls get.

Sensors that declare their scope

Start with silence, because it has the crispest answer: a green check that does not say what it looked at is a harness lying by omission. That line is the hinge of our talk on the four disciplines, and it is a design rule, not a slogan. In ontoref, a verification does not return a boolean; it returns a verdict bound to a declared scope — this slice was checked against this declaration — and the verdict is a signed, content-addressed witness. Silence becomes interpretable: a check that passes “by absence” — nothing in its declared scope — is visibly different from a check that examined the thing and found it sound. Böckeler’s question «insufficient quality or inadequate detection?» stops being philosophical the moment scope is part of the sensor’s output rather than its documentation.

The same move answers coverage. You do not evaluate harness coverage by intuition; you make every sensor declare its criteria upfront and emit witnessed verdicts, and then coverage is a query, not an estimate. Ontoref’s audit runner converges all its checks onto one vocabulary — declared criteria in, verdict records out, and the directive (stop, rectify, continue) derived mechanically from the verdict, never chosen by the check’s author. A sensor whose severity is an opinion is a sensor you will eventually argue with.

There is one refinement here the canon does not have, and it is the one we would argue for hardest. Not every question a sensor watches admits enforcement. Some of what a project declares is binary — a constraint an ADR froze, a schema a consumer depends on — and there a sensor should fail hard. But some declarations are tensions: two poles the project deliberately holds open, moving between them as it matures. A sensor that hard-fails a tension collapses it to whichever pole the check’s author preferred. Ontoref types this distinction into the sensor itself: hard severity is only legal for non-tension questions; a sensor watching a tension may only report drift and direction, never failure. That is a sensor that knows which questions it has the right to enforce. The rule is not asserted here — it is typed in ADR-050, and you can run the check. We have not found another harness that types the distinction, and we would rather be shown one than be the only ones claiming it.

The same discipline points back at us, and the number is the point. Run ontoref adr validate against this project today and it reports 199 constraints passing, 4 violated, 5 the harness could not evaluate — and 32 with no gate at all. That last figure is the honest one: a constraint nobody checks is not a floor, it is a description of one. A harness that publishes its own coverage can be argued with. That is the whole proposal.

Coherence is itself sensed

The growth question — guides and sensors drifting apart — assumes guides and sensors are two things that must be manually kept aligned. They stay aligned when both are projections of one declared subject: the guide is what the subject serves when queried, the sensor is the check that the code still matches the declaration. When the two share a source, incoherence between them is not a review finding; it is a diff the machinery can detect. A background observer watches code artifacts on one side and declarations on the other, and when they diverge it emits a drift notification — it never applies changes on its own; repair remains a deliberate act. The steering loop the canon describes as a human practice — «whenever an issue happens multiple times, improve the controls» — becomes an institution: drift observed, routed to a backlog, resolved into accepted knowledge or a recorded decision, and the self-model that guides and sensors both read can fail CI when it goes incoherent.

None of this requires possessing the whole. The trust model is explicitly partial: any actor — human or agent — can verify that one slice is coherent with what is declared without loading global knowledge of the project. Completeness is renounced as the basis of trust; sufficiency under verification replaces it. That is what makes the answer scale down as well as up: you do not need the full harness stack to check one op against one declaration.

Ambient affordances have a generator

The canon’s most quietly important concept is harnessability: some codebases respond to harnesses and some resist them, and the difference is «ambient affordances» — structural properties that make an environment legible, navigable, tractable to agents. Types afford checking; module boundaries afford architectural rules; frameworks shrink the decision space.

Read that definition twice and it stops being a property you hope your codebase has and becomes a thing you can install. A typed, queryable declaration of what the project is — its decisions as constraints, its vocabulary as contract, its maturity as explicit state — is an ambient affordance layer: it makes the project legible to any harness that asks, and it is portable across harnesses and models precisely because it lives outside them. This is the same conclusion the previous post reached from the drift side, now reachable from the canon’s own side: ontoref is not a competing harness. It is what makes a project harnessable — the subject the harness queries.

The harness has its canon now, and it is a good one. Adopt its vocabulary. Then ask its three open questions of your own stack — and notice that every answer requires something no harness contains: a subject, typed and witnessed, that outlives the session.

The full arc — from prompt to context to harness to loop, and what each discipline conceded to the next — is in the talk «From prompt to loop». The argument for the subject itself is in «A harness without a subject».

What you leave stated, someone will be able to verify.