Change Governance
Not every change deserves the same process. A typo fix and a cross-cutting auth rewrite should not pay the same review tax. Change governance is Forge's deterministic triage contract: a decision procedure, written as plain text, that the orchestrator applies to every change before acting. It classifies the change into a tier, and the tier decides how much of the workflow spine runs and how heavy review must be.
Governance is injected contract, not a gate
Be precise about what this is not. Governance does not fire steps and it blocks nothing on its own. There is no hook watching diffs in real time. It is injected text — a contract the orchestrator reads and is expected to follow, the same way it follows the constitution or a spec. Forge renders the trigger-rules; the model applies them. The discipline comes from consistent application, not from a gate that rejects non-compliant changes.
Advisory by design
Governance is a Guide — feedforward, it steers the run before it happens. That is the right shape for a judgment task: deciding a change's risk tier needs interpretation, and interpretation belongs to the model. This is the deliberate advisory default. See the enforcement doctrine for why only a small set of controls enforce.
Governance is not one of the enforced gates
The four enforced controls return a non-zero exit from deterministic evidence. Trigger-rules do neither — they are advice the orchestrator honors. When governance routes a Substantial change to full review, it is forge review validate that later enforces the delivery gate. Governance decides depth; the gates enforce outcomes.
The three tiers
Tiers are evaluated top-down, first match wins: check Trivial first, then Substantial, and everything else falls into Standard. When a change sits on the boundary between two tiers, pick the deeper one. A human can always force a deeper path than the classifier would choose on its own.
| Tier | Trigger | Workflow depth | Review |
|---|---|---|---|
| Trivial | ONLY docs / comments / formatting / typos — zero executable code, zero config | implement → verify | No review lens |
| Standard | Any other diff touching executable code or config | specify → plan → tasks → implement → verify | Exactly ONE lens, matched to the dominant risk |
| Substantial (hot-path / large) | Touches an auth / update / security / payments hot path, OR changes more than 400 lines | Full spine: specify → clarify → plan → tasks → implement → verify | The full 4R set |
The 4R set is review-risk, review-reliability, review-readability, and review-resilience — see Adversarial Review for what that review actually does.
The 400-line budget
A single change should stay under roughly 400 changed lines. Cross that budget and the change is Substantial by definition — it must either split into smaller changes or go through full review. This is a size-based escape hatch: even a diff that looks superficially Standard is promoted to the deepest tier once it is large enough to hide risk.
Delegation triggers
Alongside tier classification, the trigger-rules carry a small set of rules that keep the main agent thread thin and honest about when to get help or stop:
| Trigger | Required behavior |
|---|---|
| Reading 4+ files to understand a flow | Delegate exploration to a subagent |
| Touching 2+ non-trivial files | Use one writer; require a fresh review before marking complete |
| Commit / push / PR after code changes | Run a fresh review unless the diff is Trivial |
| Wrong cwd / worktree accident / confusing failure | Stop and re-audit before continuing |
How it reaches every agent
The canonical contract lives once under .forge/, and Forge pushes the rendered text into each adapter's own context file — because not every agent reads Forge's directory directly. The injection is marker-delimited:
<!-- forge:trigger-rules -->
… rendered contract …
<!-- /forge:trigger-rules -->It lands in CLAUDE.md for Claude and in the equivalent generated file for every other adapter; for OpenCode and Kilocode it rides inside the forge-orchestrator prompt, and for Jinja hosts it becomes an included module. The injection is idempotent: re-running it strips the previous block before appending the current one, so forge sync produces byte-identical output no matter how many times it runs. Refresh it after an update with forge install or the faster forge sync.
Governance has no slash command
Governance is ambient. There is no /forge.governance to invoke — the trigger-rules are always-loaded context, applied continuously rather than called. The nearest deliberate action is /forge.secscan for the security scan and forge sync to re-render the contract.
What it governs
- Depth — how many workflow phases run for a given change, per the tier table above.
- Review — whether and how heavily review runs: Standard gets exactly one lens matched to the dominant risk; Substantial gets the full 4R set. See Adversarial Review.
- Task-status honesty — a task is only
doneonce its acceptance scenarios pass underverify, not merely because a step ran.
Next steps
- Adversarial Review — the review depth governance selects.
- The enforcement doctrine — governance as an advisory Guide among enforced Sensors.
- The Workflow — the spine each tier walks.
- Commands — the phases governance routes between.