# ADR-0031: sovereign engineering evidence for regulated environments — narrow the wedge, never claim compliance **Date**: 2026-07-17 **Status**: accepted **Deciders**: Thibault Souris (maintainer) **Method**: decision-loop — grounded in a four-agent investigation (runward-in-regulated fit, regulated-OSS adoption requirements, the FDE market, competitor posture), cross-read against the compliance guardrails (ADR-0015/0016) and the vendor-neutral / never-a-runtime invariants, challenged against the "become a compliance validator" temptation, durable position ## Context "Can runward be used in a regulated environment?" is now a first-order question, because the market runward addresses — teams shipping and governing agentic systems, on the FDE method — increasingly overlaps regulated sectors (finance, health, public, defence), and because ~95% of enterprise GenAI pilots die at the *ship / govern / run* stage that runward exists to hold. The investigation returned a clear, honest picture: 1. **runward is usable in regulated environments today — as a wedge, not as a validator.** It produces deterministic, non-LLM, replayable *engineering evidence* (decision → ADR → conformance manifest → OSCAL) that *feeds* an ISO/IEC 42001 programme, a NIST AI RMF profile, or the EU AI Act technical documentation (art. 11 / Annex IV). It never confers compliance. The self-imposed guardrails (audit-*ready* not audit-grade; *feeds/supports* not *satisfies*; security-only by default, regulation as an optional lens — ADR-0015/0016) are honest and defensible, and this ADR keeps them intact. 2. **Being local is a structural advantage, not a limitation.** runward runs in the operator's own repository, emits no data, hosts nothing, calls no network. That makes the bulk of vendor due-diligence (TPRM) *moot*: SOC 2 / ISO 27001 of a host, a DPA / GDPR art. 28 processor agreement, sovereign hosting, service pen-tests, vendor continuity — all evaluate a third party that *holds* the data. Here there is no third party in the data flow. The review collapses onto **artifact integrity** and **project health**, where runward is already strong (OIDC trusted publishing + SLSA provenance, OpenSSF Scorecard, network-isolated core tests, SHA-pinned CI, SECURITY.md, CODEOWNERS, MIT). 3. **Two kinds of gap.** *Reducible* (in our hands): no SBOM published; no one-page "no data flow" vendor sheet to short-circuit the SaaS questionnaire; the MIT-tool / CC BY-ND-doctrine split is not spelled out for a regulated buyer; the OSCAL ingest path is documented but never exercised. *Structural by design* (must be named, never hidden): no runtime record-keeping (EU AI Act art. 12 stays the operator's), evidence is point-in-time (rerun in CI), single maintainer, MIT "AS IS" with no SLA. Closing the reducible gaps narrows the wedge — it does not turn runward into something it must not be. ## Decision **runward positions itself as sovereign, deterministic engineering evidence for regulated adoption, and closes the reducible adoption frictions — while remaining, by design, a wedge that feeds a compliance programme rather than a validator that confers compliance.** Concretely: - **Supply-chain artifacts.** Every release publishes a CycloneDX **SBOM**, attested (SLSA build-provenance attestation for the SBOM) and attached to the GitHub Release, alongside the existing npm provenance. No separate cosign step: the npm `--provenance` attestation *is* a Sigstore signature, verifiable with `npm audit signatures`; adding cosign for the same tarball would be redundant ceremony. - **A regulated-adoption reference** (`docs/compliance/regulated-adoption.md`): the "no data flow" vendor-assessment one-pager (what is moot because local, what actually applies), the OpenSSF **OSPS Baseline** alignment, the explicit **licence framing** (MIT tooling is freely reusable; CC BY-ND doctrine may be *used internally* — CC 4.0 permits private adaptation — but redistributed derivatives of the canon are not), and the named limits (no runtime logs, point-in-time, single-maintainer / no SLA, forkability as the bus-factor answer). - **OSCAL credibility.** Keep the NIST-schema validation and byte-golden test in CI, and add a **third-party ingestion proof**: every CI run generates a pack from the reference mission and loads it in **IBM compliance-trestle** (`test/oscal-ingest.py`) — a real compliance tool whose models are generated from the NIST metaschemas. This closes the "validated only against our vendored schema" gap. End-to-end ingestion into a specific GRC *SaaS* remains the operator's verification, not a runward claim. - **Guardrails unchanged.** Still never "compliant / certified"; still "audit-ready supporting evidence"; still security-only default with regulation as an optional versioned lens; still never a runtime. ## Alternatives discarded - **Become a compliance validator** (assert conformity, emit "compliant"). Violates ADR-0015/0016 and the whole honesty posture; it is the exact overclaim the Delve affair punishes. Rejected. - **Add cosign signing of the npm tarball.** Redundant with npm `--provenance` (Sigstore-backed). Effort with no new assurance. Rejected; the real missing artifact is the SBOM, not another signature. - **Pursue an editor SOC 2 / ISO 27001.** Moot for a local, no-data-flow tool with no service to audit; it would signal a SaaS posture we deliberately do not have. Rejected — artifact integrity + forkability are the recognised OSS substitutes. - **Ship a runtime logging layer to satisfy art. 12.** Turns runward into a runtime, breaking the founding invariant. Rejected — the operator supplies runtime logs; runward feeds the design-time file. ## Consequences - **Positive.** A regulated buyer's objections are answerable with artifacts, not promises; the *local / sovereign / no-data-flow* stance becomes a named advantage neither a SaaS nor a runtime governance engine can match. The vendor sheet doubles as a go-to-market asset for FDE-style / integrator buyers. The wedge is narrower and, crucially, *honest*. - **Negative, accepted.** Maintenance cost (SBOM + attestation in CI). The structural limits (runtime logs, point-in-time, single maintainer) remain and are now written down where a buyer will read them — a feature, not a leak. - **On other boundaries.** Reinforces ADR-0015 (regional/regulatory as an optional lens), ADR-0016 (read-only, feeds not satisfies), ADR-0025 (OSCAL as a citable spec). No conflict; this ADR names the *regulated-adoption operating model* those imply, and adds only supply-chain artifacts + documentation. ## Reevaluation trigger (mandatory, dated) Reopen if (a) a named GRC *SaaS* ingest is exercised — beyond the third-party compliance-trestle proof now in CI — such that the remaining operator-verifies caveat can be dropped; (b) runward ever introduces a data flow, telemetry, or a hosted surface — then the entire SaaS due-diligence set reapplies and this ADR is void; or (c) a regulator recognises (or rejects) OSCAL component-definitions as design-time evidence in a way that changes the claim. **Trigger set on**: 2026-07-17 · **Watched via**: FedRAMP OSCAL requirements, the EU AI Act technical-file guidance, and the OSPS Baseline revisions. ## References - [ADR-0015](ADR-0015-regulatory-conformance-as-a-regional-profile.md), [ADR-0016](ADR-0016-runward-compliance-evidence-pack-assembler.md) — the compliance guardrails this preserves. - [ADR-0025](ADR-0025-oscal-mapping-published-as-a-citable-spec.md) — the OSCAL mapping this documents an ingest path for. - `docs/compliance/regulated-adoption.md` — the vendor sheet + OSPS alignment + licence framing this ADR introduces. - The four-agent investigation (2026-07-17): regulated fit, regulated-OSS requirements, the FDE market, competitor posture.