NIST AI RMF Rule Engine — Post-Seed Plan¶

Status: Deferred from v0.1. Planned post-seed. Scope owner: Policy + Engine. Source of truth: PRD §16 stack (rule engine), scope-90-day.md:35.

v0.1 ships an EU AI Act Article 6 / Annex III deterministic rule set. A NIST AI RMF rule pack is a parallel rule bundle, not a rewrite of the engine. This doc captures what must be true in v0.1 so the NIST pack can be added without touching the engine core.

Why it is deferred¶

The 90-day scope is provider-first and EU-AI-Act-first because that is where the regulatory deadline pressure and the design-partner pull live. NIST AI RMF is voluntary and primarily relevant for US providers; it is a parallel framework, not a substitute. Building it before the EU pack stabilizes risks two underbaked packs instead of one credible one. The seed bar is "EU AI Act, deterministically gated, with design-partner activation," and that does not require NIST.

Architectural preconditions v0.1 must preserve¶

These are the invariants the v0.1 build must hold so the NIST pack can be added later as a swap-in policy bundle. Each is something that would force a rewrite if violated.

Precondition	Owner phase	Why it matters
Rule engine consumes versioned policy bundles, not hard-coded rules	Phase 10	A NIST pack is just another bundle ID and version
`compliance_target` on `SystemManifest` is an open enum, not hard-coded to `eu_ai_act`	Phase 1–2	The manifest must already accept `nist_ai_rmf` (or composite targets) without a schema migration
`RiskAssessment` carries `policy_bundle_version` and is framework-agnostic in shape	Phase 10	Per-framework rationales travel through the same evidence path
Control IDs are namespaced (`eu.ai_act.art6`, not `art6`)	Phase 10	NIST control IDs (`govern`, `map`, `measure`, `manage` families) coexist without collision
Annex IV dossier generator is one of N output adapters, not the only output	Phase 12	NIST RMF profiles render through a different adapter against the same evidence
Compliance mapping table in the codebase is a data file, not literals	Phase 10	New mappings ship as bundle data, not code changes

If a v0.1 PR would violate one of these, raise a change-request per scope-90-day §change-control.

Scope when it ships¶

In scope:

NIST AI RMF 1.0 control families: Govern, Map, Measure, Manage — encoded as deterministic checks where the underlying control is testable from manifest + evidence.
NIST profile generator: an output adapter that renders a NIST RMF profile document from the same evidence ledger that produces Annex IV.
Mixed-target manifests: compliance_target: [eu_ai_act, nist_ai_rmf]; the engine runs both packs and emits per-framework status artifacts.
Gold-set regression fixtures for the NIST pack at parity with the EU pack (>=99% deterministic match on the gold set).

Out of scope (intentional):

Probabilistic or LLM-based interpretation of NIST guidance. The pack stays deterministic; subjective controls are emitted as HITL prompts with a structured questionnaire, not auto-resolved.
US state-level AI laws (NYC AEDT, Colorado AI Act, etc.) — those are separate packs, scoped later.
Cross-framework "single score" aggregation. Each framework reports independently; combining them is a customer choice, not a product opinion.

Milestones (indicative, post-seed)¶

N0 — Pack scaffolding: bundle format reused; control ID namespace claimed; gold-set fixtures stubbed.
N1 — Govern + Map families deterministic; profile adapter renders subset.
N2 — Measure + Manage families deterministic; gold-set parity with EU pack; first design-partner running mixed-target CI gates.

Exit gate for "GA": gold-set >=99%, profile adapter passes schema validation, at least one US design partner runs the NIST pack in CI for 4 consecutive weeks.

Open questions¶

Whether NIST AI 600-1 (Generative AI Profile) ships in the same bundle or as a sub-pack.
Whether the profile adapter targets a community schema or the customer's auditor template.
Mapping table strategy when EU and NIST controls overlap (shared evidence, separate rationales).