Skip to content
Delivery Harness Framework / DHF Governance Decision Flow

What happens before the tool runs.

The Lifecycle Flow and the Skill Routing Map answer which route a task takes. This map answers a different question: for any single tool call, what has to be true before it is allowed to execute, and what happens when it is not. Refusal edges and the verification back-edge are drawn, because an agent that only has success paths is a demo.

Governance Decision Flow

Every tool call passes this gate.

Read it as an enforcement path, not a workflow. The guard runs at PreToolUse, so a refusal happens before the side effect, not after it. Note the two properties the topology encodes: an unresolved phase falls back to read-only rather than to trust, and a self-declared phase still cannot reach a protected root.

flowchart TD
  Req(["Agent proposes a tool call"])
  Lane{"Execution lane?"}
  HITL["High impact
separate human authorization
promotion / push / deploy"]
  Phase{"Work phase resolved?"}
  ReadOnly["Fail closed
read-only fallback"]
  Declare["Agent self-declares a phase
codex-task declare"]
  Cap{"Does the phase allow this capability?
repo_write / network / remote / subagent"}
  Scope{"Where does the call reach?"}
  Protected["Protected root or persistence write
shell profile / LaunchAgent / crontab"]
  Tier{"Category risk tier"}
  Block["PreToolUse returns a real block
reason + risk_tier"]
  Run["Tool executes"]
  Evidence["guardrail_decision appended
schema-validated JSONL"]
  Verify{"Fresh verification passes?"}
  Compact{"Context compaction happened?"}
  Successor["Transition store CAS
exactly one successor"]
  Handoff(["Checkpoint + next safe task"])

  Req --> Lane
  Lane -- "local development" --> Phase
  Lane -- "operator live demo" --> Phase
  Lane -- "customer / production" --> HITL
  HITL -- "approved" --> Phase
  HITL -- "not approved" --> Block
  Phase -- "no" --> ReadOnly --> Declare
  Declare -- "unblocks low / medium only" --> Cap
  Phase -- "yes" --> Cap
  Cap -- "no" --> Block
  Cap -- "yes" --> Scope
  Scope -- "protected root or persistence" --> Protected --> Block
  Scope -- "inside governed root" --> Tier
  Tier -- "high: remote / secret / destructive / dynamic_exec" --> Block
  Tier -- "low / medium" --> Run
  Block --> Evidence
  Run --> Evidence
  Evidence --> Verify
  Verify -- "fail: back to the agent" --> Req
  Verify -- "pass" --> Compact
  Compact -- "yes" --> Successor --> Handoff
  Compact -- "no" --> Handoff

  classDef decision fill:#f0eaff,stroke:#8a4fff,color:#17241f;
  classDef deny fill:#faeaf1,stroke:#d13574,color:#17241f;
  classDef runtime fill:#e9f7f5,stroke:#0f9b8e,color:#17241f;
  classDef build fill:#fbf0dc,stroke:#b26a00,color:#17241f;
  classDef verify fill:#eaf6f0,stroke:#12805c,color:#17241f;

  class Lane,Phase,Cap,Scope,Tier,Verify,Compact decision;
  class Block,Protected,ReadOnly deny;
  class HITL,Declare build;
  class Evidence,Successor runtime;
  class Run verify;
How to read it

Four properties this diagram is claiming.

1. Permissions are phase-scopedEight lifecycle phases each declare whether repository writes, network, remote access, and subagent dispatch are allowed. The capability check is a gate, not advice in a prompt.
2. The agent cannot widen its own reachSelf-declaring a phase unblocks ordinary low and medium actions. It never unlocks protected roots, and persistence writes stay refused in every phase.
3. Refusals are recorded, not just successesBoth the block edge and the execute edge converge on the same evidence append, so the audit trail shows what was stopped as well as what ran.
4. Failure has somewhere to goVerification failure returns to the agent instead of falling through to handoff, and a compaction routes through a first-record-wins transition so a retry cannot fan out into two successors.
Scope

What this map does not claim.

This is the enforcement path as implemented in source, with the guard promoted to one machine's runtime. Production enforcement, customer adoption, and commercial validation are separate and still unverified — the architecture status page is canonical. There is also a known limitation the diagram deliberately does not hide: the host's ask response fails open, so high-risk categories are hard blocks rather than approval prompts, and the Plan Governor stays in shadow with production_status = no_go.

Next

Continue the English path

Lifecycle FlowSee how a request routes from intake to handoff. Skill Routing MapSee which skill or helper owns each stage. Engineering NotesRead the compaction and rollback-prevention detail. English IndexReturn to the public guide entry. 中文版Read this same governance decision flow in Chinese.