# 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.

::: info 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](/harness/overview) for why only a small set of controls enforce.
:::

::: warning Governance is not one of the enforced gates
The [four enforced controls](/harness/overview) 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`](/features/review) 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](/features/review) for what that review actually does.

```mermaid
flowchart TD
    A["Every change, before acting"] --> B["Classify against trigger-rules"]
    B --> C{"Tier?"}
    C -->|Trivial| D["implement then verify · no lens"]
    C -->|Standard| E["spec-to-verify spine · one review lens"]
    C -->|Substantial| F["full spine with clarify · 4R review"]
```

### 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**:

```text
<!-- 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`.

::: tip 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](/harness/guardrails) 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](/features/review).
- **Task-status honesty** — a task is only `done` once its acceptance scenarios pass under `verify`, not merely because a step ran.

## Next steps

- [Adversarial Review](/features/review) — the review depth governance selects.
- [The enforcement doctrine](/harness/overview) — governance as an advisory Guide among enforced Sensors.
- [The Workflow](/guide/workflow) — the spine each tier walks.
- [Commands](/guide/commands) — the phases governance routes between.