The Harness
The Decision Owner's instrument
Present the harness to a business audience as testing infrastructure and it will be treated as an engineering concern and deprioritized. It happens quietly, and it kills the model. So here is the way the harness actually functions.
The harness is the Decision Owner's instrument. It is the automated system that continuously validates what was built against what was specified, running in CI on every push. Not before demos. Not nightly. Every push. It is what lets a business domain expert accept work every day without reading code, and that is the mechanism the whole model rests on.
The frequency is the point. A harness that runs periodically is a reporting tool. A harness that runs on every push is a gate that stops work from proceeding until it satisfies the contract, and the gate is what creates the discipline.
QA as a phase
QA as a phase. Testing used to be a downstream activity performed by a separate group, on a different timeline, with different assumptions. The lag between build and test was where defects accumulated. The handoff was where context died. And the queue it created cost a week or more per round trip, with defects getting more expensive the longer they waited, because the developers had moved on.
The people of that phase land better than the phase did. Careers spent thinking about how systems fail are exactly what harness stewardship needs. Former QA engineers are the shortlist for authoring the criteria test agents build from, confirming that checks trace to the spec rather than to the implementation, and growing coverage week over week. The phase retires. The discipline gets promoted.
What disappears is the handoff, the queue, and the lag. Not because testing stopped mattering, but because it moved from a phase performed by a separate group to a continuous property of the build, authored by the fleet and gated in CI. The Fleet Lead directs test agents to write checks alongside the build, so by the time the build is complete, the harness is complete.
What remains, and must be staffed, is exploratory testing for the things a harness cannot anticipate, and independent validation for high-risk changes. Expect a small specialist function rather than a team-level role.
The four layers
In the order they tend to get built.
Shape. Interfaces return the right structures, status codes, and content types. Screens show the right fields. The data model matches the spec. Fastest to write, catches the most obvious mistakes.
Behavior. Every "when X, then Y" in the spec becomes a check. This layer carries the acceptance weight. If it is green, the increment does what the Decision Owner asked for. If it is red, it does not. There is no ambiguity to resolve.
Failure. Invalid input, missing data, unauthorized access, boundary conditions. This is where teams find the defects that would have sailed through any demo-based acceptance, because demos show one path and the harness checks every path.
Control. Policy constraints are enforced and the audit trail is written. In a regulated environment this layer is not optional. It is what lets you accept daily without accumulating regulatory debt, because every increment carries proof that it complies with the constraints that apply to it.
The authorship
The agent fleet writes and maintains the coverage as it builds. The Fleet Lead owns the harness's integrity, and their most important single review is confirming that the checks correspond to the spec's criteria rather than to the implementation.
An agent that writes tests against its own implementation produces a green harness that proves nothing. This is why test agents work from the criteria independently of the build agents, and it is why the Fleet Lead role survives even when agents can produce all the code.
The demo does not carry the decision
Demos happen daily and they are valuable. They show stakeholders the work in a form they can react to, and they build intuition about what was built. What a demo cannot do is carry the acceptance decision.
The most common way the daily cycle degrades is a team accepting an increment on a red harness because the failures look cosmetic. If the harness is red at close, the increment does not land. The day ends with the failing criteria named, and that is the blocker branch working as designed.
If a criterion is failing because the criterion is wrong rather than the build, that is a spec correction made in daily planning, not waved through at acceptance. The second habit is how a harness stops meaning anything within a month.
An asset that compounds
Most process artifacts depreciate. Documentation goes stale, test plans fall behind, institutional knowledge walks out the door. The harness is the exception, because it runs on every push, forever.
Every Effort adds checks that outlive it. A check written in January still runs in August, proving the system still works. The cost of proving the next increment falls over time while confidence rises, and new teams inherit a proven baseline instead of starting from scratch. That accumulated proof is worth more than any amount of documentation, and it is the mechanism that makes fungible capacity practical: a new team can start an Effort on a system they have never touched because the harness proves it still works.
When an Effort ends and the team dissolves, the harness stays. Treat it as an organizational asset, not a team artifact.
One boundary worth stating plainly. A green harness proves the increment satisfies the contract. It does not prove the contract served the outcome. The Decision Owner still judges whether the result belongs in someone's hands. The harness strengthens judgment by giving it evidence. It does not replace judgment with a score.
The failure modes
A red harness gets accepted. "The failures look cosmetic." Within two weeks the harness is a suggestion. Within a month the team is back to demo-based acceptance, which is the process this model replaced.
The harness is not in CI. It runs before demos instead of on every push, so a defect introduced at 10am is discovered at 4pm, after the team has built on top of it. Moving the harness into the CI pipeline is the single most important infrastructure step.
The harness proves the implementation. Coverage is high, defects still reach the demo. The checks were written by the same agent that wrote the code, so they confirm what was built rather than proving what was specified. Trace checks to criteria. That is the Fleet Lead review.
The harness is too slow. A 45-minute harness is a harness teams stop running. Parallelize, cache, and keep the critical path fast enough that nobody has to decide to run it.
The control layer is missing. Shape, behavior, and failure are covered, and the team is shipping daily without proving compliance. This is the gap that creates audit findings. The control layer is what makes daily acceptance safe in a regulated environment.
For a risk audience, lead with evidence rather than speed. This model produces more evidence, more often, at a finer grain, and with clearer attribution than the process it replaces.
Practical patterns
Policy as a check. The Domain Knowledge Network injects a constraint at spec time, the spec encodes it as a criterion, and the harness checks it on every push. Say a policy requires a second approval for any transaction above a dollar threshold. The harness rejects any transaction above the threshold without the approval flag, on every push, for every team, whether or not the team knows the policy exists. The expert's judgment runs in CI long after the expert has left the room, and the audit trail is a byproduct rather than an exercise.
Inheriting a system with no harness. The most common real-world condition. Write checks for the current spec, not for the existing system. Each day's spec adds its own checks and the harness grows from that day forward. Backfilling the whole system before starting is a trap that delays the first cycle by weeks. After four to six weeks of daily cycles the harness covers the active surface, and the code nobody touches does not need checks until it does.
Coverage gaps. The tell is defects at the demo that the harness should have caught. Do not just add checks after the fact. Trace the gap to the spec: was the criterion there and not checked, or missing entirely? The first is a Fleet Lead review failure. The second is a spec failure.
"We'll fix it tomorrow." A red harness at close is not an invitation to keep building. The blocker is named and the next day starts by resolving it. Teams that carry red criteria forward for "just one day" are the teams whose harness stops meaning anything.
Its place in the Model
In The AI-Native Operating Model™, the harness sits in the Effort Teams + AI Fleets band in gold, because it is an execution mechanism. But it is the Decision Owner's instrument, which is why its checks come from the green domain-judgment layer.
The harness connects to:
- Intent, which connects the proof to its purpose, authority, execution, and accountable judgment
- The spec, which supplies its criteria
- The Decision Owner, who accepts against its evidence
- The Domain Knowledge Network, whose expert constraints are encoded into it
- Continuous governance, because the harness is how "Are we building them right?" is answered daily
- What to Measure, where the rework-location metric tracks whether defects are caught by the harness or at the demo
Read the Harness white paper (PDF). Return to the Model to see how the harness connects to the rest of the system.