Adopting runward in a regulated organisation.

Who this page is for

This page answers a different question, for a different audience, than the Compliance evidence page. It is for a TPRM / security / procurement team evaluating whether to adopt runward-the-CLI as a vendor or a dependency in your supply chain. It does not explain how runward produces compliance evidence for a system you build.

If you are producing evidence for your own delivered agentic system (ISO/IEC 42001, NIST AI RMF, EU AI Act) — the readiness drafts, the OSCAL export, runward compliance <regime> — you want the Compliance evidence page instead. This one is only about vetting runward as a supplier.

The posture in one line: runward is a local, open-source CLI. It runs inside your repository, emits no data, hosts nothing, and makes no network call. So the object of a normal vendor review — a third party that holds your data — does not exist here. Hand this page to your reviewer. The reasoning is captured in ADR-0031.

1. Why most vendor due-diligence does not apply

Standard vendor due-diligence is built to assess a third party that sits in your data flow and processes or hosts your data. runward is not in the data flow: it runs on your infrastructure, in your repo, with no runtime, no endpoint, and no transmission. That makes the following controls moot — and it is worth writing "not applicable, and here is why" on the questionnaire rather than leaving them blank, because a form built for SaaS assumes a hosted service that does not exist here.

Pursuing a publisher SOC 2 was explicitly rejected as moot: there is no service to audit. For a no-data-flow tool, artifact integrity and forkability are the recognised open-source substitutes for those SaaS controls.

2. What DOES apply: supply-chain integrity and project health

The real object of review for a local open-source dependency is supply-chain integrity (can you trust the artifact you install) and project health (is the project maintained and governed). runward is strong on both.

Supply-chain integrity

• Provenance — npm OIDC Trusted Publishing plus a SLSA provenance attestation. Verify with npm audit signatures.
• SBOM — a CycloneDX SBOM, attested (SLSA build-provenance) and attached to each GitHub Release.
• Dependency pinning — committed lockfile; every CI action pinned by commit SHA.
• Reproducibility — deterministic build; anyone can re-verify the published artifact.
• CI hardening — core tests run network-isolated (unshare -n): a structural zero-network guarantee, not a claim.
• Continuous posture — an OpenSSF Scorecard workflow.
• No long-lived Actions secrets — publishing uses OIDC trusted publishing, so there is no NPM_TOKEN or PAT to leak.

Project health and governance

• Coordinated disclosure — SECURITY.md (private channel, response window).
• Ownership and cadence — CODEOWNERS, SemVer, CHANGELOG.md, GOVERNANCE.md.
• Bus factor — single maintainer, mitigated by MIT (right to fork) plus a reproducible build. For open-source, forkability is the recognised continuity answer, and it is stronger than a single-vendor SaaS you cannot rebuild.

This maps onto the load-bearing OpenSSF OSPS Baseline controls a regulated buyer looks for: signed provenance, SBOM, SHA-pinned actions, coordinated disclosure, review-by-default, no committed secrets, and a deterministic test suite.

3. Licence framing

• Tooling — MIT. Freely reusable, no copyleft, no viral obligation. The favourable case in a regulated review.
• Doctrine / method — CC BY-ND 4.0. You may use and apply it internally: since CC 4.0, a private adaptation that is not shared is permitted. What the ND clause forbids is redistributing a modified version of the canon. Internal use therefore creates no distributed derivative and raises no obligation; only re-publishing an altered doctrine would.

4. The honest limits, named not hidden

• Not a compliance validator. runward produces audit-ready supporting evidence; it does not confer compliance, certification, or a conformity assessment. Acceptance is always the auditor's call.
• Not a runtime. No runtime logs. EU AI Act art. 12 record-keeping and the post-market / declaration-of-conformity items stay the operator's to supply. runward feeds only the design-time technical documentation (art. 11 / Annex IV).
• Point-in-time. Evidence is derived from repository content, so rerun it in CI. runward check --freeze seals it by SHA-256; later drift reddens the gate until re-verified.
• No SLA, no warranty. MIT "AS IS", best-effort, single maintainer, with forkability as the continuity answer.

5. This posture is itself drift-guarded, and runward never wires itself

Enforced in CI, not just asserted. Every verifiable claim on this page is enforced by a drift guard in CI (ADR-0031). If a control here stops being true — a workflow action un-pinned, a long-lived secret introduced, the SBOM or provenance step removed, the licence changed — the gate reddens before this document can silently go stale. The maintainer keeps the sheet; the gate keeps the maintainer honest.

The authorization boundary. runward never installs git hooks and never writes to .git/ (ADR-0012). The CI adapters are inert samples the operator wires deliberately. "Agent-operable" means an agent can drive the CLI end-to-end, including performing the wiring on the operator's say-so, not that runward silently modifies your repository. That is a deliberate authorization choice, not a missing capability, and it is exactly what a regulated buyer wants from a tool it installs.