# The boundary: runward never wires itself Wiring the gate is the one thing runward never does autonomously: why that is a deliberate security choice (ADR-0012), and the exact compliance scope. ## The one boundary runward never crosses: wiring the gate ### The apparent contradiction This is the apparent contradiction to resolve head-on: how can runward be "agent-operable end-to-end" while every guide says *you install the trigger manually*? ### The resolution **Wiring the gate into your repo is the single thing runward never does autonomously — and the single thing it does not do even for itself.** `runward wire` detects and prints a recommendation; it "wires nothing — you are the operator's hands (ADR-0012)". runward writes no file into `.git/`, edits no `.claude/settings.json`, registers no CI (ADR-0012 Decision). The adapters are inert sample text under `runward/adapters/` that do nothing until an operator copies them into place. "Agent-operable end-to-end" does **not** mean runward silently mutates your repo. It means an agent can drive every step — including performing the wiring — but the wiring specifically requires the operator's explicit approval. The charter is exact: "Propose it and act only on explicit approval; never wire it silently… you are the operator's hands, and the operator owns the gate". ADR-0012's 2026-07-12 amendment makes this precise: the agent *offers* and the operator *decides* — "the difference is consent: the agent proposes and the operator decides, versus runward acting without the operator's act". ### Why this boundary is a feature, not a missing capability - **No tool silently touching your git or CI.** Auto-installing a hook into `.git/hooks/` or editing a settings file is "surprise execution wired into a repo without the operator's act" — rejected on security grounds. A gate that a tool installs behind your back is exactly the class of foot-gun runward refuses to become. - **The frame must never become a runtime.** A daemon, file-watcher, or runward-managed hook runtime "would each turn runward from a frame into a runtime — the one thing the doctrine forbids it to become". Keeping the wiring in the operator's hands keeps runward a frame. - **Detection stays honest.** ADR-0030 preserves ADR-0012 exactly: "detection informs, the operator's approved gesture wires". runward at most prints the exact command. ### What the CHANGELOG meant Concretely: the CHANGELOG's "install and operate" refers to standing up the mission (`init`) and running the whole chain (`check`, `manifest`, `compliance`, …) autonomously — plus the agent-assisted, approval-gated wiring of the trigger. It never meant runward reaching into `.git/` on its own. There is no contradiction: the manual/approved step is the deliberate consent seam. ## Compliance and scope, stated plainly ### The gate is deterministic and offline The gate is deterministic, zero-LLM and offline: the audit "stays deterministic, zero-LLM, zero-run" — it reads and hashes files, it never runs your code. runward's default lens is engineering craft and security; a regulatory regime is an optional lens, and the CI adapter is the seam where that evidence is produced. ### What the output is, and is not What runward produces is audit-ready *supporting* evidence that feeds or supports a [compliance programme](https://runward.dev/docs/en/compliance/evidence/) (regimes: `iso-42001`, `nist-ai-rmf`, `eu-ai-act`); it does not make a system compliant or certified. The CLI itself frames the output as "a readiness draft, never a compliance claim". That determination is the auditor's. ## Why this choice ### The load-bearing choice and the rejected alternative The load-bearing design choice is that runward never wires the gate itself, even though it is 'agent-operable end-to-end.' The rejected alternative was detection-first auto-wiring: on init or on detecting the harness, silently install the git hook into .git/hooks/ or edit the harness settings file. ### It was rejected on two grounds - **Security:** silent installation is 'surprise execution wired into a repo without the operator's act' — the exact foot-gun class runward refuses to become. - **Doctrine:** a daemon, watcher, or runward-managed hook runtime 'would turn runward from a frame into a runtime — the one thing the doctrine forbids it to become'. ### The chosen model The chosen model keeps wiring as an operator consent gesture that an agent may perform on explicit approval (ADR-0012's 2026-07-12 amendment). Detection (ADR-0030) is layered on top as best-effort and read-only, with wires:false as a machine-checkable invariant, precisely so recognition can never slide into silent action. This makes the boundary a designed consent seam, not a missing capability. ## What comes next ADR-0030 sets an additive, non-breaking follow-on: extend --json coverage beyond check to status, doctor, manifest and compliance as the autonomous driving loop demands each read path. The ADR's dated reevaluation trigger reopens the detection design if: - a cross-harness runtime convention for agent identity emerges (a standard env marker adopted by more than two major harnesses), or - the driving loop needs a read path that has no --json yet still without runward writing a channel itself. ## See also - [Wire the gate](https://runward.dev/docs/en/operating/wire-the-gate/) - [From an AI agent](https://runward.dev/docs/en/operating/from-an-agent/) - [The machine contract: check --json and wire](https://runward.dev/docs/en/operating/from-an-agent/machine-contract/) - [Adopting runward in a regulated organisation](https://runward.dev/docs/en/compliance/regulated-adoption/)