Compliance evidence for the system you deliver.

The shape of this whole page is one invariance: a constant universal core, a swappable regulatory lens on top, and two outputs where only one carries the regime label.

Evidence for the agentic system you deliver

This page is for the team building and delivering an agentic system with runward. The purpose is narrow and concrete: turn the mission's own engineering artifacts into audit-ready supporting evidence about the system you are shipping, in a shape your compliance programme can consume. The audience is your delivery team and the compliance, risk or audit people who will read what you hand over.

Evaluating runward-the-tool as a vendor in a regulated organisation is a different question with a different audience. If a TPRM, security or procurement team needs to clear the CLI itself, send them to Adopting runward in a regulated organisation instead.

The guardrails here are properties of the evidence, not of how the tool is hosted:

• It feeds, it never validates. What runward produces supports your compliance work; it is not a compliance validator and never claims to be. The wording is enforced: never "compliant / certified / satisfies", always "audit-ready supporting evidence" and "feeds / supports".
• A draft, never a claim. Every artifact is generated as an incomplete draft that carries a non-negotiable header saying so. It is assembled deterministically from artifacts at rest, with no model call.
• Acceptance is the auditor's call. runward assembles evidence; it does not grade it. Only an accredited body certifies, and the go/no-go is always someone else's decision.

The universal gate and the regime lenses

The gate knows nothing about any regulation

The deterministic gate is universal and knows nothing about any regulation — it verifies traced decisions and rule conformance against the OWASP Top 10 for Agentic Applications (ASI01–ASI10), a region-agnostic security taxonomy. No regulation-specific branch ever enters the decision path. The honest default posture is security-only: it makes no regulatory claim at all.

A regulation is a swappable, versioned lens

A regulation is a swappable framing layer on top of that universal core (ADR-0015). Three lenses ship today:

• ISO/IEC 42001 — the region-agnostic anchor (certifiable, offends no market).
• NIST AI RMF — the US lens.
• EU AI Act (Annex IV) — the EU lens.

This is the whole point: build-time evidence travels almost everywhere that expects governance; what changes across regimes is the citation label, not the artifact. Baking the EU AI Act into the gate was rejected — it would forfeit the US market, age badly as regulations churn, and break the zero-LLM / universal invariant.

Each lens is versioned data (regimes/<regime>@<version>.json), not code. The stable product voice (draft framing, narrative) lives in the CLI's code; each JSON file carries only what tracks a dated external text — clause references, Annex IV rows, the crosswalk, the operator-required list. A regulatory change is a new file, never an edit of a shipped version, so a pack stays re-assemblable against the exact lens its auditor saw. Version strings are date-/zero-pad-shaped so lexicographic order equals chronological, and the default pick is the highest shipped version.

runward compliance <regime> — the command

runward compliance <regime> is a deterministic, read-only, zero-LLM command, outside the gate. It reads the mission's real artifacts at rest and assembles an assessment-readiness draft about the agentic system this mission governs. No model call, no live-state scraping, nothing runs.

Usage and flags:

runward compliance [regime]          # regime: iso-42001 | nist-ai-rmf | eu-ai-act
  -p, --path <path>                  # project directory
  --regime-version <version>         # pin the lens (default: highest shipped, see regimes/)

What it reads (all at rest, in the mission's runward/ directory):

• The craft rules and their OWASP ASI tags. It prefers the mission's own rules/, falling back to the shipped package rules. Files are read in sorted order so the output is byte-identical across filesystems.
• The conformance manifests — the same gated (phase, deliverable) pairs runward check --strict verifies, from one source.
• The ADR journal in runward/adr/, skipping the template, README and DRAFT files.
• Governance-doc presence: governance/threat-model.md and governance/evaluation-rubric.md.

What it writes (to runward/compliance/):

• The human-readable readiness draft <regime>-readiness.md.
• The machine-readable, regime-neutral oscal-component-definition.json.

Both are always refreshed (generated artifacts, force: true).

It requires a mission. The command only runs against a runward/ mission. Exit codes: 0 = draft written; 2 = no runward/ mission found, no/unsupported regime, or unknown mapping version. An agent should treat exit 2 as operator misuse, not a gate failure.

Every draft carries a non-negotiable DRAFT header stating it is a draft, incomplete, not a compliance claim, assembled deterministically with no model call, and that only an accredited body certifies. Each lens also ends with a "Required from the operator / organization (runward cannot produce this)" section — the managerial, legal and organizational parts no tool can assemble from engineering artifacts.

What each lens populates vs. leaves to you

Each lens fills the parts an auditor can read straight from engineering artifacts, and explicitly carves out the parts that are the organisation's to supply.

• ISO/IEC 42001 — populates the Statement of Applicability's implementation-status + evidence columns, the ASI risk-coverage table (feeds clause 6.1.2 / 6.1.3), and the ADR design-decision records. Leaves to the operator: the AI policy (5.2), AIMS scope (4.3), the applicability judgment itself, risk methodology and acceptance, impact assessment, internal audit and management review, and runtime AI event logs (A.6.2.8).
• NIST AI RMF — populates the MEASURE/TEVV documentation and an indicative (not NIST-endorsed) ASI→AI RMF crosswalk landing primarily under MEASURE and MANAGE. The AI RMF is explicitly framed as voluntary guidance with no pass/fail and no certification. Leaves to the operator: all of GOVERN, MAP, the go/no-go MANAGE decision, and profile / risk-tolerance choices.
• EU AI Act (Annex IV) — strong on Point 2 (architecture, validation, cybersecurity) and the design-rationale / change history (the ADR journal is a near-verbatim fit). The draft states it does not satisfy Article 12 runtime logging and is not a signed declaration of conformity. The Annex IV coverage map spells out, point by point, what runward supplies vs. what the provider must supply. Note the dated facts in this lens: high-risk obligations bind from 2 December 2027 (postponed by the Digital Omnibus on AI), while the 2 August 2026 milestone remains real for other obligations (Article 50 transparency, GPAI) but is not the high-risk deadline.

The common thread: applicability, risk acceptance, policy, management sign-off, the declaration of conformity and runtime logs are always required from the operator / organization. No tool can produce them from engineering artifacts, and each draft says so.

The OSCAL 1.2.2 export and what it feeds

Alongside the readiness draft, the command emits oscal-component-definition.json — an OSCAL component-definition, version 1.2.2, titled "the agentic system governed by this runward mission". This is the regime-neutral, machine-readable interop layer so the evidence flows into the GRC / auditor tools runward will never own.

How it is built

• The 10 OWASP ASI categories become 10 implemented-requirements, each targeting an OSCAL control (asi-01…asi-10) sourced from the OWASP Agentic Top 10 catalog. Each requirement also links back to the co-generated readiness draft.
• Implementation-status is derived, never asserted: planned if no rule maps that risk (a gap); implemented only if there is at least one manifest row and every manifest row of every mapping rule is applied; otherwise partial (mapped but deviated / n-a / not yet in a manifest). A rule mapped but not justified yields partial, never implemented. The status aggregates every manifest row across all deliverables, deliberately avoiding first-row order-dependence.
• UUIDs are deterministic — RFC-4122 v5-shaped, derived from a SHA-256 seed, so two runs on the same artifacts produce byte-identical OSCAL with no random UUIDs.
• The lens that framed the pack is stamped into metadata.props as runward-regime-lens (e.g. eu-ai-act@2024-1689); the control structure itself stays regime-neutral.
• The metadata remarks field hard-codes that this is a DRAFT / supporting evidence only — NOT a compliance claim, NOT a certification, NOT a conformity assessment.

What it feeds, and the honest boundary

Because it is a standard OSCAL 1.2.2 component-definition, any OSCAL-aware GRC tool ingests it as-is. The offline proof of well-formedness is schema validation against the vendored NIST schema, with negative controls.

Beyond that, a separate CI job loads the pack into IBM compliance-trestle — a real compliance toolkit used in FedRAMP/NIST workflows whose models are generated from the NIST metaschemas — proving it is ingestible by a genuine independent tool. That trestle job runs in a separate Python job with network for pip install; the core Node test path stays zero-dependency and network-isolated.

End-to-end ingestion into your specific GRC SaaS (RegScale, Paramify, Xacta) is your verification step, not a runward guarantee. The manual ingest procedure — generate, optionally pre-flight against the vendored schema with ajv-cli, import as a component definition, attach the readiness draft as narrative, fill the operator sections — is documented step by step.

Published as a citable mini-spec

The mapping is also published as a versioned, citable mini-spec (docs/spec/runward-oscal-mapping.md, v1.0) plus a CITATION.cff, so a GRC vendor or auditor can implement or critique the mapping without reading runward's TypeScript.

Keeping the regulatory facts honest

runward pins two kinds of fact that live outside the repo and move on their own clock: the OSCAL schema version, and the dated regulatory facts in regimes/*.json. Keeping them honest is a deliberate mechanism, ADR-0032.

The failure ADR-0032 fixes: runward's OSCAL pin had silently fallen two generations behind (still emitting 1.1.2 while NIST shipped through 1.2.2) and no test reddened, because every in-gate guard compares repo to doc, never repo to world.

The decision has two halves:

1. Track the current OSCAL release — bumped to 1.2.2 now. The bump was proven trivial and risk-free: runward's output validates against the NIST 1.2.2 schema, trestle 4.2.0 ingests a 1.2.2-stamped pack, the schema diff removes zero definitions and touches nothing runward emits, and oscal-version does not feed the UUID seeds. Packs previously emitted as 1.1.2 stay valid; no migration is owed. A future bump remains a traced versioned-port human act, never automatic.
2. Watch dated facts out-of-band, never in the gate. A scheduled, non-blocking workflow — .github/workflows/watch-external-facts.yml, weekly (Mondays 06:17 UTC), with network, outside the deterministic gate — compares the pinned OSCAL_VERSION against the latest usnistgov/OSCAL release, and each regimes/*.json reviewBy date against today. On any drift it opens or refreshes a single tracking issue; it never bumps a pin and never fails a build.

The reviewBy dates

The reviewBy dates: EU AI Act → 2026-08-02 (right after the Article 50 milestone), ISO 42001 and NIST AI RMF → an annual 2027-01-01 checkpoint. Crucially, reviewBy is metadata that never enters the OSCAL and never alters the lens content — it records when to re-check, not what the mapping says, so it does not violate the "never edit a shipped mapping" rule.

Why no clock or network in the gate

A clock-driven or network test inside the gate was rejected: it would put wall-clock and network into the deterministic, zero-network critical path — a test that reddens on a Tuesday with no code change is exactly the non-determinism runward exists to ban. The watch runs where non-determinism is harmless: out-of-band, non-blocking, issue-only.

Why OSCAL, not an EU format

This is a deliberate, documented choice. The strategic frame: there is no European (or other) machine format to migrate to.

• EUCS and SecNumCloud are cloud-service certifications. They certify a cloud service provider, not a local developer tool, and structurally cannot apply to a CLI that runs in your own repo with no hosted surface.
• The EU AI Act technical documentation (Annex IV) has no executable / machine format. It is a prose technical file. There is nothing machine-readable to emit as Annex IV. runward instead feeds that prose file via the EU AI Act lens (Point 2, the ADR journal).
• OSCAL is the only mature machine format, and it is gaining non-US uptake — the ECSO OSCAL Task Force and the CRA context — so the sensible bet is to stay on OSCAL and keep it current, not to invent a format. Adopting or inventing an EU machine format was explicitly rejected: none exists as an adopted standard, and inventing one is the opposite of the audit-ready promise.

So the question was never "which format" but "how to keep the OSCAL pin and the dated regulatory wording honest and current over time" — which is exactly what the drift watch above does.