# Sealing, rules, and the method

Sealing a crossing with --freeze into evidence-lock.json, where the rules and mapping live, the boundaries runward will not cross, and the method workflows.

## Sealing a crossing: `--freeze`

Once a strict gate is fully green you can seal it: `runward check --freeze` (implies `--strict`) hashes the resolvable evidence files into `runward/evidence-lock.json`. runward refuses to seal a red gate — "a seal certifies a crossing, not a hope". A sealed file that later changes or disappears fails `check --strict` until you re-verify and re-seal.

The sealed pack is **audit-ready supporting evidence** that *feeds* a [compliance programme](https://runward.dev/docs/en/compliance/evidence/) (assemble it with `runward compliance <regime>`; the command describes itself as "a readiness draft, never a compliance claim"); acceptance remains the auditor's call — runward makes no compliance claim of its own.

## Where the rules and the mapping live

The CRITICAL/HIGH rules are markdown files under `runward/rules/` (the mission's own copy when present, else the shipped package rules). Each rule's YAML frontmatter carries `impact:`, `phases: [...]`, and an optional `signature:`. The phase mapping is thus a property of the rules themselves, and the `EXPECTED_MAPPED` floors exist precisely so that mapping cannot be quietly stripped to make the gate pass on an empty set. The shipped reference mission (`examples/request-triage/runward/`) is a filled example of all of the above and ships no `rules/` of its own, so it exercises the package-rules fallback.

## Boundaries runward will not cross

- **runward frames; it does not generate.** The agent writes the deliverables and the code; runward reads the mission files and gates them.
- **The gate is deterministic, zero-LLM, zero-network** (the check only reads local files): it verifies that a decision is *traced* and points at something real; it never opens project code, runs a test, or judges implementation quality. The LLM lives in your harness, not in the gate.
- **runward never installs git hooks or writes to `.git/`.** The `--hooks` flag runs only operator-authored hooks from `runward/hooks.json` and is opt-in; adapters shipped under `templates/adapters/` are inert samples the operator wires themselves. An agent can *drive* runward end to end — including performing that wiring on your say-so — but runward does not silently modify your repo.

## The workflows behind the phases

The phases are gated milestones; the *method* your agent follows to reach them ships as workflows under `runward/workflows/`:

- **`method`** is the conductor: it sequences the six phases and delegates the detail of each to its own workflow (`frame`, `architect`, `floor`, `iterate`, `govern`, `handover`, plus `brownfield` for a non-greenfield start).
- **`decision-loop`** governs every structural decision: lock a position before touching the document, challenge and ask before any change, one ADR per decision. Never edit on instinct.
- **`review`** is a read-only expert panel that judges an architecture document for soundness, consistency and editorial quality. It criticises, it never rewrites without validation, and it pairs with `decision-loop` (review provides the eyes, decision-loop the method).
- **`verify`** is the advisory cite-vs-apply pass run above a green strict gate, covered on the [Evidence & integrity page](https://runward.dev/docs/en/concepts/evidence/).

These workflows are guidance the agent reads and applies; the deterministic gate stays the only authority.

## Why this choice

Iterate (phase 4) deliberately has no fixed gated deliverable file, unlike the other five phases. The alternative — inventing a single "iterate.md" deliverable to make all six phases uniform — was rejected because iteration is open-ended: each evolution is its own decision, so the honest artifact is one ADR per switch, subject to the same ADR-ratification and drift checks where those changes land. Uniformity would have forced a hollow file that passes the gate on nothing.

Similarly, the EXPECTED_MAPPED floors exist so the `phases: [...]` rule mapping cannot be silently stripped to make `--strict` pass vacuously — lowering a floor must be a deliberate, tracked edit rather than an invisible way to weaken the gate.

## See also

- [The six phases](https://runward.dev/docs/en/concepts/six-phases/)
- [The six phases in detail](https://runward.dev/docs/en/concepts/six-phases/frame-to-handover/)
- [Evidence & integrity](https://runward.dev/docs/en/concepts/evidence/)
- [Compliance evidence for the system you deliver](https://runward.dev/docs/en/compliance/evidence/)