Sealing, rules, and the method.

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

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.