NIST AI 600-1: Generative AI Profile (2024)
Lifecycle risk management, provenance, testing, information integrity, security, and human-AI configuration.
Open authoritative sourcePresentation 01 | Spatial architecture map
Architecture
and Intent
The system diagram is only half the architecture.
Most teams can draw the AI stack.
They can show me the chat interface, the model, the object store, the vector database, the retrieval path, the orchestration framework, the APIs, and a respectable collection of vendor logos connected by arrows.
Good. I need that diagram.
Now show me the one that determines whether the system does the right thing.
Show me what the system is allowed to treat as true. Show me which source wins when two sources disagree. Show me what happens when the answer is ambiguous. Show me who can approve an exception. Show me what the agent may read, recommend, change, publish, or delete. Show me the maximum damage one bad decision can cause. Show me where the system must stop and call a human.
That is the architecture of intent.
The technology architecture tells me what the system can do.
The architecture of intent tells me what it should do, what it may do, and when it must refuse.
You need both.
Capability rises from the stack. Legitimacy descends from intent.
TLDR
Bring me both diagrams.
Your architecture diagram shows what the system can reach. It usually does not show what the system should trust, who has authority, how contradictions are resolved, what may be changed, or how far the consequences can spread.
That missing layer is not a governance appendix. It is architecture.
Every consequential AI system needs two aligned views:
- Technology architecture: components, data, retrieval, tools, identity, security, deployment, observability, and recovery.
- Architecture of intent: objectives, semantics, truth hierarchy, authority, ambiguity, decision rights, mutation rights, evidence, blast radius, escalation, and stop conditions.
A system can be technically elegant, fully connected, and operationally wrong.
01
We keep drawing the easy diagram
Component diagrams answer how the machinery connects. They do not establish which information governs, which instruction outranks another, or whether a technically possible action is authorized.
A vector store is not a truth hierarchy.
A retrieval score is not approval.
A tool permission is not an operating mandate.
02
Architecture has two planes
The technology plane supplies capability.
The intent plane supplies direction, legitimacy, and constraint.
The planes must be separate enough to review independently and connected enough that every material capability has an objective, authority source, action boundary, validation gate, and reversal path.
The binding is the architecture
03
Meaning is not cleanup
The semantic layer cannot be postponed until after the platform is built.
The architecture must define what the organization means by terms such as approved, current, canonical, validated, managed, complete, and authorized.
Those words are operating controls. Treating them as loose prose and asking retrieval to sort it out later is not sophisticated. It is deferred architecture.
Authority distinctions
| Do not confuse | With | Why it matters |
|---|---|---|
| Relevant | Authoritative | Similarity nominates material; authority determines whether it governs. |
| Recent | Approved | Freshness does not create approval. |
| Working copy | Governed record | Convenience does not create canonicality. |
| Recommendation | Decision | Generation does not establish accountability. |
| Tool access | Mutation authority | Capability is not a mandate. |
| Candidate context | Trusted context | Promotion requires review, evidence, and explicit authority. |
04
Authority must be explicit
The system needs contracts for:
- source authority
- instruction precedence
- decision authority
- mutation authority
- exception authority
- context-promotion authority
Capability is not authority.
The fact that an agent can change a repository, database, workflow, or infrastructure component does not mean it has the mandate to do so.
05
Contradiction and ambiguity are normal
Real operating environments contain stale records, scoped policies, overlapping definitions, incomplete evidence, exceptions, and sources that disagree.
The architecture must define whether the system resolves, escalates, quarantines, asks, or stops.
Take the most recent result is not a universal conflict-resolution strategy. Recent can still be wrong, unapproved, out of scope, or nonauthoritative.
Conflict path
Retrieve
Compare authority
Identify scope
Resolve
Escalate or quarantine
Stop
06
The knowledge corpus is production
In a context-as-code environment, policies, decisions, instructions, evidence, relationships, and exceptions can directly shape future agent behavior.
When an agent can rewrite its own operating context, you are no longer managing documentation. You are managing the future behavior of the system.
Candidate context and trusted context must remain separate. Generated material does not become organizational memory because the model wrote it confidently and the file saved successfully.
07
Review consequence, not only access
The security question is not only:
What can this system access?
What can this system cause?
The architecture must bound maximum scope, target eligibility, reversibility, approval, validation, observability, rollback, retained evidence, and stop conditions.
A read-only research worker and a production mutation worker may use the same model. They do not have the same risk.
Action and blast-radius ladder
01
ReadObserve without changing state
Low02
RetrieveSelect context for a bounded purpose
Low03
InferProduce a nonauthoritative interpretation
Moderate04
RecommendPropose an action for accountable review
Moderate05
PrepareCreate a reversible candidate change
Elevated06
ApproveExercise delegated decision authority
High07
MutateChange operational state
High08
PublishExpose information or instructions to consumers
High09
PromoteMake output trusted future context
Critical08
Human judgment belongs at authority transitions
A decorative human-in-the-loop box does not establish accountability.
Human review belongs where authority changes, ambiguity remains material, evidence is incomplete, consequences become difficult to reverse, an exception is requested, or the system proposes modifying its own governing context.
Models can perform increasingly sophisticated work. They do not establish their own organizational mandate or accept accountability for the outcome.
09
Require two architecture views
Every consequential AI architecture submission should include:
- the technology architecture
- the architecture of intent
- an alignment matrix binding each capability to objective, authority, permitted action, evidence, scope, approver, validation, rollback, and stop condition
The first view proves the system can work.
The second helps prove it can be trusted to work in the intended way.
Alignment matrix
| Capability | Intended outcome | Governing authority | Action class | Maximum scope | Stop condition |
|---|---|---|---|---|---|
| Retrieval | Provide relevant context | Source and permission contract | Read / retrieve | Eligible corpus only | Evidence gap or conflict |
| Code generation | Prepare a candidate change | Repository and issue authority | Prepare | Isolated branch or worktree | Validation failure |
| Database update | Change approved records | Application owner and policy | Mutate | Explicit rows / objects | Scope or integrity uncertainty |
| Infrastructure action | Apply an authorized change | Change authority | Mutate | Named target set | Blast radius exceeds limit |
| Knowledge promotion | Add trusted operating context | Content owner and promotion contract | Promote | Exact approved artifact | Unresolved contradiction |
The models will change.
The orchestration frameworks will change.
The fashionable database will change.
The durable advantage is the governed operating context that defines what the organization means, trusts, permits, prohibits, and learns.
The technology architecture makes the system possible.
The architecture of intent makes it valuable.
Draw both.
Evidence spine
Sources that carry the load
OWASP LLM01: Prompt Injection (2025)
Retrieved and external content can carry instructions that alter model behavior; RAG alone does not remove the risk.
Open authoritative sourceOWASP LLM06: Excessive Agency (2025)
Narrow tools, least privilege, downstream authorization, human approval for high-impact actions, monitoring, and rate limiting.
Open authoritative sourceEU AI Act, Regulation (EU) 2024/1689 (2024)
Risk-proportionate human oversight, including interpretation, override, reversal, interruption, and safe stopping.
Open authoritative sourceW3C PROV Overview (Foundational)
Portable provenance model for entities, activities, derivation, versioning, reproducibility, and trust assessment.
Open authoritative sourceVisual production sidecars
Dual-mode teaching prompts
These prompts preserve the architecture thesis across future visual production. The capstone is open by default.
Two-Plane Architecture
Teach the difference between technical capability and governing intent, then show the explicit bindings required between them.
Light prompt
Create a rigorous enterprise architecture teaching infographic on a pure white field. Title: “Architecture and Intent”. Subtitle: “The system diagram is only half the architecture.” Show two horizontal planes. Upper plane labeled ARCHITECTURE OF INTENT with eight nodes: Objective, Semantics, Truth hierarchy, Authority, Conflict rules, Mutation boundary, Evidence, Stop conditions. Lower plane labeled TECHNOLOGY ARCHITECTURE with eight nodes: Interfaces, Models, Retrieval, Data stores, Tools and APIs, Identity, Runtime, Observability. Connect each upper node to relevant lower nodes with precise vertical binding lines. Center statement: “Capability is not authority.” Bottom statement: “The technical stack determines what the system can do. Intent determines what it should do, may do, and must refuse.” Use black typography, restrained red accents, thin technical lines, no vendor logos, no gradients, no decorative AI imagery, no fake dashboard chrome, no external brand marks. Dense but legible 16:9 composition.
Dark prompt
Create a dark-mode enterprise architecture teaching infographic. Near-black field, warm white typography, restrained red and amber accents. Title: “Architecture and Intent”. Subtitle: “The system diagram is only half the architecture.” Show an upper intent plane and lower technology plane, each with eight clearly labeled nodes. Use luminous but restrained binding lines between planes. Center statement: “Capability is not authority.” Bottom statement: “The technical stack determines what the system can do. Intent determines what it should do, may do, and must refuse.” No vendor logos, no neon cyberpunk clichés, no gradients that reduce legibility, no humanoid robots, no fake dashboard widgets. Dense, precise 16:9 teaching composition.
Action and Blast-Radius Ladder
Show that every transition from reading to trusted-context promotion increases authority and consequence.
Light prompt
Design a white-background vertical teaching graphic titled “What can this system cause?” Show a nine-step ladder: Read, Retrieve, Infer, Recommend, Prepare, Approve, Mutate, Publish, Promote into trusted context. Each step must show increasing authority, consequence, approval, evidence, reversibility, and stop requirements. Place “Capability is not authority” across the midpoint. Use black text, red escalation markers, subtle gray structure, and a clear critical boundary before Mutate and before Promote. No vendor logos, no decorative AI imagery, no fake metrics, no gradients. 16:9, enterprise technical field-guide style.
Dark prompt
Design a dark-background vertical teaching graphic titled “What can this system cause?” Show a nine-step ladder: Read, Retrieve, Infer, Recommend, Prepare, Approve, Mutate, Publish, Promote into trusted context. Increase visual intensity carefully as consequence rises. Mark explicit authority gates before Approve, Mutate, Publish, and Promote. Place “Capability is not authority” across the midpoint. Near-black field, warm white text, restrained red escalation markers, accessible contrast, no neon spectacle, no robots, no vendor marks. 16:9 technical field-guide style.
Architecture Review Capstone
Communicate the complete review standard: two architecture views plus an alignment matrix.
Light prompt
Create a complete enterprise AI architecture review capstone on a pure white field. Title: “Bring me both diagrams.” Left third: Technology Architecture with components, data and retrieval paths, identity, security boundaries, deployment, observability, resilience, recovery, and failure modes. Center third: Architecture of Intent with objective, semantic model, truth hierarchy, contradiction rules, decision authority, mutation boundaries, blast-radius controls, human judgment points, evidence, stop, rollback, and escalation. Right third: Alignment Matrix with columns Capability, Intended outcome, Governing authority, Permitted action, Evidence, Maximum scope, Validation, Accountable approver, Rollback, Stop condition. Footer: “The first view proves the system can work. The second helps prove it can be trusted to work in the intended way.” Black typography, restrained red accents, precise technical linework, no vendor logos, no product icons, no gradients, no fake dashboard. Dense, legible 16:9 capstone.
Dark prompt
Create a complete dark-mode enterprise AI architecture review capstone. Title: “Bring me both diagrams.” Three clearly separated regions: Technology Architecture, Architecture of Intent, and Alignment Matrix. Include all required fields for each region. Footer: “The first view proves the system can work. The second helps prove it can be trusted to work in the intended way.” Near-black background, warm white typography, restrained red and amber accents, precise thin linework, accessible contrast. No vendor logos, no product icons, no neon cyberpunk styling, no humanoid AI imagery, no fake dashboard metrics. Dense, legible 16:9 capstone.