"What is the governance gap, and why does it exist?"	"Technical security (B2-B8) is NECESSARY but NOT SUFFICIENT for enterprise adoption. A CISO does not approve production deployment because a guardrail works — they approve against FRAMEWORKS (NIST AI RMF, ISO 42001, EU AI Act) because those are the instruments auditors, regulators, and insurers read. An agent with a 4% injection rate and no AI BOM / audit trail / policy-as-code layer will not clear enterprise governance — and an agent with weaker controls but a complete governance stack will SHIP FIRST. The budget and board attention follow the governance layer."	c2b::b11::recall
"Name the four core functions of the NIST AI RMF (AI 100-1) and what each asks."	"(1) GOVERN — who owns the risk? what policy applies? (culture, accountability, named owner). (2) MAP — what is the system? what can go wrong? (context, use, risk surface). (3) MEASURE — have we tested it? what is the residual risk? (test, evaluate, verify). (4) MANAGE — what controls are deployed? how do we respond? (mitigate, respond, remediate). The four operate as a CONTINUOUS LOOP, not a linear pipeline — every system is doing all four at all times."	c2b::b11::recall
"Why is the NIST AI RMF 'voluntary in law but mandatory in practice'?"	"The RMF carries NO penalties (it's a voluntary, non-sector-specific framework). Yet it's the de facto US AI governance standard because: (1) OMB M-24-10 requires US federal agencies to implement it — vendors selling to those agencies INHERIT the requirement. (2) Insurers underwriting AI liability policies ask for RMF alignment. (3) Enterprise governance councils map programs against it because it's what their auditors read. Voluntary in law, mandatory in practice."	c2b::b11::recall
"Map the B2-B8 technical controls onto the NIST AI RMF four functions."	"GOVERN → policy-as-code layer (B11.3), scope file + provider_authorization (B0). MAP → threat model (B1), AI BOM (B11.2). MEASURE → injection success rates (B2, InjecAgent SDD-B03), OWASP ASI checklist scores (B9), Microsoft taxonomy chain findings (B10). MANAGE → tool-call governance (B3), sandboxing (B6), observability (B8), incident response (B0). The mapping is the evidence a governance review requests — a working control and a documented mapping are BOTH required."	c2b::b11::recall
"What is the AI BOM (AI Bill of Materials), and how does it extend the SBOM?"	"The SBOM concept extended to AI systems. An agent is software PLUS a model PLUS training data PLUS tools PLUS prompts PLUS external services. An SBOM listing Python packages but not the model version, training-data sources, or MCP servers misses the components an AI ATTACKER actually targets. The AI BOM contains 6 component classes: 3 AI-specific extensions (model, training data, system prompt/config) and 3 SBOM-surface items (tools/MCP, frameworks/SDKs, external services)."	c2b::b11::recall
"Name the six component classes of an AI BOM and which are AI-specific vs SBOM-surface."	"AI-SPECIFIC EXTENSIONS (3): (1) MODEL — provider, id, checkpoint, modality, params, license; (2) TRAINING DATA — datasets, sources, provenance, license, PII status; (3) SYSTEM PROMPT & CONFIG — prompt version, config hash, guardrail versions. SBOM SURFACE (3): (4) TOOLS/MCP SERVERS — names, endpoints, versions, capability scope; (5) FRAMEWORKS & SDKs — the dependency list; (6) EXTERNAL SERVICES — API providers, vector DB, identity, sandbox. The model version is the single most important field (B0: a finding may not reproduce on the next checkpoint)."	c2b::b11::recall
"Why can an agent without an AI BOM not be audited?"	"(1) A vulnerability in a dependency (malicious MCP, poisoned dataset, model version with known jailbreak) CANNOT BE TRACED to the agents that include it — the B4 supply-chain response has no inventory to query. (2) A model-version dispute ('this finding doesn't reproduce') CANNOT BE RESOLVED — no record of which version ran when. (3) A compliance assertion ('we don't use unlicensed training data') CANNOT BE EVIDENCED — no provenance. (4) A change ('we updated the system prompt') CANNOT BE GOVERNED — no version history. The AI BOM is the precondition for every other governance artifact."	c2b::b11::recall
"What is the audit trail, and how does it differ from observability (B8)?"	"The audit trail is the APPEND-ONLY, COMPLETE record of agent decisions, tool calls, approvals, model versions, and policy evaluations — the EVIDENCE that controls are enforced, not just documented. B8's observability is the engineering CAPABILITY; the audit trail is the EVIDENCE that capability produces, formatted for the regulator. The difference is retention, integrity (append-only, hash-chained/tamper-evident), and COMPLETENESS — an observability dashboard that SAMPLES 1% of events is useful for engineering and USELESS for compliance. The auditor reads the complete record."	c2b::b11::recall
"Name the six event classes that must be logged in an agent audit trail."	"(1) AGENT DECISION — timestamp, agent id, model version, decision, rationale. (2) TOOL CALL — tool name, redacted args, result class, outcome. (3) APPROVAL — approval id, approver, policy reference, decision. (4) MODEL VERSION — sampled at decision time (B0 extended to every decision). (5) POLICY EVALUATION — policy id, action, decision (ALLOW/DENY), reason. (6) DATA ACCESS — surface, data class, record COUNT (not content — B0 retention discipline). For compliance: 'a tool call not logged did not happen'; 'an approval not logged cannot be proven.'"	c2b::b11::recall
"What is the load-bearing distinction between 'we have a policy' and 'we can prove the policy fired'?"	"A control documented in a policy is a control the auditor ASSUMES exists. A control evidenced in an audit trail is a control the auditor CAN VERIFY. The gap between the two is the gap between PASSING and FAILING a governance review. The policy-as-code engine (B11.3) closes the gap — every policy evaluation emits an audit-trail entry, and the entry is the evidence. EU AI Act Art 12 and HIPAA § 164.312(b) both require the logs to EXIST, be COMPLETE, and be RETAINED — neither accepts 'we have logging configured.'"	c2b::b11::recall
"What is policy-as-code, and what problem does it solve?"	"A governance policy expressed as MACHINE-EVALUABLE RULES enforced in the harness execution path. It solves the 'policy-in-the-wiki' problem: a policy in a document does nothing at runtime — the agent will do what its tools permit, wiki or no wiki. Policy-as-code makes the policy the INPUT to the harness's enforcement. The lifecycle: POLICY (plain English, Govern) → CONTROL (compiled rule, B2-B8/B11.3) → TEST (B9/B10 verifies it fires) → AUDIT (entry emitted every evaluation). The four form a LOOP, not a pipeline."	c2b::b11::recall
"State the policy → control → test → audit lifecycle, and why it is a loop, not a pipeline."	"Four stages: (1) POLICY — plain English, owned by a named role, a Govern output ('no agent may access prod data without human approval'). (2) CONTROL — compiled to an enforceable rule (matches surface == production_data, requires approval.state == approved). (3) TEST — B9/B10 test verifies the control fires (propose access without approval, assert DENY). (4) AUDIT — evaluation emits {policy_id, action, decision, reason, timestamp}. It's a LOOP because a policy change propagates to control→test→audit; a test failure propagates back to a control fix; residual risk exceeding tolerance goes back to MAP (re-scope) or GOVERN (re-policy). A static policy doc is the loop frozen at stage 1."	c2b::b11::recall
"What does DD-20 IronCurtain contribute to policy-as-code?"	"DETERMINISTIC POLICY COMPILATION. You write policy in plain English in a constitution.md. An OFFLINE LLM pipeline compiles it to deterministic JSON rules. At runtime, enforcement is pure IF/THEN evaluation — ZERO LLM AT RUNTIME. The LLM is a BUILD-TIME tool (annotation, compilation, list resolution, scenario generation, verify-and-repair); the runtime enforcement is machine-certain. This is the architecturally pure policy-as-code pattern: human-readable policy, machine-certain enforcement, connected by a verifiable compilation step. Build fails if the policy can't be verified."	c2b::b11::recall
"What does DD-09 NemoClaw contribute to policy-as-code?"	"The ARCHITECTURAL PLACEMENT: governance BENEATH the agent. NeMo Guardrails sit between the agent and the world, in the harness execution path, where the agent CANNOT REACH them to disable them. The load-bearing principle: IF THE AGENT CAN REACH THE ENFORCEMENT LAYER, A COMPROMISED AGENT CAN DISABLE IT. Policy-as-code inside the agent's process (a tool the agent calls, a system-prompt instruction) is policy-as-code a prompt injection turns off. Policy-as-code in the execution path (the interceptor every tool/model call passes through) survives agent compromise. NemoClaw is the production reference for governance done right."	c2b::b11::recall
"What is default-deny in a policy engine, and why does it matter?"	"A policy-engine design where an action NO RULE MATCHES is DENIED (not allowed). The failure mode of a missing policy is SAFETY, not openness. Contrast with default-allow, where a missing rule becomes a permission — an attacker who finds an action no policy covers gets it for free. The B11.3 engine implements default-deny: an unmatched action returns (DENY, 'no policy matched; default-deny') AND emits an audit entry. The evidence that no policy matched is captured — so the gap gets noticed and a rule gets added, rather than the action silently proceeding."	c2b::b11::recall
"How does the EU AI Act turn the (voluntary) RMF into mandatory compliance engineering?"	"The AI Act (Reg 2024/1689) imposes CONFORMITY obligations: Annex IV (technical documentation) reads like an AI BOM + risk assessment; Article 12 (logging) reads like an audit-trail spec (complete, retained); Article 14 (human oversight) reads like a HITL control. Where the RMF is a voluntary framework, the AI Act is the RMF MADE MANDATORY — the regulation with teeth. An agent in the EU market must satisfy these engineering requirements; the AI BOM and audit trail (B11.2) are the artifacts that satisfy Annex IV and Art 12."	c2b::b11::recall
"What is ISO/IEC 42001:2023, and how does it relate to the RMF?"	"The certifiable AI MANAGEMENT SYSTEM standard — the ISO 9001 equivalent for AI. Covers AI policy, roles, risk treatment, continual improvement. Where the RMF is a voluntary framework, 42001 is a CERTIFIABLE standard (some enterprises/regulators treat certification as a procurement requirement). 42001 and the RMF are DESIGNED TO INTEROPERATE — an RMF-aligned program is most of the way to 42001. Use 42001 when certification is required; use the RMF as the default framework to map to."	c2b::b11::recall
"An agent has a working guardrail but no AI BOM, no audit trail, and no policy-as-code layer. Will it clear enterprise governance review?"	"NO. A governance review is not a re-test of technical controls — it is a request for EVIDENCE that controls map to the four RMF functions and that the mapping is DOCUMENTED. Without an AI BOM, the supply chain is invisible and undiscoverable. Without an audit trail, the controls cannot be evidenced as ENFORCED (only documented). Without policy-as-code, the policy is a wiki entry with no runtime effect. An agent with WEAKER technical controls but a complete governance stack will ship FIRST — the budget and board attention follow the governance layer, not the guardrail."	c2b::b11::analysis
"Design the AI BOM generator: what does it read, and why must it be generated (not wiki-maintained)?"	"Reads from the RUNNING SYSTEM: model version from the API response, tool list from the harness registry, dependencies from the SBOM tooling (pip-audit / npm audit), system prompt from the config (hashed), training-data sources from the model card, external services from the network egress config. It must be GENERATED because a wiki and reality DRIFT — a dependency updated yesterday, a tool added this morning, a system prompt tweaked at 2am — and the auditor reads REALITY, not the wiki. The generator's output (JSON, NTIA-minimum-elements format extended with AI fields) is the source of truth; the wiki, if any, is a derivative."	c2b::b11::analysis
"A client's governance policy says 'no agent may access production data without human approval.' Translate this into the policy-as-code lifecycle."	"(1) POLICY (Govern): 'no agent may access production data without human approval.' (2) CONTROL (B11.3): a PolicyRule with matches=lambda a: a.surface == 'production_data', decide=lambda a: Decision.ESCALATE (forces human approval). (3) TEST (Measure, B9): propose an AgentAction with surface='production_data' and no approval on file; assert the engine returns ESCALATE; propose the same action with approval.state='approved'; assert ALLOW. (4) AUDIT (Manage): every evaluation of P-001 emits {policy_id='P-001', action_summary, decision, reason, timestamp, model_version} to the append-only trail. The loop: if the test fails, fix the control; if the audit shows repeated ESCALATEs, re-policy."	c2b::b11::analysis
"You discover the policy engine was implemented as a tool the agent calls, rather than an interceptor in the execution path. What is the risk, and what is the fix?"	"RISK: the enforcement layer is INSIDE THE AGENT'S REACH — a prompt-injected agent can call it with a different action, skip calling it, or call a 'disable_policy' tool. This is the DD-09 NemoClaw anti-pattern: policy-as-code the agent can reach is policy-as-code a compromise turns off. FIX: move the engine into the HARNESS EXECUTION PATH (the interceptor every tool call and model call passes through, between agent and world), where the agent CANNOT reach it. The agent proposes actions; the engine evaluates them BEFORE they execute; the agent never sees the engine's internals. This is governance beneath the agent (DD-09) + deterministic enforcement (DD-20)."	c2b::b11::analysis
"The CISO asks: 'How does our agent satisfy NIST AI RMF?' Construct the answer mapping technical controls to the four functions."	"GOVERN: named owner (the AI security lead), documented risk tolerance, the policy-as-code layer (B11.3) where every policy compiles to an enforced rule, the scope file's provider_authorization (B0). MAP: the threat model (B1) documenting the trust surface, the AI BOM (B11.2) inventorying model/data/tools/config. MEASURE: the InjecAgent injection success rates (B2, SDD-B03), the OWASP ASI checklist scores (B9), the Microsoft taxonomy chain findings (B10) — each a measured residual risk, not an assertion. MANAGE: deployed controls (B3 tool governance, B6 sandbox, B8 observability) + the incident-response capability (B0). The EVIDENCE for each function lives in the audit trail (B11.2): every policy evaluation, tool call, approval, and model version is logged. The mapping is not a spreadsheet claim — it is evidenced."	c2b::b11::analysis
"Contrast 'governance theater' with real RMF mapping. What distinguishes them?"	"GOVERNANCE THEATER: a spreadsheet mapping controls to Govern/Map/Measure/Manage with no underlying evidence — a Map claim with no AI BOM, a Measure claim with no test result, a Manage claim with no audit-trail entry. It is paperwork that satisfies a checklist without satisfying a regulator. REAL RMF MAPPING is evidence-backed: every Map claim REFERENCES an AI BOM (a generated artifact, not a wiki), every Measure claim REFERENCES a test result (a measured success rate over N, not an assertion), every Manage claim REFERENCES an audit-trail entry (a logged policy evaluation with a timestamp and model version). The distinction is whether the framework mapping points to ARTIFACTS or to CLAIMS. Auditors read artifacts."	c2b::b11::analysis
"Design the audit-trail store for tamper-evidence. What properties must it have for compliance?"	"(1) APPEND-ONLY — no entry can be modified or deleted once written (an audit trail you can edit is not an audit trail). (2) HASH-CHAINED — each entry includes a hash of the previous entry, so a tamper attempt breaks the chain and is detectable (like a blockchain but simpler; a Merkle tree or a sequential hash chain). (3) COMPLETE — every event class logged for every action, not sampled (Art 12 / HIPAA require this). (4) RETAINED per policy — a defined retention period (e.g., 6 years for HIPAA); destruction is itself logged. (5) SEPARATE from observability — the engineering dashboard (sampled, B8) and the compliance trail (complete, this store) are different systems. The lab has you build a hash-chained append-only writer."	c2b::b11::analysis
"Why does the policy-as-code engine emit an audit entry even for the default-deny (no rule matched) case?"	"Because the default-deny IS the evidence the control fired. If unmatched actions were silently denied without logging, the gap (an action class no policy covers) would be INVISIBLE — no one would know to add a rule. By emitting {policy_id='UNMATCHED', decision=DENY, reason='no policy matched; default-deny'} for every unmatched action, the audit trail surfaces the gap: repeated UNMATCHED entries for a given action shape are a signal that a new PolicyRule is needed. The audit entry makes the governance system self-improving — the loop closes because the gap is observable, not hidden."	c2b::b11::analysis