NIST AI Risk Management Framework 1.0 — alignment mapping
This page is generated from the requirement table the AiSSAY engine ships for this framework. When the engine produces an evidence pack, each row below gets a status computed from the operator's own records at that moment. This page shows the table, not anyone's results.
Informational mapping prepared by the operator's own tooling. Not a legal opinion, not a certification, and not a substitute for advice of counsel. It organizes the operator's records against the cited requirements; whether those records satisfy the requirements is a determination for the operator, counsel, and the examiner.
NIST AI RMF is a voluntary framework. No NIST certification exists and none can be claimed; the accurate public statement is that the operator ALIGNS with the framework, self-assessed, with this mapping regenerable from the evidence store at any time.
The requirement table
11 rows: 7 mechanism, 3 organizational, 1 named gap
| Requirement | Mechanism, duty or gap | Type |
|---|---|---|
| GOVERN 1.1–1.4 — policies, accountability structures, and risk tolerance documented across the AI lifecycle | organizational: written AI governance policy naming AiSSAY records as the evidence mechanism | organizational |
| GOVERN 2.1 — roles and responsibilities for AI risk are defined | PARTIAL, and not by software. Records name a reviewer where one countersigned, and the gate names who may clear a held action — but the system has no roles, no permissions and no notion of who is entitled to do what. Defining accountability is an organizational act; the store can only record it after the fact. | organizational |
| GOVERN 4.3 — incidents and errors are shared and documented | sealed records of failures, capture-gap records, and the acknowledged-fork mechanism: incidents become chain entries, never emails | mechanism |
| MAP 1.1/2.3 — context, purpose and assumptions of AI use documented | every record carries the task mandate, the agent's stated assumptions, ambiguities and validity conditions | mechanism |
| MEASURE 2.5 — AI system performance monitored with metrics | reconciliation findings, deliverable coverage, and drift analysis per task shape, computed per run | mechanism |
| MEASURE 2.7(a) — adversarial evaluation of the AI system | honeypots, forged-record challenges, injection scanning and cross-model adjudication run on every measured run | mechanism |
| MEASURE 2.7(b) — security and resilience of the deployed system | PARTLY IMPLEMENTED, and the parts are named. Adversarial testing here evaluates the AI's account of its work, not the security of the software carrying it. On the software: dependencies are scanned at release with an age check, a narrow static checker runs over this tree, and the parsers that read outside input are fuzzed — each proved against a planted defect rather than trusted. There is still no penetration test and no third-party review of the cryptography. | named gap |
| MEASURE 2.8 — transparency and accountability records maintained | append-only hash chain, complete access log, external anchoring | mechanism |
| MEASURE 3.1–3.3 — risks tracked over time; measurement itself is assessed | the instrument profile: a signed, versioned ledger of what the checker learned, stamped on every record it judged | mechanism |
| MANAGE 2.3/2.4 — mechanisms to respond to and recover from incidents | PARTIAL. Ledger restoration, fork diagnosis, capture-gap sealing and legal hold are recovery MECHANISMS and they work; who is paged, within what time, and who decides to invoke them is an incident response procedure no software supplies. | organizational |
| MANAGE 4.1 — post-deployment monitoring with human oversight | needs-review flagging, reviewer countersigns feeding calibration, and pre-run briefings from verified corrections | mechanism |
How a status is earned
- Evidenced
- a deterministic check ran against your records and the counts support the row. A store holding no relevant records reads unevidenced — a true statement, not a passing one. Empty never counts as clean.
- Delegated
- the mechanism is enforced by a system you already trust — a store sealed by your own key manager delegates access control to it, and the pack says the enforcing log is your key manager's, not ours. The pack names the endpoint the key manager was reached at. An AWS endpoint other than AWS's own default for the region reads delegated to that endpoint, with a request that you confirm it is your key management service. One backend — AWS KMS — has run against the real AWS KMS service; no other backend has.
- Test seam
- sealed by an in-process test backend — a stub, or a stand-in for the AWS client — and the status names which. No key manager enforces access. The seam is built and tested, and the pack refuses to call that delegation.
- Partially evidenced
- the mechanism is built and some of your runs carry its evidence, but not all — usually because they were sealed before the mechanism existed. The pack says how many runs are in each group, and never counts the missing ones as passing.
- Organizational
- the requirement is a procedure only people can perform. The pack names it as yours instead of dressing a policy up as a mechanism.
- Named gap
- the pack cannot evidence it — either the mechanism is not built, or no software can supply it — and it says which. The gap is printed, because a reviewer should read it here rather than discover it.
No status is typed in by hand: every status is recomputed from the store each time a pack is produced, the requirement and mechanism text is written and reviewed as part of the engine, and the dependency evidence comes from our release scan. A failing mechanism can never be read as evidence that the control works.