Trust Model
How Harness Intelligence makes AI-assisted work inspectable
The hard part is knowing what shaped the code.
After an AI-assisted run, the team needs to know which guidance the agent read, which workflow it followed, which checks ran, which artifacts changed, and which parts still need human judgment. The Harness trust model exists to make those answers inspectable.
Harness Intelligence makes the operating trail explicit. The output becomes easier to review because the team can inspect the context, workflow, evidence, and artifacts behind it.
The trust model works because trust is attached to inspectable evidence. A finished run should leave enough artifact trail for another engineer to see why the agent acted, which validation evidence supports the result, where manual judgment was applied, and what remains uncertain.
What Trust Means
Trust means the team can answer concrete questions after an AI-assisted run:
- Which repo and scoped guidance shaped the agent?
- Which skills or phase wrappers were active?
- Which checks ran?
- Which source files, docs, specs, or logs were used as evidence?
- Which artifact records the result?
- Which docs or backlog state changed?
- Which work remains outside scope?
If those answers are missing, the team has a confidence problem even when the code looks plausible.
Trust Surfaces
Each trust question maps to a concrete Harness surface:
- Prompt surfaces define the operating rules before work starts.
- Skills define workflow contracts for requirements, planning, delivery, review, debugging, docs ingest, and debt resolution.
- Validation gates define what evidence is required before closeout.
- Hooks and required tools make repeated checks easier to run and harder to forget.
- Wiki and docs artifacts preserve requirements, specs, implementation notes, runbooks, and source knowledge.
- CLI distribution keeps repositories on a known scaffold baseline.
- Reporting loops turn friction into skill, docs, hook, CLI, or baseline improvements.
No single surface is enough. The trust model comes from how these surfaces reinforce one another.
Artifact Trail
After a completed run, trust comes from the artifact trail.
The relevant artifacts fall into a few groups:
- Scope artifacts: specs, plans, backlog updates, and explicit non-goals.
- Implementation artifacts: implementation notes, changed files, review findings, fixes, and tech debt captured or resolved.
- Validation artifacts: command output, manual checklist results, browser evidence, and runtime evidence gathered during debugging.
- Docs artifacts: docs ingest result, explicit no-op reason, routed Fumadocs pages,
meta.jsonupdates, rootdocs/README.md, and runbook updates. - Feedback artifacts: backlog synchronization, harness reports, and follow-up links when they are in scope.
The point is not to make every run produce more documents. The point is to prevent invisible documentation debt and invisible trust debt.
Artifact trails are useful only when they preserve judgment. A validation command without its scope, a checklist without the inspected behavior, or a note without the remaining risk gives the team ceremony instead of evidence.
Manual And AFK Trust
Manual and AFK flows earn trust differently.
In manual flow, the operator creates trust through explicit checkpoints: requirements definition, spec review, plan review, manual E2E, and debugging evidence collection.
In AFK flow, the operator creates trust before the run by choosing a bounded goal and a phase wrapper. The phase then carries the workflow discipline, validation gates, artifact expectations, and final report while the agent works.
Both modes use the same underlying trust model: source guidance, scoped contracts, validation, artifact closeout, and honest blockers. For operating details, see Goal Mode And AFK.
Limit
Harness output still needs engineering judgment. The system gives the team a standard way to shape, constrain, validate, review, document, and improve AI-assisted work. Speed is useful only when the quality bar remains visible.
Manual trust and AFK trust both depend on that judgment. The difference is where the judgment is applied: during active checkpoints in manual work, or before and after a bounded phase in AFK work.