Skip to content
DHF for Product & Field Teams

What the harness guarantees,
without reading the code.

Delivery Harness Framework (DHF) wraps AI agents in the same discipline you expect from a good engineering team: understand first, work in small verified steps, prove every claim, and hand off cleanly. This page explains the five guarantees in diagrams.

Guarantee 1 · Predictable process

Every request runs the same delivery loop

No agent jumps straight to code. Work always moves left to right, and each stage has a gate that must pass before the next one starts. A PM can ask "which stage is this in?" at any time and get a real answer.

The DHF delivery loop Requestintake Recoverfacts & state Requiresuccess criteria Planslices & gates Buildone slice at a time Verifyfresh evidence Handoffnext safe task the handoff seeds the next request — nothing relies on anyone's memory
Gates only move forward. If a stage cannot pass its gate, work stops there and says so — it does not quietly continue.
Guarantee 2 · No unproven claims

"Done" always comes with a receipt

Every completion claim carries a four-part verification receipt. If any part is missing, the claim is treated as unverified — by policy, not by trust. For a PM this means status reports are checkable; for an FDE this means you can re-run exactly what was run.

The verification receipt Verification receipt attached to every completion claim what ranthe exact check how it exitedmachine-readable result what it showedthe key output line when it ranevidence freshness missing any field → the claim is UNVERIFIED, and a historical green result is never reused as proof of today
One receipt proves one claim. Yesterday's passing test does not certify today's system — verification is always re-run after change.
See a real one

Sanitized verification example

what ran
Public navigation, content, and responsive layout checks.
how it exited
Completed successfully with no failed checks.
what it showed
Every registered page was reachable and the mobile layout stayed within the viewport.
when it ran
Immediately after the documentation update.

Report-only refresh shape

Status: attention needed
Observed: deployed version differs from the approved source
Changed: nothing
Next: operator reviews version direction and evidence
Guarantee 3 · Blast-radius control

Work is routed by lane before it starts

The first routing decision is not "what to build" but "where this is allowed to touch". Customer data, production systems, deploys, and secrets sit behind approval gates that agents cannot self-grant.

The lane gate Incoming work any request Lane gate Local development free to iterate — no external systems, no customer data Operator live demo real accounts, with the operator present and approving Customer / production deploys, secrets, and customer data stay approval-gated
An FDE can promise a customer: nothing crosses into the production lane without an explicit, recorded human approval.
Guarantee 4 · Long work survives

Multi-day work does not depend on anyone's memory

AI agents have a limited working memory. DHF continuously writes decisions, progress, and the next safe task to durable files, so when a session fills up, a successor picks up exactly where the last one stopped — once, not twice, and never by guessing.

How long-running work survives Session working memory slowly fills Memory pressure detected by the host, not self-reported Safe boundary finish the step, verify Successor session resumes from the handoff Durable state: progress log · decisions · verification evidence · one next safe task written continuously, so any session can be reconstructed from files alone exactly one successor per boundary — duplicates are structurally impossible, not just discouraged
For a PM: a two-week agent project degrades gracefully instead of restarting. For an FDE: any session can be audited after the fact from durable files.
Guarantee 5 · Deployments only move forward

An older version can never silently replace a newer one

Every deployed environment remembers which version it runs. Before anything overwrites it, the harness compares versions: newer wins, same is a no-op, and older is refused unless a human explicitly approves a rollback. Scheduled automation only reports — it never repairs.

The deployment direction guard Incoming deploy carries its version Version compare NEWER → deploys forward move, verified after landing, version recorded SAME → no-op nothing rewritten, nothing to verify twice OLDER → refused fails closed; only an explicit human-approved rollback may pass
This guard exists because the failure it prevents is real: an out-of-date automated job once tried to overwrite a newer runtime. Now the direction check is structural.
What this means for you

Two audiences, two payoffs

The same five guarantees read differently depending on your seat.

If you manage the product

  • Status is checkable: every "done" has a receipt you can open, not a vibe.
  • Scope is visible: work is sliced, and each slice lands or fails on its own.
  • Risk is bounded: customer-facing lanes require recorded human approval.
  • Long projects degrade gracefully: session limits produce handoffs, not amnesia.

If you deploy in the field

  • Environments are self-describing: each one records the exact version it runs.
  • Rollbacks are explicit: nothing downgrades without you approving it by name.
  • Automation is read-only by default: scheduled jobs report drift, never "fix" it.
  • Everything is auditable after the fact from durable files and receipts.
Go deeper

Beginner guide

The plain-English walkthrough of completion evidence and handoff basics — the natural next page after this one.
Go deeper

Lifecycle flow map

The full end-to-end flow behind Guarantee 1, from request intake to verified handoff.