10. AI Context Contract Controls

These cards apply when AI, machine inference, generated evidence, automation, or agents materially affect the decision path. The controls define how AI-assisted evidence and behavior are tested against governed context for the stated decision scope; they do not establish intrinsic model correctness.

AI-001: Binding AI Context Contract Exists

Prerequisites	Pass required: CORE-004.
Specification requirement	Each AI-assisted decision scope shall have a Binding AI Context Contract before AI outputs are relied on for material use.
Why this control exists	AI cannot be governed against vague intent. It requires a concrete context contract.
When this applies	Before AI-assisted evidence, recommendations, or actions are relied on for a material decision scope.
Evidence to inspect	Binding AI Context Contract with identifier, owner/authority, version, scope mapping, and references to the applicable taxonomy, ontology, identity, context, path, vector, Gate, drift, and evidence rules.
Evidence sufficiency	The Binding AI Context Contract must identify the governed semantic, identity, relationship, context, path, vector, Gate, drift, and evidence rules that apply to the AI-assisted decision scope, with the applicable references and version. Insufficient: A system prompt, retrieval configuration, tool list, model instruction, or architecture diagram is not sufficient by itself when the governed context contract does not bind the AI use to the required DACS evidence and control rules.
Assessment procedure	1. Retrieve the Binding AI Context Contract for the stated scope. 2. Verify identifier, owner/authority, version, and scope mapping. 3. Inspect references to every applicable taxonomy, ontology, identity, context, permitted/prohibited path, vector, Gate, drift, and evidence rule.
Control-result determination	Pass: The contract is identified, owned, versioned, and linked to the decision scope. It references applicable Extended Taxonomy, Extended Ontology, Business Identity rules, preserved context, permitted/prohibited paths, vector criteria, Gate criteria, drift rules, and evidence requirements. Fail: AI output is relied on for material use without a contract or the contract lacks required semantic, identity, relationship, context, Gate, or drift constraints.
Common failure modes	• AI use begins with prompts or retrieval but no Binding AI Context Contract. • Contract omits permitted or prohibited paths. • Taxonomy, ontology, identity, Gate, or drift references are out of date. • Contract owner or version is unclear.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-04 - Missing authority; R-12 - Automated or AI-assisted control If AI use begins with prompts, retrieval, tools, or workflows but no Binding AI Context Contract exists: create and version the Binding AI Context Contract before AI-assisted stated use If the contract omits permitted or prohibited relationship or context paths: add the required permitted and prohibited path rules If taxonomy, ontology, identity, Gate, drift, or other referenced evidence is outdated: update the contract references and reassess the affected AI-assisted scope If the contract owner or version is unclear: record the accountable owner and the applicable contract version
Repeatable fix	AI-enabled scopes invoke a standard contract record and change process before production or stated use.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when the AI-assisted decision scope lacks a complete Binding AI Context Contract.
Example	The contract for a claims assistant references approved concepts, identity rules, allowed relationship paths, prohibited paths, Gate criteria, and drift tests.
Non-example	A system prompt is treated as the entire context contract even though governed semantic, relationship, and evidence rules are absent.
Authority and execution	Authority: The AI decision-scope owner is accountable for the Binding AI Context Contract. Referenced semantic, identity, ontology, risk, and other component authorities remain accountable for their respective components.
Retest	Reinspect identifier, owner/authority, version, scope mapping, and every applicable component reference. Confirm the contract governs this AI-assisted use and its effective versions.

AI-002: AI Inputs Conform to the Semantic Contract

Prerequisites	Pass required: AI-001.
Specification requirement	Each material input feature, retrieved field, prompt-supplied variable, tool-returned value, document excerpt, or context element used by an AI-assisted decision scope shall map to the applicable Semantic Contract.
Why this control exists	Material information supplied to AI must be governed and traceable to the applicable Semantic Contract for the stated decision scope.
When this applies	When a material AI input, retrieved field, prompt variable, tool return, document excerpt, feature, or context element influences the decision path.
Evidence to inspect	AI input record, retrieval/prompt/tool context record, taxonomy reference, identity reference where applicable, physical attribution where required, Gate Record, decision-scope mapping.
Evidence sufficiency	The AI-input evidence must show how every material input or context element maps to the applicable Semantic Contract, including approved taxonomy, Business Identity where applicable, physical attribution where required, context rule, and Gate status. Insufficient: Successful retrieval, an authorized API response, a prompt variable, or a document excerpt is not sufficient merely because it was available to the AI. The input must also be governed and eligible for this decision scope.
Assessment procedure	1. Enumerate material AI inputs, including retrieved fields, prompt-supplied variables, tool-returned values, document excerpts, and context elements. 2. Verify that each material AI input or context element maps to approved Semantic Contract evidence, identity where applicable, physical attribution where required, context rules, and Gate status.
Control-result determination	Pass: Each material AI input maps to approved taxonomy, Business Identity where applicable, physical attribution where required, context rule, and Gate readiness state for the decision scope. Fail: Material use of input or context that is unmapped, ambiguous, prohibited, unreviewed, or lacks the required evidence and readiness for the stated use.
Common failure modes	• Retrieved context is assumed valid because retrieval succeeded. • Prompt variables use local meanings. • Tool-returned values lack physical attribution. • Unreviewed documents enter context. • Input Gate status is ignored.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-02 - Ambiguous meaning; R-07 - Unsupported discovery If retrieved context is assumed valid merely because retrieval succeeded: validate the retrieved evidence against the applicable Semantic Contract, identity, attribution, context, and Gate rules If prompt-supplied variables use local or ambiguous meanings: map the material variables to approved governed concepts before use If tool-returned values lack required physical attribution: record the source-level evidence needed to identify and test those values If unreviewed documents enter AI context: keep the documents Quarantined or route them through the applicable controls before material use If input Gate status is ignored: enforce the recorded input readiness state before the AI-assisted decision uses the evidence
Repeatable fix	Retrieval, prompts, tools, and features emit input-evidence records that can be checked before stated use.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material AI input or context element is not yet governed and eligible under the applicable Semantic Contract.
Example	A retrieved customer-status field maps to the approved concept, Business Identity, source field, and Gate state.
Non-example	An agent uses an unlabeled tool response because it was returned by an authorized API.
Authority and execution	Authority: The AI application or workflow owner controls how inputs enter the process. Semantic, identity, and source authorities govern their respective evidence; the responsible decision-scope authority approves input eligibility for stated use.
Retest	Recheck each affected material AI input or context element. Confirm that it maps to approved Semantic Contract evidence, Business Identity where applicable, physical attribution where required, context rules, and Gate status for the decision scope.

AI-003: AI Output Terms Conform to Extended Taxonomy or Are Quarantined

Prerequisites	Recorded result required: ET-016, AI-001.
Specification requirement	Each material term, classification, or concept used in an AI-assisted output shall map to an approved Extended Taxonomy node or be assigned Quarantined before material use.
Why this control exists	AI outputs must use governed business language when they support Defensible Analytics.
When this applies	When an AI-assisted output introduces or uses a material business term, classification, or concept.
Evidence to inspect	AI output record, term extraction or mapping record, taxonomy references for mapped terms, and Quarantined/review records identifying unmapped or unreviewed terms where applicable.
Evidence sufficiency	The output-term evidence must show that every material AI-generated or AI-used term, classification, or concept maps to an approved Extended Taxonomy node for the decision scope, or is explicitly routed to Quarantined review before material use. Insufficient: A generated label or classification is not sufficient because it sounds reasonable, resembles an approved term, or was reviewed informally. Its governed taxonomy mapping or Quarantined status must be recorded.
Assessment procedure	1. Inspect material terms, classifications, and concepts in AI-assisted outputs. 2. Verify that each material term, classification, or concept maps to an approved Extended Taxonomy node for the decision scope or is assigned Quarantined before material use.
Control-result determination	Pass: All material AI output terms map to approved taxonomy nodes for the decision scope or are routed as Quarantined evidence for review. Fail: The output uses material terms, classifications, or concepts that are unmapped, ambiguous, prohibited, or unreviewed as if ready for stated use.
Common failure modes	• Generated labels are accepted without governed taxonomy evidence. • Synonyms are mapped without approved taxonomy evidence. • Novel concepts enter material outputs without Quarantined status. • Output review checks wording but not governed meaning.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-07 - Unsupported discovery If generated labels or concepts are accepted without governed taxonomy evidence: map them to approved Extended Taxonomy nodes or assign them Quarantined before material use If synonyms are mapped without approved taxonomy evidence: use the governed synonym or alias record rather than name similarity If novel concepts enter material outputs without Quarantined status: route them to taxonomy review as candidate evidence If output review checks wording but not governed meaning: evaluate the material term against the approved business meaning and decision-scope boundary
Repeatable fix	Output validation extracts material terms and checks them against the governed taxonomy or a stewardship queue.
Controlled disposition	Disposition reference: D-03, Ungoverned candidate evidence. Use this reference for AI-generated or AI-used terms and classifications that lack an approved taxonomy mapping.
Example	The model generates “Dormant Customer,” which is not approved, so the classification remains Quarantined until reviewed.
Non-example	A new model-generated category is added to an executive report because it sounds reasonable.
Authority and execution	Authority: Taxonomy authority governs output terms and classifications. The AI workflow owner implements the required mapping or Quarantined routing.
Retest	Reinspect the affected AI output terms, classifications, and concepts. Confirm that each maps to an approved Extended Taxonomy node for the scope or remains Quarantined before material use.

AI-004: AI Output Relationships Conform to Extended Ontology or Are Quarantined

Prerequisites	Recorded result required: EO-016, AI-001.
Specification requirement	Each material relationship asserted or used by an AI-assisted output shall map to approved Extended Ontology evidence or be assigned Quarantined before material use.
Why this control exists	AI relationship assertions must be tested, not accepted because they are plausible.
When this applies	When an AI-assisted output asserts, infers, or relies on a material relationship.
Evidence to inspect	AI output record, relationship extraction or mapping record, applicable ontology, vector, orientation, and path-rule references for governed relationships, and Quarantined/review records for unsupported or unmapped relationships where applicable.
Evidence sufficiency	The output-relationship evidence must show that every material relationship asserted or used by AI maps to approved Extended Ontology evidence, including the required relationship type, orientation, vector criteria, and path rules, or is routed to Quarantined review. Insufficient: A model citation, high confidence score, plausible explanation, or retrieved supporting text is not sufficient to establish an AI-generated relationship as ready for stated use when the applicable ontology controls have not been satisfied.
Assessment procedure	1. Inspect material relationships asserted or used by AI-assisted outputs. 2. Verify that each material relationship maps to approved Extended Ontology evidence, permitted orientation, vector criteria, and path rules, or is assigned Quarantined before material use.
Control-result determination	Pass: All material AI output relationships map to approved relationship types, permitted orientations, vector criteria, and path rules for the decision scope, or are routed as Quarantined evidence. Fail: The AI output asserts or depends on an unmapped, prohibited, unsupported, or unreviewed relationship as if ready for stated use.
Common failure modes	• AI infers relationships not present in the approved ontology. • Orientation is wrong or absent. • Vector and path criteria are skipped. • A plausible association is treated as ready for stated use because the model is confident.
Remediation procedure	Pattern references: R-07 - Unsupported discovery; R-06 - Threshold or rule failure If AI asserts a relationship that is not present in the approved ontology: map it to governed relationship evidence or keep it Quarantined as a candidate relationship If relationship orientation is wrong or missing: correct and approve the orientation before material use If vector criteria or path rules were skipped: evaluate the applicable relationship vector and permitted-path controls If model confidence is being used as a substitute for governed relationship evidence: apply the Extended Ontology controls regardless of the model confidence score
Repeatable fix	Output validation identifies material relationship assertions and checks them against governed ontology evidence.
Controlled disposition	Disposition reference: D-03, Ungoverned candidate evidence. Use this reference for AI-generated or AI-used relationships that lack approved Extended Ontology evidence.
Example	The model asserts Supplier depends on Component; the assertion is Quarantined because no approved relationship evidence exists.
Non-example	A generated relationship is accepted as ready for stated use because the model cites supporting text.
Authority and execution	Authority: Ontology authority governs output relationships. The AI workflow owner implements the required relationship validation or Quarantined routing.
Retest	Reinspect the affected AI output relationships. Confirm that each maps to approved Extended Ontology evidence, permitted orientation, vector criteria, and path rules, or remains Quarantined before material use.

AI-005: AI Inference and Output Drift Are Tested

Prerequisites	Pass required: AI-001. Recorded result required: AI-002, AI-003, AI-004.
Specification requirement	Each AI-assisted decision scope shall test material AI outputs, inferred relationships, generated classifications, or context use for drift against the Binding AI Context Contract.
Why this control exists	AI behavior can deviate from governed meaning and relationship rules. Drift must be testable against the contract.
When this applies	When AI can generate or infer material terms, classifications, relationships, context use, recommendations, or actions whose behavior can drift from the Binding AI Context Contract.
Evidence to inspect	Drift test record, AI output sample or production record, contract reference, applicable taxonomy/ontology references, drift result, and recorded readiness disposition.
Evidence sufficiency	The drift evidence must show that the required tests compare material AI terms, classifications, relationships, context use, recommendations, or actions with the correct Binding AI Context Contract version and record the tested item, result, timestamp, and responsible rule or authority. Insufficient: Model-performance monitoring alone is not sufficient when it does not test whether AI behavior has drifted from the governed semantic, relationship, context, or action rules in the Binding AI Context Contract.
Assessment procedure	1. Retrieve the required drift-test rules and records. 2. Confirm tests compare material terms, classifications, relationships, orientations, context use, or actions with the effective Binding AI Context Contract. 3. Verify test ID, contract version, tested output/action, result, timestamp, and responsible authority or approved rule. 4. Trace detected violations to their separate recorded consequence; completing a test does not authorize violating evidence.
Control-result determination	Pass: Required drift-test records compare AI terms, classifications, relationships, orientations, context use, or actions against the contract and record test ID, contract version, tested output/action, result, timestamp, and responsible authority or approved drift-test rule. Fail: AI output is relied on for material use without required drift testing where AI may generate or infer material terms, classifications, relationships, context, or actions.
Common failure modes	• Only model-performance drift is monitored. • Semantic or relationship drift is not tested. • Tests use the wrong contract version. • Drift samples are not tied to the decision scope. • Violations do not update readiness.
Remediation procedure	Pattern references: R-08 - Material change or drift; R-06 - Threshold or rule failure; R-12 - Automated or AI-assisted control If only model-performance drift is monitored: add tests for the semantic, identity, relationship, context, or other contract conditions that can affect the stated decision scope If semantic or relationship drift is not tested: define and execute the missing contract-alignment drift checks If drift tests use the wrong Binding AI Context Contract version: bind the test to the version effective for the outputs or actions being assessed If drift samples are not tied to the decision scope: select and record samples that represent the stated decision scope and material AI behavior If a detected violation does not update readiness or trigger a governed consequence: route the violation to the required disposition, remediation, exception, or contract-review path
Repeatable fix	A repeatable evaluation process samples or tests outputs at the required cadence and preserves test evidence.
Controlled disposition	Disposition reference: D-04, Change or reassessment. Use this reference when required AI drift testing has not been performed against the applicable Binding AI Context Contract version.
Example	A scheduled contract-alignment test records a deprecated classification. A linked Gate holds the affected output under Quarantined or Stop, or permits bounded Caution only through a valid authorizing exception.
Non-example	Model quality metrics are monitored, but no test checks semantic or relationship drift against the governed contract.
Authority and execution	Authority: Binding AI Context Contract owner defines required drift tests; AI operations or workflow owners execute and preserve test evidence. Execution: Drift testing must compare the tested output or action with the correct Binding AI Context Contract version and preserve the test result.
Retest	Run the required drift test against the correct Binding AI Context Contract version. Confirm that the tested terms, relationships, context use, recommendations, or actions produce the recorded expected result or a governed violation disposition.

AI-006: AI Context Contract Violation Has Consequence

Prerequisites	Pass required: AI-001. Recorded result required: CORE-014, AI-005.
Specification requirement	Each material violation of the Binding AI Context Contract shall produce a Gate Record with a resulting readiness state before the affected output, context, relationship, or action is relied on for stated use. Remediation, exception handling, or contract review may be required in addition to the Gate state; they do not substitute for it.
Why this control exists	A binding contract is not binding unless violations have consequence.
When this applies	When a material Binding AI Context Contract violation is detected.
Evidence to inspect	Violation record, Gate Record, resulting readiness state, approved constrained-use exception where Caution permits use, remediation record where required, and contract-review record where required.
Evidence sufficiency	Every material violation has a recorded Gate consequence before affected reliance: Stop, Quarantined, or Caution with a valid exception explicitly authorizing bounded use. Required remediation or contract review is additional evidence. Insufficient: Logging, alerting, remediation, or contract review without the required Gate state does not establish the consequence.
Assessment procedure	1. Identify each material contract violation and its affected evidence or action. 2. Retrieve the violation record and linked Gate determination. 3. Verify Stop or Quarantined prevents material reliance, or Caution has an explicit valid authorizing exception and actual use stays within its bounds. 4. Verify required remediation or contract-review records without treating them as substitutes for the Gate state.
Control-result determination	Pass: Each material violation is recorded and results in Stop or Quarantined, or in Caution with an approved constrained-use exception that explicitly authorizes the bounded use; any required remediation or contract-review action is also recorded. Fail: A material violation has no Gate readiness state, affected evidence or action proceeds under Stop or Quarantined, or Caution is used without an explicit approved constrained-use exception.
Common failure modes	• Violations are logged but have no control consequence. • Repeated exceptions become normal operation. • Violation severity is not tied to Gate disposition. • Contract review occurs without preserving the original violation evidence.
Remediation procedure	Pattern references: R-06, R-10, R-12 If a violation is only logged or alerted: produce the required Gate determination before affected reliance. If Caution lacks explicit use authority: prevent the use or obtain a valid prospective bounded exception. If repeated exceptions have become normal operation: reassess the contract or design while preserving failed findings and exception history. If contract review replaces consequence or erases history: preserve the original violation and create linked Gate and review records.
Repeatable fix	Violation handling is encoded in workflow or operating procedure and produces a Gate/readiness update.
Controlled disposition	Disposition reference: D-05, Threshold, constraint, or conflict. Use this reference when a material AI context-contract violation has occurred and requires a governed consequence or exception.
Example	Use of a prohibited relationship path causes Stop and creates a remediation case.
Non-example	A violation is logged for monitoring but the output remains marked ready for stated use with no consequence.
Authority and execution	Authority: The responsible decision-scope or risk authority defines consequences for material contract violations and approves any constrained-use exception. Execution: A material contract violation must automatically or procedurally invoke a recorded consequence rather than remain a monitoring-only event.
Retest	Trace each affected violation to its Gate state before reliance. Confirm containment under Stop or Quarantined, or authorized bounded use under Caution. Verify any additional required remediation or review records.

AI-007: Context Enforcement Point or Equivalent Control Is Declared

Prerequisites	Pass required: CORE-017, AI-001.
Specification requirement	Each AI-assisted decision scope shall identify the point, process, or mechanism that enforces context eligibility before stated use. A high-frequency path may use a Cached Gate Policy State only when that state was produced by a prior full evaluation and is explicitly bound to decision scope, permitted action class, authority, policy/control versions, constraints, expiration, and invalidation triggers.
Why this control exists	Delivered context can be stale, unauthorized, semantically ambiguous, or outside the stated scope. A declared control point is required to test eligibility before material use.
When this applies	When context is supplied to AI and eligibility must be enforced before the resulting output is treated as ready for stated use.
Evidence to inspect	Context Enforcement Point/equivalent-control record, Semantic Contract/Gate criteria, scope/action-class mapping, authority, policy/control versions, constraints, Cached Gate Policy State and expiration/invalidation triggers where used, Equivalence Rule where used, execution evidence, and Buffered Gate Capture policy/evidence where applicable.
Evidence sufficiency	The declared enforcement point has the required identity, authority, version, scope, contract/Gate references, context rules, and pre-use execution evidence. A claimed equivalent is supported by an Equivalence Rule. Cached policy and buffering are conditional evidence paths with their own required bounds. Insufficient: A named retrieval layer, stale cache, or promised later audit does not establish context eligibility enforcement before use.
Assessment procedure	1. Inspect enforcement-point identifier, owner/authority, version, scope, contract, Gate criteria, and permitted/prohibited context rules. 2. Test eligible, ineligible, and bypass attempts; inspect evidence that enforcement precedes use. 3. For a claimed equivalent, inspect the recorded Equivalence Rule. 4. If cached policy is used, trace its prior full evaluation and verify scope/action class, authority, versions, constraints, expiry, and invalidation at runtime. 5. If buffering is used, verify complete pre-action capture and bounded durable persistence under Section 9.1.
Control-result determination	Pass: The Context Enforcement Point or equivalent control has an identifier, owner/authority, version, scope mapping, Semantic Contract reference, Gate criteria, permitted/prohibited context rules, and evidence of enforcement before use. Any claimed equivalent has a recorded Equivalence Rule. If Cached Gate Policy State is used, it must be current, bound to the scope and action class, versioned, authorized, constrained, unexpired, and invalidated on declared triggers. If buffering is used, its pre-action capture and durable persistence must satisfy Section 9.1. Fail: Use occurs before enforcement, a cached state is stale, expired, broader than the action, lacks an invalidation trigger, or is created after observing the action result.
Common failure modes	• Context is delivered through retrieval, connected tools, APIs, or other context-delivery mechanisms but no point enforces eligibility. • Enforcement occurs after output generation. • The control is not linked to the current contract or scope. • Prohibited context can bypass the enforcement path.
Remediation procedure	Pattern references: R-12 - Automated or AI-assisted control; R-10 - Prohibited or out-of-scope use; R-09 - Missing execution record If context can enter through retrieval, tools, APIs, or other mechanisms without an eligibility check: declare the Context Enforcement Point or equivalent control that evaluates context before stated use If enforcement occurs only after output generation or action: move the eligibility check to the point before the material output or action can rely on the context If the enforcement control is not linked to the current contract or decision scope: bind it to the applicable Semantic Contract or Binding AI Context Contract, Gate criteria, and decision-scope rules If prohibited context can bypass the declared enforcement path: close the bypass and ensure every material context-delivery path is subject to the declared control
Repeatable fix	The enforcement point is named, versioned, testable, and produces evidence of the rule applied.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when no declared control enforces context eligibility before stated AI use.
Example	A retrieval gateway checks context eligibility and records the contract and Gate rule before context reaches the decision step.
Non-example	The architecture diagram shows a retrieval layer, but no control determines whether retrieved context is permitted for the decision scope.
Authority and execution	Authority: AI workflow owner implements the Context Enforcement Point; Binding AI Context Contract owner defines the eligibility rules it must enforce. Execution: The declared Context Enforcement Point or equivalent control must operate before stated use and preserve which eligibility rule was applied.
Retest	Test pre-use enforcement and bypass prevention against the recorded scope and rules. Verify equivalent-control evidence, cached-policy bounds and invalidation, and buffered completion where those paths are used.

AI-008: Agentic Action Authority Is Declared Where AI Acts

Prerequisites	Pass required: AI-001.
Specification requirement	When AI or automation performs an Agentic Action, the decision scope shall declare the authority under which that action is permitted. An Agentic Action is an automated operation that changes or commits state outside the isolated reasoning workspace, or releases/publishes a material recommendation, instruction, message, approval, decision, or output for downstream reliance. Internal reasoning steps that neither change external state nor expose a material output for reliance are not Agentic Actions.
Why this control exists	An agent that acts requires scoped authority and accountability.
When this applies	When automation changes external state or releases a material recommendation/message/output for downstream reliance. Internal reasoning that remains isolated and is not released for reliance is not an Agentic Action.
Evidence to inspect	Agent identity, authority record, permitted action/action-class record, tool/API/channel permissions, downstream-reliance boundary, escalation rule, and Gate-before-action requirement.
Evidence sufficiency	The authority evidence must identify the agent or automation, the delegated business authority, allowed action class, allowed tools or APIs, escalation rule, and Gate-before-action requirement where applicable, and those limits must align with the permissions actually available to the agent. Insufficient: Technical permission to call an API, access a tool, or execute a workflow is not sufficient evidence that the agent has business authority to recommend or perform the material action.
Assessment procedure	1. Identify material external state changes and releases for downstream reliance, including recommendations and messages. 2. Inspect agent identity, delegated business authority, permitted action class, tools/APIs/channels, reliance boundary, escalation, and Gate-before-action requirements. 3. Compare declared limits with actual permissions. Internal reasoning is excluded only when it neither changes external state nor releases material output for reliance.
Control-result determination	Pass: Agent identity, delegated authority, permitted action class, allowed tools/APIs/channels, downstream-reliance boundary, escalation rule, and Gate-before-action requirement are recorded for every material Agentic Action. Fail: A state-changing or externally released material output occurs without declared authority, or a material recommendation is misclassified as an internal reasoning step to avoid Gate control.
Common failure modes	• Technical API permission is treated as business authority. • Agent identity is shared or ambiguous. • Allowed action class is too broad. • Escalation rule is missing. • Recommendation authority and execution authority are conflated.
Remediation procedure	Pattern references: R-04 - Missing authority; R-10 - Prohibited or out-of-scope use; R-12 - Automated or AI-assisted control If technical API permission is being treated as business authority: record the delegated business authority that permits the agent to perform the material action If agent identity is shared or ambiguous: assign a stable agent identity that can be linked to the delegated authority and execution trace If the allowed action class is too broad: narrow the authorized action class to the specific material actions the agent may perform If the escalation rule is missing: define when and to whom the agent must escalate instead of acting If recommendation authority and execution authority are conflated: separate the authority to recommend from the authority to execute a material action
Repeatable fix	Agent authorization is expressed as a governed, versioned authority record enforced by workflow or access policy.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when an agent or automation lacks recorded business authority and action boundaries for a material action.
Example	An invoice agent may recommend holds up to a defined class but must escalate payment release decisions.
Non-example	An agent can call any connected business API because the API credentials permit it.
Authority and execution	Authority: Business or operational authority delegates agent actions; technical permission alone is not business authority. Execution: Technical permission must be constrained to the recorded delegated action authority and escalation rules.
Retest	Inspect the affected material action classes, including externally released recommendations or messages. Verify declared business authority, action/tool/channel limits, downstream-reliance boundary, escalation, and Gate requirements against actual permissions.

AI-009: Material Agentic Action Requires Gate-Before-Action

Prerequisites	Pass required: CORE-016, AI-007, AI-008.
Specification requirement	Each material Agentic Action shall be evaluated by the applicable pre-action Gate synchronously before execution or release for downstream reliance. A valid Cached Gate Policy State may supply the pre-authorized policy decision when the runtime Gate synchronously verifies that the action is within the cached scope, action class, authority, constraints, versions, expiration, and invalidation state. Proceed permits the action. Caution permits only the explicitly authorized constrained action. Stop and Quarantined prohibit action. Compensating action may supplement, but shall not replace, pre-action authorization for irreversible actions.
Why this control exists	Low-latency execution may use precompiled policy state, but the action itself still requires synchronous verification against current authorized policy before it occurs.
When this applies	When an AI agent or automated workflow can execute a material action whose authority depends on a pre-action Gate.
Evidence to inspect	Pre-action Gate Record or Buffered Gate Capture, Cached Gate Policy State where used, decision scope/action class, authority, policy/control versions, constraints, expiration/invalidation status, readiness validity, execution trace link, persistence evidence, reversibility/compensating-action authorization where applicable, and action result.
Evidence sufficiency	Evidence establishes synchronous Gate determination and complete capture before each material action or release. Proceed or a valid explicitly authorizing Caution governs the exact action. Where permitted, delayed durable persistence has a declared interval and linked completion evidence. Insufficient: An exception without a pre-action Gate, later approval, partial capture, stale cache, or post-action rollback does not establish Gate-before-action.
Assessment procedure	1. Compare Gate determination/capture time with the material action or release; inspect causal-order evidence where needed. 2. Verify Proceed or explicitly authorizing Caution, current authority, scope/action class, constraints, and validity. 3. If cached policy is used, verify the runtime checked its effective versions, expiry, invalidation, and bounds synchronously. 4. If buffering is used, verify complete pre-action capture and durable completion within the declared interval. Assess completion when evidence exists or the deadline expires, not in advance. 5. Verify rollback or compensation applies only to a predeclared reversible or compensable class and never replaces pre-action authority for irreversible action.
Control-result determination	Pass: Gate logic completes before action or release; a current full evaluation or valid Cached Gate Policy State governs the exact action; the state is Proceed or an explicitly authorizing Caution; authority is valid; readiness and cached policy remain valid; and the complete pre-action determination is captured. Where buffering is used, the capture shall be durably persisted within the declared interval. This completion criterion is assessed under Section 9.1 and shall not be claimed as Pass before persistence completes. Any rollback or compensating mechanism is used only for an action class predeclared as reversible or compensable. Fail: Action before Gate evaluation, stale/invalid cached policy, Stop/Quarantined execution, unauthorized Caution, invalid authority, expired readiness, missing pre-action capture, missed persistence deadline, or reliance on post-action rollback as authorization for an irreversible action.
Common failure modes	• Action executes before pre-action Gate. • Cached policy is stale, expired, or broader than the action. • Stop/Quarantined action proceeds. • Caution lacks explicit action authorization. • Rollback is used as a substitute for pre-authorization of an irreversible action.
Remediation procedure	Pattern references: R-09 - Missing execution record; R-10 - Prohibited or out-of-scope use; R-12 - Automated or AI-assisted control If the agent acts before the Gate and is reviewed afterward: block the material action until the required Gate result exists If the Gate evidence or authorization is outdated or belongs to another scope: validate that the Gate evidence is current and bound to the same decision scope and action If an exception is created only after execution: require the authorized constrained-use exception before the action occurs If an asynchronous workflow can proceed before control evaluation is complete: add an execution barrier so the action cannot proceed until the Gate has completed
Repeatable fix	The workflow enforces synchronous Gate authorization and complete capture before material action. Permitted buffering has bounded persistence and separate completion checks; exceptions do not bypass the Gate.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when pre-action Gate authority, valid policy, complete capture, or required persistence completion cannot be established. Record the actual failure and apply the Gate and runtime-failure rules.
Example	A payment hold is executed only after the scope-bound Gate records the required control results.
Non-example	The agent executes first and relies on audit logs to review whether it should have acted.
Authority and execution	Authority: The responsible action authority authorizes the exact material use before it occurs. Caution requires a valid bounded exception. Execution: Synchronously determine and capture Gate readiness before action or release. An exception does not replace the Gate. Verify permitted durable persistence later within its declared interval.
Retest	Inspect controlled action tests for permitted and blocked states, invalid authority, expired or invalidated cache, and buffering where used. Verify authorization and complete capture before action, durable persistence within the bound, and no premature Pass for completion criteria.

AI-010: Decision Execution Trace Is Recorded Where AI or Automation Is Material

Prerequisites	Pass required: CORE-012. Recorded result required: CORE-013, AI-009.
Specification requirement	Each material AI-assisted or automated decision path shall record a Decision Execution Trace sufficient to establish what actually executed, including historical model limitations where the original provider/model version may later become unavailable.
Why this control exists	Technical execution logs may supply useful evidence, but defensibility requires the decision-scope evidence defined by applicable DACS controls.
When this applies	When AI or automation materially affects a recommendation, decision, routing step, or action that must later be reconstructed.
Evidence to inspect	Decision Execution Trace, request/actor/input/context, Gate reference, tools/APIs, model/provider/process/version and available material configuration, output/action, time/causal-order evidence, DACS version, conformance/exception state, buffered persistence evidence where applicable, and historical-model availability/reproducibility status.
Evidence sufficiency	Trace must identify provider/model/process version and available material configuration. If the original proprietary model later becomes unavailable, preserve contemporaneous execution evidence and state that original-model execution is not reproducible; a newer model is comparison only.
Assessment procedure	1. Select executions within a defined assessment population and retrieve their contemporaneous Decision Execution Traces. 2. Verify request, actor/agent, inputs/context, concepts, applicable relationship paths, Gate/readiness, tools/APIs, model/provider/process identity and versions, and available material configuration. 3. Verify output/action, timestamp/causal sequence, DACS version, and conformance/exception state. 4. Where the original model is unavailable, verify contemporaneous support and explicit non-reproducibility; a newer run is comparison only. 5. Inspect buffered-persistence evidence where applicable.
Control-result determination	Pass: The trace includes request, actor/agent, input/context, material concepts, relationship paths where applicable, Gate Records/readiness states, tools/APIs, model/provider/process identifier and version where applicable, material parameters/configuration where available, output/action, timestamp/causal sequence evidence, DACS normative version, and conformance/exception state. If the exact historical model later becomes unavailable, the trace must retain contemporaneous evidence sufficient to establish the execution and explicitly mark original-model execution as not reproducible; a newer model result is comparison evidence only. Fail: Material AI/automation execution cannot be reconstructed from contemporaneous trace evidence, model/provider/version identity is missing where material, or a newer model is represented as reproduction of an unavailable historical model.
Common failure modes	• Only prompts and responses are logged. • Retrieved context or tool calls are missing. • Model, process, or rule version is absent. • Agent identity is unknown. • Gate results and exception state cannot be reconstructed.
Remediation procedure	Pattern references: R-09 - Missing execution record; R-12 - Automated or AI-assisted control If only prompts and responses are logged: extend the Decision Execution Trace to the other material execution evidence required by the decision path If retrieved context or tool calls are missing: capture the material context sources, tool calls, APIs, and returned values needed for reconstruction If the model, process, rule, or contract version is absent: record the versions that governed the execution If the actor or agent identity is unknown: record a stable identity for the person, process, or agent that initiated or executed the material step If Gate results, readiness, or exception state cannot be reconstructed: link the trace to the relevant Gate, disposition, and conformance or exception evidence
Repeatable fix	Execution logging uses a structured trace schema linked to the decision scope and evidence records.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when a material AI-assisted or automated execution cannot be reconstructed from a Decision Execution Trace.
Example	An agent action can be reconstructed from request through tool calls, governed context, Gate result, model version, and final action.
Non-example	Only the final AI response is saved; the inputs, context, tools, and Gate results are unavailable.
Authority and execution	Authority: AI or automation owner ensures execution traces exist; evidence custodians preserve them for reconstruction and review. Execution: The Decision Execution Trace must capture the material inputs, context, tools, versions, Gates, output or action, and state needed for reconstruction.
Retest	Reconstruct the affected execution from contemporaneous trace evidence. Verify every required field, effective version, causal sequence, historical-model limitation, and applicable persistence evidence. If historical evidence is unprovable, a new run does not repair the old claim.

AI-011: AI-Generated Evidence Is Not Treated as Decision-Ready Without Gate Evidence

Prerequisites	Recorded result required: AI-002, AI-003, AI-004, AI-005, AI-006, AI-009, AI-010.
Specification requirement	AI-generated evidence shall be governed before material reliance. The applicable Gate shall either permit use within recorded authority and conditions or prevent use. Authorized constrained use under Caution does not establish full decision-scope conformance or change another control result from Fail to Pass.
Why this control exists	AI may produce useful candidates. This control verifies that their use follows the recorded Gate decision. A Pass for correct containment or constrained use does not mean the candidate evidence satisfies every other requirement or that the decision scope is conformant.
When this applies	When AI-generated evidence is held, released, or proposed for material reliance within the stated decision scope.
Evidence to inspect	AI-generated evidence record, applicable control results, Gate Record and readiness validity, recorded use or containment evidence, authority and enforced constraints, and exception/remediation records where applicable.
Evidence sufficiency	Evidence compares actual use or containment with the recorded Gate state, scope, authority, validity, and enforced constraints. Proceed use stays within its permitted scope. Caution use has a valid authorizing exception. Stop, Quarantined, or unauthorized Caution prevents reliance. Insufficient: A recorded disposition without matching actual handling, informal human review, production use, or plausible output does not establish this control’s Pass. Correct containment does not make other failed controls Pass.
Assessment procedure	1. Identify the generated items within the stated assessment population and retrieve their applicable results, Gate, authority, and holding/use records. 2. Under Proceed, compare actual use with permitted scope and validity. 3. Under Caution, verify an authorizing exception and actual compliance with its bounds; without use authority, verify reliance is prevented. 4. Under Stop or Quarantined, verify material reliance is prevented. 5. Preserve failed prerequisite results and distinguish handling Pass from full scope conformance.
Control-result determination	Pass: Actual handling follows the recorded Gate decision. Under Proceed, use remains within the permitted scope and validity conditions. Under Caution, use occurs only within a valid authorizing exception and its bounds. Under Stop or Quarantined, material reliance is prevented. Caution without authority for the proposed use also prevents that use. Fail: Required control results, Gate evidence, authority, or use constraints cannot be established; material reliance occurs under Stop or Quarantined; Caution use lacks a valid authorizing exception or exceeds its bounds; or permitted use exceeds the recorded scope or validity conditions. A failed prerequisite remains Fail.
Common failure modes	• Actual use exceeds the Gate’s scope, validity, or constraints. • Stop or Quarantined evidence enters material reliance. • Caution is treated as permission without a valid authorizing exception. • A handling Pass is presented as proof that every control passed. • Generated evidence loses provenance or enforced bounds during reuse.
Remediation procedure	Pattern references: R-07, R-10, R-12, R-09 If use violates Stop or Quarantined: prevent reliance and preserve the finding. If Caution lacks authority or exceeds bounds: prevent that use or obtain a valid prospective bounded exception and new Gate determination. If Proceed use exceeds scope or validity: block affected use and reassess the proposed scope. If disposition records do not match actual handling: correct enforcement and preserve linked use or containment evidence. If provenance or constraints are lost in reuse: restore verifiable links and enforce the bounds through the receiving path. If handling Pass is presented as full conformance: correct the claim while retaining every other control’s actual result.
Repeatable fix	Generated evidence retains provenance, recorded Gate bounds, and inspectable use or containment evidence through transformation and reuse.
Controlled disposition	Disposition reference: D-03, Ungoverned candidate evidence. Apply the actual Gate state to the generated item. This card tests compliance with that state; it does not promote candidate evidence or erase other failures.
Example	AI-003 records an unmapped term held as Quarantined. Use records show no material reliance. AI-011 may Pass its handling test when its prerequisites and all local criteria are satisfied; the term remains held and full scope conformance is assessed separately.
Non-example	A Gate records Quarantined, but the generated mapping is used in a material decision. An informal human review does not authorize that reliance.
Authority and execution	Authority: The applicable decision-scope authority governs permitted use or containment. Component authorities remain accountable for their controls. Execution: Enforce the recorded Gate state, validity, authority, and constraints at the point of material use and preserve actual handling evidence.
Retest	Compare each affected item’s actual handling with its Gate state and valid authority. Verify scope and validity under Proceed, exception bounds under Caution, and prevention of reliance under Stop, Quarantined, or unauthorized Caution. Retain every other control’s result.