# NIST AI 100-1: What the Framework Requires October 2026

> NIST AI 100-1 guide for October 2026 covering the AI RMF Core functions, trustworthy AI characteristics, and alignment implementation steps.

Published: 2026-10-29

In late September 2026, researchers at Glow Security reported that AI coding agents, while preparing screenshots for code reviews, published more than 13,000 internal images from more than 300 organizations, including customer billing records and unreleased product features, to public GitHub repositories, mostly under employees' personal accounts (AI Incident Database, [Incident #1734](https://incidentdatabase.ai/cite/1734/)). The task was routine; the damage occurred at the publish step. Logging records the exposure after the fact. Preventive controls, such as repository access restrictions or publication-time authorization, can stop sensitive images from becoming public. NIST AI 100-1 organizes AI risk management into four functions: Govern, Map, Measure, and Manage. Together, they assign accountability, measurement, and a documented response before an output causes harm. The framework is voluntary, but a GSA contract clause finalized in September 2026 and at least one state financial-examiner framework already reference it.

**TLDR:**

- NIST AI 100-1 is voluntary US guidance, but a GSA contract clause issued in September 2026 and effective October 19 incorporates the framework's Appendix A task categories into subcontractor requirements for certain LLM procurements.
- Per Ankura's summary, the AI RMF Core organizes risk management into four functions: Govern, Map, Measure, and Manage across 19 categories and 72 subcategories.
- A recommended starting sequence is to build Govern infrastructure first; starting with Measure before ownership and escalation paths exist produces data no one acts on.
- NIST AI 600-1 (July 2024) extends the base framework with 12 generative AI-specific risk categories and suggested actions organized by AI RMF subcategory.
- Openlayer includes NIST AI RMF among its pre-built framework mappings, with CI/CD gates that block deployment when a configured threshold is breached, such as groundedness below 85% or a demographic parity gap above 5 percentage points.

## What is NIST AI 100-1? {#what-is-nist-ai-100-1}

NIST AI 100-1 is the publication number assigned to the [AI Risk Management Framework (AI RMF 1.0)](https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf), published by the National Institute of Standards and Technology in January 2023. The two names refer to the same document: when "NIST AI 100-1" appears in a contract, procurement requirement, or audit checklist, it means the AI RMF.

The framework is voluntary guidance, not a binding regulation. Procurement and supervisory practices are increasingly shaping its influence. A GSA contract clause issued September 28, 2026, and effective October 19, references NIST AI RMF task categories for certain LLM subcontractor requirements. Organizations selling to government or operating in regulated industries may also be asked to demonstrate alignment.

## Why was NIST AI 100-1 created? {#why-was-nist-ai-100-1-created}

Traditional software failures often produce recognizable errors, such as exceptions, outages, or failed queries. AI systems introduce additional failure modes that may be harder to detect. A model can pass every pre-deployment test and still hallucinate under live traffic, drift silently as input distributions shift, or produce outputs that are technically correct but discriminatory in practice. Before 2023, no widely adopted US framework gave industries a shared vocabulary for any of this.

That gap is what NIST AI 100-1 was built to close. NIST developed the framework in collaboration with the private and public sectors, through a request for information, draft versions, and workshops. Teams building out a full [NIST AI RMF implementation](https://www.openlayer.com/blog/nist-ai-rmf-implementation-guide) plan often start with this framework.

## The two-part structure of the document {#the-two-part-structure-of-the-document}

Part 1 frames the problem: how to think about AI risk, who the framework applies to, and what it means for an AI system to be trustworthy. Part 2 is where the practical work lives. That's the AI RMF Core, which defines four functions (Govern, Map, Measure, Manage) teams use to actually manage risk.

The framework spans the full AI lifecycle, from initial problem framing through decommissioning, and is deliberately agnostic about both technology and use case. It applies to traditional ML models, LLM applications, and agentic systems, and to sectors such as healthcare, financial services, and the public sector.

## The seven characteristics of trustworthy AI {#the-seven-characteristics-of-trustworthy-ai}

NIST's framework identifies seven properties that trustworthy AI systems should exhibit. These are sociotechnical properties to balance based on a system's context of use, not sequential steps. NIST's Measure function uses quantitative, qualitative, or mixed-method tools and methodologies to analyze, assess, benchmark, and monitor AI risk, which is how a team tests a system against these properties.

| Characteristic | What it means in practice |
| --- | --- |
| Valid and reliable | The model performs as intended across conditions and over its lifetime: on the test set and under real traffic and edge cases |
| Safe | The system does not endanger human life, health, property, or the environment; risks are assessed before deployment and monitored after |
| Secure and resilient | The system resists adversarial examples, data poisoning, and exfiltration of models, data, or IP, including LLM-specific cases like prompt injection and jailbreaks, and degrades gracefully under attack |
| Accountable and transparent | Appropriate teams and individuals hold documented responsibility for the system's behavior (naming one accountable person per system is a recommended practice), and individuals interacting with the system have access to appropriate information about how decisions were made |
| Explainable and interpretable | The mechanisms behind the system's operation can be represented (explainability), and its outputs have clear meaning in their intended context (interpretability) |
| Privacy-enhanced | Practices safeguard autonomy, identity, and dignity. Privacy-enhancing technologies and data minimization (such as de-identification and aggregation) support the design, and AI can create new privacy risks through inference about individuals. For LLM systems, PII leaking through outputs or logs is a practical example. |
| Fair with harmful bias managed | Harmful bias and discrimination are managed across systemic, computational and statistical, and human-cognitive sources; metrics and thresholds are chosen for the system's context of use |

NIST treats valid and reliable as the base, a necessary condition of trustworthiness. Beyond that base, no characteristic automatically outranks the others, and optimizing hard for one often creates tension with another. NIST adds that accountability and transparency relate to every other characteristic. A highly explainable model may expose information that undermines privacy. NIST also notes that privacy-enhancing techniques can reduce accuracy under conditions such as data sparsity. NIST is explicit that these tradeoffs require active judgment, not a fixed formula.

[A clean, modern infographic-style illustration showing seven interconnected hexagonal shapes arranged in a honeycomb pattern, each a distinct color — deep blue, teal, indigo, emerald, amber, slate, and violet — glowing softly against a dark navy background. The hexagons are connected by thin luminous lines suggesting balance and interdependence. Each hexagon contains a simple geometric icon: a shield, a lock, a scale, an eye, a gear, a fingerprint, and a checkmark.](https://cdn.sanity.io/images/m9qfap23/production/92ac4852557c448b08205b89427bd73ef72f661c-1586x992.png?w=1400&fit=max&auto=format)

## The four core functions: Govern, Map, Measure, Manage {#the-four-core-functions-govern-map-measure-manage}

Ankura's summary of the framework says the AI RMF Core organizes risk management into four functions, with 19 categories and 72 subcategories. These are iterative practices applied across the AI lifecycle. Although the functions aren't sequential phases, a model update in production triggers Measure and Manage without restarting Govern from scratch.

[A clean, modern circular diagram showing four interconnected segments representing an AI risk management lifecycle: Govern, Map, Measure, and Manage. Each segment is a distinct color — deep blue, teal, indigo, and slate — arranged in a continuous loop with subtle directional arrows between them, suggesting an iterative cycle.](https://cdn.sanity.io/images/m9qfap23/production/1c1b60a46390a68191af3f609aa7f125e253c433-1254x1254.png?w=1400&fit=max&auto=format)

- **Govern** sets the foundation: organizational policies, roles, accountability structures, and risk tolerances.
- **Map** translates organizational context into system-level risk. Teams categorize intended use, identify affected parties, and classify failure modes. That work includes determining, for instance, whether a credit-scoring model falls under a [high-risk AI system](https://www.openlayer.com/blog/high-risk-ai-systems-eu-ai-act-guide) category.
- **Measure** turns risk into evidence through bias testing, groundedness evaluation, adversarial robustness checks, and drift detection. The output is documentation an auditor can inspect.
- **Manage** acts on what Measure surfaces. Risks crossing defined thresholds get responded to: deployment gets blocked, a model gets retrained, or a human reviewer gets looped in.

### The Govern function

Govern sits underneath the other three functions. Strip it out and Map, Measure, and Manage have no policy to execute against; they produce data without any organizational commitment to act on it.

Govern calls for integrating risk management into organizational decision-making, not documenting it separately. In practice, that means documented roles for each AI system (NIST calls for appropriate teams and individuals; the recommended practice is to name one accountable person), defined risk tolerances teams can reference when classifying a deployment, and escalation paths that connect technical signals to the people authorized to act on them.

Govern also assigns responsibilities across the full AI lifecycle. A governance structure that only covers pre-deployment review misses most of where risk materializes: in production, under real traffic, after a model update no one formally approved. NIST is explicit that Govern applies continuously, not as a one-time setup step before launch.

### The Map function

Map is where abstract organizational risk tolerance gets translated into concrete system-level questions. Before anything gets measured, a team needs to know what it is measuring and why it matters for this specific deployment.

The function asks teams to define context: who the AI system is intended to serve, who else might be affected by its outputs, what decisions it informs or makes, and under what operating conditions. A fraud detection model deployed within a bank's internal risk team carries a different risk profile than one that generates customer-facing decline decisions, even if the underlying model is identical. That's a distinction that [internal AI risk tiering](https://www.openlayer.com/blog/ai-governance-internal-risk-tiers) is built to capture. Map surfaces that distinction before Measure begins.

Practically, mapping means answering questions teams often skip: Is this system high-risk under the applicable regulatory framework? What failure modes are plausible given the use case? Which demographic groups might be disproportionately affected by errors? Are there third-party components in the pipeline whose behavior the deploying organization doesn't fully control? The answers determine which risks are in scope for Measure and which Manage responses are proportionate.

### The Measure function

Measure is where risk moves from classification to evidence. Teams apply quantitative and qualitative methods to test how well an AI system meets the seven trustworthy AI characteristics identified in Part 1. The aim is a continuous practice that runs through production, not a one-time pre-launch checklist.

The framework calls for selecting appropriate methods and metrics to assess identified risks, evaluating model performance and trustworthiness, and reassessing risks throughout the AI lifecycle. Depending on the use case, teams may use held-out datasets, demographic subgroup analysis, and production monitoring. In practice, teams commonly extend this baseline with groundedness evaluation for retrieval-augmented systems and adversarial red-teaming for prompt injection and jailbreak resistance. No single method covers all seven characteristics. A bias audit shows whether a chosen fairness metric, such as a demographic parity gap, exceeds the team's threshold; it shows nothing about whether the system is resilient to adversarial inputs.

Some organizations treat evaluation as a deployment gate instead of adopting [continuous AI risk monitoring](https://www.openlayer.com/blog/continuous-ai-risk-assessment-guide) as a lifecycle practice. But a model that passes every pre-deployment test can still drift as input distributions shift, degrade after a prompt template change, or begin producing disparate outcomes as user behavior evolves. NIST is clear that Measure applies after deployment too, which means measurement infrastructure needs to run in production.

Each Measure method trades coverage against cost, so treat Measure as a resourcing question as much as a technical one:

- **LLM-as-a-judge evaluation** scales to thousands of daily inferences but requires careful calibration to avoid false positives.
- **Red-teaming** produces high-quality adversarial coverage but demands specialized expertise some teams lack internally.
- **Full demographic subgroup analysis** requires sufficient sample sizes per group, a constraint that creates gaps for low-frequency populations.

### The Manage function

Manage is the action layer. Where Measure produces evidence, Manage decides what to do with it.

The four Manage categories cover ranking and responding to risks from Map and Measure, planning strategies that maximize benefits and minimize negative impacts, managing risks from third-party entities, and documenting and regularly monitoring risk treatments, including post-deployment monitoring plans. Manage does not end at launch.

Ranking forces a choice teams often avoid. A demographic parity gap of 3 percentage points in a low-stakes recommendation engine does not carry the same treatment urgency as the same gap in a credit-scoring model generating adverse action decisions. Map's context work makes that distinction legible; Manage is where it becomes a decision, much as banks rely on [model validation for LLMs](https://www.openlayer.com/blog/sr-11-7-sr-26-2-ai-model-risk-governance) to decide whether a model can be used.

Treatment options range from accepting the risk with documented rationale, to modifying the system, to blocking deployment entirely. NIST is explicit that halting deployment is a legitimate Manage outcome. For a system that fails defined thresholds, Manage calls for an appropriate response based on the risk and its potential impact. An organization may block deployment, require remediation, or accept residual risk within its established tolerance. Each decision should have documented rationale and clear accountability.

Manage controls progress from documentation to logging to alerting to blocking. The first three record or flag a breach, and only blocking stops the action before it completes. Though NIST does not require blocking, the gap between knowing a threshold was crossed and preventing the action can surface in audit findings.

## AI RMF profiles and the generative AI profile (AI 600-1) {#ai-rmf-profiles-and-the-generative-ai-profile-ai-600-1}

Profiles are how NIST adapts the AI RMF to specific sectors, technologies, or deployment contexts without rewriting the base framework. A profile takes the four core functions and maps them against the particular risks, regulatory obligations, and operating conditions relevant to a defined use case, producing a more focused implementation guide without discarding the underlying structure.

The most relevant profile for most teams deploying generative AI today is [NIST AI 600-1](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf), published in July 2024. It extends AI 100-1 with 12 generative AI-specific risk categories (including confabulation, data privacy, and dangerous, violent, or hateful content) and a set of suggested actions organized by AI RMF subcategory. AI 600-1 supplements and does not replace AI 100-1: the base framework governs the overall risk management program, while the generative AI profile adds category-specific actions the base framework is too general to specify.

For teams assessing alignment scope, the practical question is whether a published profile exists for your deployment context. If so, your implementation plan should draw on both documents.

## Is NIST AI 100-1 mandatory? {#is-nist-ai-100-1-mandatory}

Technically, no. NIST AI 100-1 is voluntary guidance: there is no federal statute mandating adoption, no penalty for non-compliance, and no certification body to audit against it.

In practice, that distinction is narrowing. GSA published a proposed GSAR clause in the Federal Register on June 17, 2026 (91 FR 36559) as a notice and request for comments, with comments due August 3, 2026. The clause covers Large Language Model AI systems, not AI systems in general. Per Crowell & Moring's October 2, 2026 client alert, GSA issued a final clause (GSAR 552.239-7001) on September 28, 2026, as a GSA Regulation Deviation, effective October 19, 2026. The final clause applies when LLM functionality is a material feature of the procurement and Government Data is submitted directly to or produced by the LLM. It replaces the four role-based flow-downs with the AI RMF 1.0 Appendix A task categories (AI Design, AI Development, AI Deployment, and Operation and Monitoring) and flows down to subcontractors performing those tasks. The CSBS AI Supervisory Framework, published September 16, 2026, is a discretionary tool for state examiners at financial institutions, built on the NIST AI RMF ([CSBS AI Supervisory Framework](https://www.csbs.org/csbs-artificial-intelligence-supervisory-framework)). Each state decides how much of it to adopt. Banking AI systems also face newer [model risk management updates](https://www.openlayer.com/blog/sr-26-2-mrm-guide-ai-teams). But the framework remains voluntary guidance with no certification body behind it.

NIST describes AI RMF 1.0 as a living document, with a review involving formal input from the AI community expected no later than 2028. NIST states that AI RMF 1.0 is being revised as part of the White House AI Action Plan.

## How NIST AI 100-1 compares to the EU AI Act and ISO 42001 {#how-nist-ai-100-1-compares-to-the-eu-ai-act-and-iso-42001}

NIST AI 100-1 is voluntary US guidance with no enforcement mechanism. The EU AI Act is binding law: breaching provider and deployer obligations, including those for high-risk systems, carries fines up to €15 million or 3% of global annual turnover, whichever is higher, under Article 99(4), and prohibited AI practices carry fines up to €35 million or 7% of global annual turnover, whichever is higher, under Article 99(3) ([Article 99 penalties](https://artificialintelligenceact.eu/article/99/)). [ISO 42001](https://www.openlayer.com/blog/iso-42001-ai-management-systems-guide) sits between them as a certifiable management system standard that an accredited body audits you against, producing a certificate procurement teams request.

### Where they overlap

Inventory management, named accountability, risk assessment, data governance, evaluation, and ongoing monitoring appear across all three. Building AI RMF Govern and Map infrastructure also lays the groundwork for both ISO 42001 clause compliance and [EU AI Act risk-management](https://www.openlayer.com/blog/eu-ai-act-risk-management-system-requirements) documentation under Article 9. Teams that start with AI RMF may already have produced some of the artifacts an ISO 42001 auditor asks for, though ISO 42001 also requires items AI RMF does not produce, such as a documented AI policy, objectives, management review, an internal audit program, and a Statement of Applicability.

### Where they diverge

The instruments split on what you must prove and to whom. AI RMF guides voluntary risk management practices, including documentation, measurement, and risk treatment. ISO 42001 establishes requirements for a certifiable AI management system. The EU AI Act establishes binding legal obligations with named articles, [conformity assessment requirements](https://www.openlayer.com/blog/eu-ai-act-conformity-assessment-requirements-process-guide) under Article 43, and enforcement by national authorities. Neither AI 100-1 nor ISO 42001 satisfies EU AI Act obligations on its own. Binding law requires satisfying specific article-level requirements that voluntary frameworks only partially cover, so some teams build a [unified AI compliance program](https://www.openlayer.com/blog/eu-ai-act-nist-rmf-iso-42001-compliance-program) that covers all three.

## Practical implementation: applying AI 100-1 across the AI lifecycle {#practical-implementation-applying-ai-100-1-across-the-ai-lifecycle}

The gap between reading AI 100-1 and implementing it is where programs often stall. The framework is designed to be applied in varying degrees and capacities, with no mandated starting point, required sequence across the four functions, or universal threshold across industries. NIST states that the Core's actions "do not constitute a checklist, nor are they necessarily an ordered set of steps."

A reasonable starting sequence, not a sequence NIST mandates: build Govern infrastructure first (ownership registry, risk tolerance definitions, escalation paths). NIST's Core notes that after governance is in place, most users would start with the Map function, then use Map to classify existing AI systems before adding new ones. Measure and Manage can begin in parallel once you have at least one system mapped and a threshold defined for what triggers a response. A common mistake is starting with Measure (running bias audits and adversarial tests) before Govern has confirmed who owns the results and what happens when something fails.

Multi-vendor portfolios create a specific complication the framework explicitly acknowledges. When your deployment uses a third-party model, a vendor-supplied retrieval layer, and an orchestration framework you didn't build, Map requires documenting which components you control and which you don't; your Manage response options are narrower for the parts you don't own.

Resource constraints around Measure are real:

- **Demographic subgroup testing:** requires sufficient sample sizes per group, producing coverage gaps for low-frequency populations.
- **Red-teaming:** requires adversarial expertise some internal teams lack.

Treat Measure scope as a resourcing decision made at Map time, not an afterthought once deployment is approved.

## How Openlayer supports NIST AI 100-1 alignment {#how-openlayer-supports-nist-ai-100-1-alignment}

Openlayer includes NIST AI RMF as one of its pre-built framework mappings. The mapping connects evaluation results and monitoring evidence to the framework's requirements, replacing manual documentation cycles with continuous risk assessment and automatic evidence capture. Openlayer unifies governance, risk management, and enforcement in one platform. The same test definitions support evaluation, monitoring, and runtime enforcement, which reduces the need to recreate controls at each lifecycle stage.

The Measure function maps to Openlayer's pre-deployment evaluation layer and production monitoring: over 175 pre-built automated tests cover accuracy, groundedness, bias across demographic subgroups, prompt-injection resistance, and PII detection, and the same metrics keep running once a model is live. These tests produce the evidentiary record auditors inspect: pass/fail results, metric scores, and flagged failure modes, all bound to the deployed model version.

The Manage function's emphasis on documented risk responses is where CI/CD deployment gates apply. When a configured threshold is breached, such as groundedness below 85% or a demographic parity gap above 5 percentage points (illustrative values teams set to match risk tolerance), Openlayer blocks the merge. That blocking step separates enforcement from observation: a hard gate that prevents deployment produces the documented response the Manage function calls for, which a logged alert does not. NIST also permits other treatments, including accepting residual risk with documented rationale, but whatever the treatment, it needs a record and a named owner behind it.

Openlayer's governance intake interface, AI system inventory, and role-based access controls give teams one system of record for the Govern function's accountability requirements: named ownership, escalation paths, and audit trails. Every governance event carries a named actor, timestamp, and before/after delta in an append-only audit log.

Govern also covers work that software supports but cannot replace:

- **Training:** NIST asks that the teams and individuals who map, measure, and manage AI risk are trained for that work.
- **Executive responsibility:** NIST assigns executive leadership responsibility for decisions about AI risk. Software can record the decision, and the accountability belongs to the executive.
- **Team composition:** NIST asks that AI risk decisions are informed by a diverse team. Software can show who signed off, and who is in the room is an organizational choice.

Real-time guardrails close the gap documentation-only approaches leave open. They act at inference time, blocking prompt injections, PII leakage, and unsafe outputs before they leave the API boundary and before an agent's output becomes an irreversible downstream action. CI/CD gates and pre-deployment tests act earlier in the lifecycle.

## Final thoughts on NIST AI 100-1 and AI risk management {#final-thoughts-on-nist-ai-100-1-and-ai-risk-management}

The framework is designed to scale with your program, not to demand perfection upfront. If you want to see where your current AI deployments stand against the four core functions, [talk to the Openlayer team](https://www.openlayer.com/contact).

## FAQ {#faq}

### How does NIST AI 100-1 map to the EU AI Act and ISO 42001: can alignment with one satisfy the others?

No single framework satisfies the others on its own, but they share enough structural overlap that building one program accelerates the rest. NIST AI 100-1's Govern and Map infrastructure produces the ownership registries, risk classifications, and escalation paths that ISO 42001 clause compliance and EU AI Act Article 9 risk management documentation both require, so teams that start with AI RMF may reach an ISO 42001 audit with some of the required artifacts already produced. ISO 42001 also requires items the AI RMF does not produce on its own, including a documented AI policy, management review records, an internal audit program, and a Statement of Applicability. Where they diverge is on enforcement: the EU AI Act imposes binding legal obligations with named articles and fines up to €15 million or 3% of global annual turnover, whichever is higher, for breaching provider and deployer obligations under Article 99(4), while AI 100-1 produces internal governance maturity with no penalty mechanism behind it.

### What's the difference between the NIST AI RMF Measure function and a standard pre-deployment eval checklist?

A pre-deployment checklist is a one-time gate; the Measure function is a continuous lifecycle practice. NIST is explicit that Measure applies after deployment. That means covering drift detection as input distributions shift, groundedness monitoring as prompt templates change, and demographic subgroup analysis as user behavior evolves. A model can pass every pre-deployment test and still produce disparate outcomes or degrade silently in production. The practical consequence: measurement infrastructure needs to run in production.

### How do I implement the NIST AI 100-1 Govern function without starting from scratch on every new AI system?

Build the Govern infrastructure once, then reuse it across deployments. The three components that pay forward most are: an ownership registry with documented roles per system (recommended practice: name an individual, not a team alias; NIST asks only for appropriate teams and individuals with documented roles), a defined risk tolerance document teams reference when classifying new deployments, and escalation paths that connect specific metric signals (a groundedness score falling below threshold, a demographic parity gap widening) to the person authorized to act. Systems registered in that structure get Map, Measure, and Manage applied against a policy that already exists, with no governance design exercise required per project.

### What should I look for in a platform that supports NIST AI 100-1 alignment?

Credo AI and IBM watsonx.governance both map their policy and documentation workflows to the NIST AI RMF, and Openlayer includes a pre-built mapping. Compare them on whether controls enforce or only record. Credo AI's Agent Governor is designed to allow, block, or escalate agent actions, but it is a research preview and not generally available. IBM watsonx.governance documents real-time detection through a REST API and Python library. Openlayer's guardrails, CI/CD deployment gates, and continuous production monitoring are shipped capabilities that cover custom agents, RAG systems, traditional ML, and multiple LLM providers. Whichever vendor you evaluate, look for a blocking control that records each decision against thresholds you configure, and ask to see ongoing testing, monitoring, and runtime evidence that it works.

### What evidence does NIST AI 100-1 actually require teams to produce, and what format do auditors expect it in?

NIST prescribes no audit standard or specific artifact format, but the four core functions imply discrete evidence categories that are practical to produce for a review. Govern produces an ownership registry with named accountability per system, documented risk tolerances, and escalation records. Map produces system-level context documentation: intended use, affected populations, failure mode classification, and third-party component inventory. Measure produces test results tied to the deployed model version, including pass/fail records, metric scores, and flagged failure modes traceable to a specific artifact. Manage produces documented response records: the threshold that triggered action, the decision made, and the named owner who made it. Records generated automatically as a byproduct of the evaluation and enforcement workflow are easier to trace and defend than evidence assembled after the fact from narrative policy statements.