7. Core Decision-Scope Controls

Core controls apply to every DACS decision scope. These cards operationalize the Core controls without changing their normative meaning.

CORE-001: Decision Scope Is Declared

Prerequisites	None.
Specification requirement	Before evaluating dependent controls, record the specific business decision or use that will be reviewed and the boundary of that review. The decision-scope record identifies what is included, what is excluded, the business level being assessed, and the accountable owner. An initial Bootstrap Scope Record may be used to collect these facts; it does not authorize material use.
Why this control exists	A shared review boundary lets managers, practitioners, and assessors test the same decision and evidence. Without it, teams may assess different uses, compare different grains, or apply approval beyond the use actually reviewed.
When this applies	At initialization of every DACS decision scope and whenever the decision boundary changes. A Bootstrap Scope Record may be used only to collect evidence for CORE-001/CORE-002 and never authorizes material reliance.
Evidence to inspect	Decision-scope record or completed Bootstrap Scope Record, business domain, decision/use statement, grain boundary, owner, in-scope statement, out-of-scope statement, stable scope identifier, and version.
Evidence sufficiency	The record identifies the specific decision or use, domain, grain or multi-grain boundary, included and excluded uses, accountable owner, stable scope identifier, and record version. The recorded boundaries identify which evidence belongs in this review. Insufficient: A project, dataset, dashboard, or subject-area name does not establish the decision, evidence boundary, grain, or authority being assessed.
Assessment procedure	1. Retrieve the decision-scope record or completed Bootstrap Scope Record. 2. Check every required field, including the stable identifier and record version. 3. Confirm that the decision, included and excluded uses, and grain describe the same review boundary. 4. Check that the initial collection record has not been used as permission for material reliance.
Control-result determination	Pass: The completed record identifies the business domain; the specific decision or use; the grain, or declared boundary covering multiple grains; in-scope use; out-of-scope use; accountable owner; stable scope identifier; and record version. Every required field is present. The recorded decision, included and excluded uses, and grain define which evidence is included in this review. These criteria also apply when the completed record originated as a Bootstrap Scope Record. Fail: A required scope field is missing or ambiguous; the scope identifier or version is missing; or an initial scope record is treated as permission for material reliance.
Common failure modes	• Bootstrap record treated as approval to proceed. • Scope lacks stable identifier/version. • Decision/use or grain boundary is ambiguous. • Ownership or permitted/excluded use is missing.
Remediation procedure	Pattern references: R-01, R-02, R-04, R-10 If the record names only a project or dataset: state the specific decision or use and its evidence boundary. If grain or use boundaries are missing: record the business level, included uses, and excluded uses. If ownership is divided or implicit: identify the accountable owner and recorded authority. If identifier or version is missing: assign a stable scope identifier and version the completed record. If an initial collection record was used as approval: stop the unsupported reliance and evaluate the proposed use through the applicable controls and Gate.
Repeatable fix	A reusable decision-scope template requires the same minimum fields and named authority for every evaluation.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when the decision scope itself is missing, incomplete, or ambiguous.
Example	A weekly executive Active Customer Count is bounded to North America, account grain, internal operating review, with explicit exclusions.
Non-example	“Customer reporting” with no grain, owner, or permitted-use boundary.
Authority and execution	Authority: Business owner owns the decision boundary; governance or stewardship authority resolves scope and grain disputes.
Retest	Reinspect all required scope fields, including identifier and version. Confirm that the recorded boundaries identify the evidence being reviewed and that any material reliance has separate Gate authority.

CORE-002: Materiality and Conditional Applicability Are Bound Before Dependent Controls

Prerequisites	Pass required: CORE-001.
Specification requirement	The decision scope shall establish recorded rules or authority references for every materiality, applicability, approval, authorization, equivalence, compatibility, multi-value, or other conditional predicate it uses. Each rule shall exist independently of the result it governs.
Why this control exists	Binary controls require deterministic predicates and a deterministic evaluation order. Conditional language cannot be left to assessor discretion, and a predicate cannot be justified by a downstream result that depends on that same predicate.
When this applies	Immediately after the decision scope is established and before profile selection or any control containing a conditional predicate.
Evidence to inspect	The recorded rules and authority references needed for the predicates used in this scope, with observable criteria, authority, version, effective period, scope mapping, applicable reassessment triggers, and dependency references. Include Materiality, Applicability, Equivalence, and Multi-Value Rules when the corresponding condition is used; do not require an unused rule merely because it appears in this list.
Evidence sufficiency	Every materiality/applicability/equivalence/multi-value/authority predicate needed by downstream controls has a recorded rule with observable criteria, authority, version, effective period, and scope mapping. No rule may depend on the result it governs.
Assessment procedure	1. List each conditional predicate used by the decision scope. 2. Locate its governing rule/authority and verify completeness. 3. Confirm the rule predates the dependent evaluation and contains no Circular Reliance. 4. Record unresolved predicates as Fail; do not invent a fallback threshold.
Control-result determination	Pass: Every conditional predicate required by the decision scope has a recorded rule or authority reference with identifier, owner/authority, version, effective period, observable condition or threshold, decision-scope mapping, and reassessment trigger where applicable; each predicate can be evaluated from recorded facts without assessor invention; no predicate relies on Circular Reliance; and no DACS fallback threshold is required because the organization has supplied the governing rule. Fail: A required predicate rule is missing, incomplete, expired, subjective, created from the dependent result, dependent on Circular Reliance, or cannot resolve the predicate from recorded facts. DACS does not supply a fallback materiality or vector threshold.
Common failure modes	• Materiality is decided by assessor judgment. • A profile trigger has no applicability rule. • A threshold is created after seeing the evidence. • A rule relies on the Gate or Conformance Record whose validity depends on that rule.
Remediation procedure	Create or correct the missing rule under accountable authority, version it, give it an effective period, bind it to the decision scope, remove any circular dependency, and retest before evaluating dependent controls.
Repeatable fix	Use a controlled predicate-rule registry/template that requires scope, observable condition/threshold, authority, version, effective period, and reassessment trigger.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Dependent controls shall not be evaluated as Passed while their required predicate remains unresolved.
Example	A materiality rule approved before evaluation declares that any evidence capable of changing customer eligibility, legal rights, financial exposure, safety, or the primary decision outcome is material for the scope.
Non-example	The assessor decides during review that a difficult relationship is “not material” because including it would cause another control to fail.
Authority and execution	Authority: The accountable decision-scope authority approves the governing rules and authority references. Component rule owners remain accountable for their rules. Execution: Establish governing predicates independently of their dependent results. Apply each card’s listed prerequisite status; failure diagnosis and containment may continue while permission for material use remains withheld.
Retest	Re-evaluate every previously unresolved predicate from the corrected rule, then evaluate affected downstream controls in dependency order.

CORE-003: Applicable Profiles Are Declared

Prerequisites	Pass required: CORE-002.
Specification requirement	Each conformance evaluation shall record which DACS profiles apply to the stated decision scope, using the recorded profile Applicability Rules.
Why this control exists	Profiles keep DACS narrow while preventing material controls from being skipped.
When this applies	When the decision scope is established or changed in a way that could add or remove Extended Taxonomy, Extended Ontology, or AI Context Contract applicability.
Evidence to inspect	Profile Applicability Rules, profile-applicability record, scope mapping, and reasons for excluded profiles.
Evidence sufficiency	The profile-applicability record identifies Core and each additional profile whose recorded rule evaluates true. Each excluded profile has a false applicability result, reason, rule reference, and supporting scope facts. Insufficient: A selected profile list does not establish applicability when exclusions are based on preference, unresolved facts, or the final Conformance Record’s unsupported claim.
Assessment procedure	1. Retrieve the profile Applicability Rules and independently recorded scope facts. 2. Apply each profile rule and record its true or false result. 3. Include Core and every additional profile whose rule is true; record the reason and supporting facts for every exclusion. 4. Check that no applicability determination depends on the conformance claim it will support.
Control-result determination	Pass: The profile-applicability record identifies Core and every additional profile whose recorded Applicability Rule evaluates true. Each excluded profile has a recorded false applicability result and reason. The determination uses recorded scope facts without assessor inference or Circular Reliance. Fail: A profile Applicability Rule is missing or unresolved; a required profile is omitted; an excluded profile lacks a recorded false applicability result and reason; or the determination contains Circular Reliance.
Common failure modes	• Only Core is declared by default. • A profile is omitted because the evidence is inconvenient to assess. • AI or inferred relationships are present but not recognized as profile triggers. • Applicability rationale is undocumented.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-10 - Prohibited or out-of-scope use If only the Core profile was declared without examining the actual decision path: trace the material decision path and declare every DACS profile triggered by its use of concepts, relationships, AI, inference, automation, or agentic action If a profile was omitted because its evidence is difficult or inconvenient to assess: restore the profile when its triggering condition is present and assess its controls normally If AI, inference, or material relationships are present but were not recognized as profile triggers: add the applicable AI Context Contract or Extended Ontology profile and evaluate the affected controls If the reason for including or excluding a profile is not recorded: record the applicability rationale for each profile decision
Repeatable fix	A profile-applicability checklist is completed at scope creation and rerun when the decision path changes.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when the applicable DACS profiles have not been established from the actual decision path.
Example	Core, Extended Taxonomy, and Extended Ontology are declared; AI Context Contract is Not Applicable because no AI affects the path.
Non-example	Only Core is selected because it is easier, although inferred relationships materially affect the result.
Authority and execution	Authority: Decision-scope owner and governance authority determine applicability from the actual decision path, not convenience.
Retest	Reapply the recorded profile rules to the scope facts. Confirm all required profiles are included, each exclusion is supported by a false rule result and reason, and the determination is independently established before it is linked to the final assessment record.

CORE-004: Semantic Contract Exists

Prerequisites	Pass required: CORE-003.
Specification requirement	A decision scope shall have an identified Semantic Contract before evidence is relied on for material use.
Why this control exists	Without a Semantic Contract, meaning, identity, relationship, context, and Gate controls cannot be tested consistently.
When this applies	Before material evidence in the decision scope is treated as ready for stated use, and whenever the governing Semantic Contract changes.
Evidence to inspect	Semantic Contract record, identifier, owner, version, decision-scope mapping, and references to every component required by the applicable profiles.
Evidence sufficiency	The Semantic Contract evidence must identify the contract, its owner and version, the decision scope it governs, and the component references required by every applicable DACS profile. The contract must be the governed agreement for this scope, not a collection of loosely related documentation. Insufficient: A glossary, data dictionary, semantic layer, prompt, or architecture document is not sufficient by itself unless it is part of, or is explicitly referenced by, the governed Semantic Contract for the stated decision scope.
Assessment procedure	1. Inspect the Semantic Contract record. 2. Verify identifier, owner, version, decision-scope mapping, and each component reference required by the profiles declared for this scope.
Control-result determination	Pass: The Semantic Contract has an identifier, owner, version, decision-scope mapping, and referenced components required by the applicable profiles. Fail: No Semantic Contract exists, ownership or version is missing, or it is not linked to the decision scope.
Common failure modes	• A glossary, data dictionary, or semantic layer is treated as the whole Semantic Contract. • The contract has no owner or version. • Required profile components are referenced informally. • Scope mapping is missing.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-04 - Missing authority If a glossary, data dictionary, semantic layer, prompt, or architecture document is being treated as the entire Semantic Contract: establish or identify the governed Semantic Contract and explicitly reference the supporting artifacts that form part of it If the contract has no owner or version: assign the accountable owner and record the applicable version If required profile components are only referenced informally: add explicit governed references to the components required by the applicable DACS profiles If the contract is not mapped to the decision scope: bind the Semantic Contract to the stated decision scope before stated use
Repeatable fix	A version-controlled Semantic Contract record is created through the same approval and change process for each scope.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when the required Semantic Contract is missing, incomplete, unowned, unversioned, or not bound to the decision scope.
Example	SC-CUST-014 v3 is owned by Customer Operations and mapped to the dashboard decision scope and its taxonomy, ontology, and identity references.
Non-example	A glossary link is treated as the Semantic Contract even though it has no owner, version, or scope mapping.
Authority and execution	Authority: Semantic Contract owner approves the contract; component owners remain accountable for referenced evidence.
Retest	Reinspect the revised Semantic Contract. Confirm its identifier, owner, version, decision-scope mapping, and all component references required by the applicable profiles.

CORE-005: Physical Attribution or Boundary Evidence Anchor Is Recorded Where Required

Prerequisites	Pass required: CORE-002.
Specification requirement	Each material evidence item shall record the physical attribution required for the decision scope. When an external, legacy, proprietary, or third-party source prevents direct source-level inspection, a Boundary Evidence Anchor may satisfy the attribution requirement only when the unavailable boundary is explicit and the anchor identifies the exact external evidence actually consumed.
Why this control exists	Material evidence must be traceable without making conformance impossible when the organization cannot lawfully or technically inspect a third-party or legacy internal schema.
When this applies	When material evidence requires source attribution, including evidence obtained from external, proprietary, SaaS, legacy, or otherwise inaccessible systems.
Evidence to inspect	Source reference and source-level locator; or Boundary Evidence Anchor containing external source/vendor identity, interface/API/feed/contract identifier and version, payload/event/message/document identifier, acquisition timestamp/effective period, content hash or equivalent fingerprint where possible, supporting contract/SLA/attestation where available, inaccessible-boundary statement, and decision-scope mapping.
Evidence sufficiency	For directly inspectable evidence, the locator identifies the source-level evidence needed to locate, interpret, and test the item. Where visibility is legitimately unavailable, a complete Boundary Evidence Anchor identifies the exact evidence consumed, its source and interface/version, payload identity, time, inaccessible boundary, and scope. Inspect fingerprints where technically possible and supporting contract/SLA/attestation references where available. Insufficient: Vendor attestation alone, an unspecified feed, or a reference to current data does not identify the exact evidence consumed.
Assessment procedure	1. Trace each material evidence item to its source-level locator. 2. If direct source-level visibility is legitimately unavailable, verify every required Boundary Evidence Anchor field and the inaccessible-boundary statement. 3. Verify the exact payload/event/message/document identity, interface or contract version, acquisition time, and decision-scope mapping. 4. Inspect the fingerprint where technically possible and supporting references where available; do not treat attestation alone as attribution.
Control-result determination	Pass: The evidence item records source-level attribution sufficient to locate, interpret, and test the evidence for the decision scope; or, when direct source-level visibility is legitimately unavailable, a Boundary Evidence Anchor records external source identity, interface/feed/contract identifier and version, payload/event/message/document identifier, acquisition timestamp or effective period, content hash or equivalent immutable fingerprint where technically possible, contract/SLA/attestation reference where available, the inaccessible boundary, and decision-scope mapping. Vendor attestation alone is not sufficient. Fail: Material evidence cannot be tied to source-level evidence or a complete Boundary Evidence Anchor, the inaccessible boundary is not declared, or a vendor statement is used as the sole attribution evidence.
Common failure modes	• Vendor name is recorded but not the exact feed/API/payload. • A compliance letter is treated as the sole source anchor. • Proprietary schema is unavailable and no immutable payload reference is preserved.
Remediation procedure	Pattern references: R-01, R-13 If source attribution is missing: locate the required source-level evidence and preserve its exact reference. If direct visibility is legitimately unavailable: create a complete Boundary Evidence Anchor and state the inaccessible boundary. If the anchor identifies only a vendor or feed: add the exact interface/version, payload identity, time, and scope mapping. If attestation is the only support: obtain the remaining required anchor evidence, including a fingerprint where technically possible and supporting references where available. If the historical evidence cannot be established: record the limitation and retain the failed finding.
Repeatable fix	External-source onboarding requires a Boundary Evidence Anchor whenever direct source-level inspection is unavailable.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Candidate evidence remains out of stated use until direct attribution or a complete Boundary Evidence Anchor exists.
Example	A bureau API response is preserved with vendor, endpoint/version, request/response ID, acquisition time, payload hash, contract reference, and a statement that the provider’s internal tables are not inspectable.
Non-example	“Credit bureau data” plus a vendor SOC report, with no record of the exact response used.
Authority and execution	Authority: Source custodian and decision-scope owner approve the boundary; legal/procurement evidence may support but not replace the anchor.
Retest	Trace each affected item to its source evidence or verify every required field of the permitted Boundary Evidence Anchor. Confirm exact consumed-evidence identity and the conditional fingerprint and supporting-reference obligations.

CORE-006: Logical-to-Conceptual Binding Exists Where Required

Prerequisites	Pass required: CORE-004, CORE-005.
Specification requirement	Each logical information element used in a material decision path shall map to an approved business concept.
Why this control exists	Logical meaning must be tied to governed business meaning before it supports DACS conformance for the stated scope.
When this applies	When a material logical information element contributes to the decision path and its governed business meaning must be established.
Evidence to inspect	Logical-to-conceptual mapping record, business concept identifier, owner, version, source reference where required, decision-scope mapping.
Evidence sufficiency	The mapping evidence must identify the approved business concept for each material logical information element and include the owner, version, decision-scope applicability, and source reference where the control requires one. Insufficient: A local field name, technical label, or unapproved term is not sufficient evidence of business meaning unless it is explicitly bound to the approved business concept used by the stated decision scope.
Assessment procedure	1. Enumerate material logical information elements. 2. Verify that each material item maps to an approved business concept with the required owner, version, source reference where required, and decision-scope applicability.
Control-result determination	Pass: Each logical information element maps to an approved business concept with owner, version, source reference where required, and decision-scope applicability. Fail: The logical element lacks a business concept mapping, maps only to a local term, or maps to an unapproved or ambiguous concept.
Common failure modes	• Logical fields map only to local technical names. • Several logical elements map to one concept without boundary rules. • Mappings are out of date or unowned. • An unapproved concept is used because names appear similar.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-01 - Missing evidence; R-04 - Missing authority If logical fields map only to local or technical names: map each material logical element to an approved business concept If several logical elements map to one concept without boundary rules: record the conditions or boundaries that explain when each mapping is valid If a mapping is outdated or has no accountable owner: assign ownership, update the mapping, and record the applicable version or effective period If a concept was selected because its name appears similar: obtain semantic-authority approval for the mapping or reject the mapping until the business meaning is proven
Repeatable fix	Logical mappings retain the approved concept, owner, version, decision-scope applicability, and source reference where required.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material logical element is not yet bound to an approved business concept.
Example	logical_customer_status maps to the approved Customer Status concept version used by the decision scope.
Non-example	A warehouse column named cust_type is assumed to mean the enterprise Customer Type concept.
Authority and execution	Authority: Semantic authority approves the business concept; mapping owner maintains the logical-to-conceptual binding.
Retest	Recheck each material logical information element. Confirm that it now maps to the approved business concept with the required owner, version, source reference where required, and scope applicability.

CORE-007: Business Identity Anchors Exist Where Required

Prerequisites	Pass required: CORE-004.
Specification requirement	Each identity-bearing concept used in a material decision path shall have a Business Identity anchor.
Why this control exists	Without identity, the enterprise cannot reliably compare history, reconcile systems, reconstruct decisions, or defend analytics.
When this applies	When the material decision path must distinguish a specific business instance across systems, sources, or time.
Evidence to inspect	Identity evidence used for the stated scope: the stable business identifier mapping, durable or composite identity rule, approved resolution record, or equivalent identity evidence permitted by the Pass criterion.
Evidence sufficiency	The identity evidence must show, for every identity-bearing concept in the material decision path, which business identifier, identity rule, composite rule, or approved resolution method is authoritative for the stated semantic grain and decision scope. Insufficient: A source-system key, local identifier, display value, or match result is not sufficient by itself unless it has been approved as the Business Identity anchor, or as part of the governed identity-resolution method, for the stated grain and decision scope.
Assessment procedure	1. List every material concept in the decision path whose use depends on identifying a specific business instance. 2. For each identity-bearing concept, identify the claimed Business Identity anchor or approved resolution method. 3. Verify that the anchor or resolution method is approved for the stated semantic grain and decision scope.
Control-result determination	Pass: Each identity-bearing concept is linked to a stable business identifier, durable identity rule, composite identifier rule, approved resolution method, or equivalent identity evidence. Fail: A concept requires identity for the decision scope and lacks an approved identity anchor.
Common failure modes	• A source key is assumed to be business identity without authority. • Multiple systems use incompatible identifiers with no crosswalk. • Approximate matching is used with no approved resolution rule. • Identity authority is unknown.
Remediation procedure	Pattern references: R-03 - Unstable identity or grain; R-04 - Missing authority; R-11 - Human adjudication If a source-system key or local identifier is being treated as Business Identity without approval: identify and approve the authoritative business identifier, durable identity rule, composite rule, or resolution method for the stated semantic grain and decision scope If systems use incompatible identifiers: create or approve the governed crosswalk or identity-resolution rule that connects the identifiers at the correct semantic grain If approximate matching is used without an approved resolution rule: govern the matching rule, threshold, tie-break logic, authority, and unresolved-case handling before relying on the result If identity authority is unknown: assign the accountable identity authority before the identity evidence is used for material stated use
Repeatable fix	Identity anchors are registered with scope, grain, authority, effective period, and resolution method.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference for identity-bearing evidence that still lacks an approved Business Identity anchor.
Example	Customer Account uses CRM Master Account ID, with a governed crosswalk for acquired systems.
Non-example	A display name is used to join customers across systems without an approved identity rule.
Authority and execution	Authority: The designated identity authority or steward approves identifiers and resolution rules; technical teams implement them.
Retest	Recheck every material identity-bearing concept. Confirm that each concept now has an approved Business Identity anchor or governed resolution method for the stated semantic grain and decision scope.

CORE-008: Semantic Grain Is Declared for Identity-Bearing Evidence

Prerequisites	Pass required: CORE-007.
Specification requirement	Each material Business Identity shall declare semantic grain for each identity-bearing evidence item at each point of consumption within the decision path. Where identity-bearing evidence is transformed, aggregated, split, or reconciled across grains, the source grain, transformation rule, and resulting grain shall be recorded.
Why this control exists	Identity failures often occur when different grains are treated as equivalent or when aggregation changes the business level at which identity is interpreted. DACS permits multi-grain decision paths only when each grain and material transition is explicit.
When this applies	When a material Business Identity is used, compared, counted, reconciled, resolved, or acted upon.
Evidence to inspect	Identity record, per-consumption semantic grain declaration, uniqueness exception where applicable, decision-scope mapping, and source-grain, transformation/aggregation-rule, and resulting-grain evidence for each material grain transition.
Evidence sufficiency	Each identity-bearing item has an explicit grain at every point of consumption. Each material transformation, aggregation, split, or reconciliation records the source grain, governing rule, and resulting grain. Insufficient: A single grain label on the source record does not establish the grain at later consumption points or explain a material change between grains.
Assessment procedure	1. Trace each identity-bearing evidence item through its points of consumption. 2. Verify the grain at each point and its link to the decision scope. 3. For each material grain transition, inspect source grain, transformation or aggregation rule, and resulting grain. 4. Verify any claimed cross-grain equivalence under its approved rule.
Control-result determination	Pass: Every identity-bearing evidence item records the business level at which it is unique and meaningful at its point of consumption, links that grain to the decision scope, and records each material grain transition from source grain to resulting grain with the governing transformation or aggregation rule. Fail: An identity-bearing evidence item is consumed without a declared grain, different grains are treated as equivalent without an approved transformation or equivalence rule, or a material grain transition is not recorded.
Common failure modes	• Account, person, household, contract, and transaction grains are mixed. • Uniqueness is asserted only technically. • Aggregate counts are compared as if they share the same business grain. • Grain is documented but not bound to the scope.
Remediation procedure	Pattern references: R-03, R-02 If grain is missing at a consumption point: declare the business level at that point and bind it to the scope. If an aggregation, split, or reconciliation changes grain: record the source grain, governing transformation, and resulting grain. If different grains are treated as equivalent: correct the use or establish the approved transformation or equivalence rule prospectively. If a transformation changes meaning: reassess the affected identity and downstream use.
Repeatable fix	Identity records require a semantic-grain field and a uniqueness expectation before approval.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when the semantic grain of a material Business Identity is missing, incompatible, or not approved for the scope.
Example	Account ID is unique at customer-account grain; household ID is recorded separately and is not treated as equivalent.
Non-example	A household key and an account key are treated as interchangeable because both are called Customer ID.
Authority and execution	Authority: Business identity owner or steward approves semantic grain and uniqueness expectations for the scope.
Retest	Trace the affected items through every relevant consumption point and material grain transition. Confirm the recorded grain, source-to-result transformation, scope mapping, and any approved equivalence rule.

CORE-009: Business Concept Is Not Assumed to Be Business Identity

Prerequisites	Pass required: CORE-007.
Specification requirement	A business concept shall not be treated as a Business Identity unless identity evidence is recorded.
Why this control exists	A concept defines meaning; identity distinguishes a specific instance.
When this applies	When a business concept, taxonomy node, glossary term, label, or classification might be used as evidence of a specific business instance.
Evidence to inspect	Business concept record, decision-scope mapping, and the distinct identity rule, identifier mapping, or approved resolution method used for each identity-bearing use.
Evidence sufficiency	The evidence must distinguish the governed meaning of a business concept from the evidence that identifies a specific business instance. Each identity-bearing use must have its own approved identifier, identity rule, or resolution method. Insufficient: A concept name, taxonomy node, glossary term, classification, category, or label is not sufficient evidence that two records represent the same business instance unless separate Business Identity evidence establishes that identity.
Assessment procedure	1. Inspect each identity-bearing use of a business concept. 2. Verify the identity evidence is distinct from the concept definition, taxonomy node, glossary term, or classification label and includes an approved identifier or resolution method.
Control-result determination	Pass: Each identity-bearing use has a distinct identity rule, identifier, or approved resolution method beyond the existence of a concept label. Fail: A concept name, taxonomy node, glossary term, or classification is used as identity evidence without an approved identity anchor.
Common failure modes	• A taxonomy node, glossary term, label, or class is used as if it identifies a specific instance. • A concept-level code is confused with an instance identifier. • Identity evidence is omitted because the business concept is well defined.
Remediation procedure	Pattern references: R-03 - Unstable identity or grain; R-02 - Ambiguous meaning If a concept, taxonomy node, glossary term, label, or class is being used as if it identifies a specific instance: separate the concept definition from the evidence that identifies an individual business instance If a concept-level code is being treated as an instance identifier: record the actual business identifier or approved identity-resolution rule required for the instance If identity evidence was omitted because the concept is well defined: add the required Business Identity anchor for every use that depends on identifying a specific instance
Repeatable fix	Templates and reviews require distinct fields for business concept and Business Identity evidence.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a concept, label, classification, or taxonomy node is being used as identity evidence without a separate approved identity anchor.
Example	Customer is the concept; CRM Master Account ID plus its grain and resolution rule identifies the customer account instance.
Non-example	The taxonomy term “Customer” is used as proof that two records refer to the same customer.
Authority and execution	Authority: Semantic authority owns concept meaning; identity authority owns instance-identification evidence. Neither substitutes for the other.
Retest	Reinspect each identity-bearing use of a business concept. Confirm that the evidence now separates concept meaning from the approved identifier, identity rule, or resolution method used to identify a specific instance.

CORE-010: Identity Resolution Produces Determinate Results

Prerequisites	Pass required: CORE-002. Recorded result required: CORE-007, CORE-008.
Specification requirement	Each identity-resolution method used for stated use shall return the same identity result, or the same unresolved or exception result, when the inputs, rule set, threshold, method version, and decision scope are unchanged.
Why this control exists	Material decisions require repeatable identity outcomes.
When this applies	When identity resolution, matching, mastering, or adjudication determines identity in a decision path relied on for stated use.
Evidence to inspect	Identity-resolution method and version, tested inputs, rule set, threshold, scope reference, repeat-test results, and exception record where applicable.
Evidence sufficiency	Repeat-test records preserve unchanged inputs, rules, thresholds, method version, and scope. The tests return the same identity result or the same governed unresolved or exception result. Insufficient: An explanation for different outcomes under unchanged conditions does not establish Pass. Repeatable unresolved outcomes establish repeatability only, not identity readiness.
Assessment procedure	1. Record the tested inputs, rule set, threshold, method version, and scope. 2. Repeat the identity test without changing those conditions. 3. Compare outcomes, including unresolved or exception results. Any different outcome under unchanged conditions is Fail. 4. Record a changed configuration as a different test case and preserve the original result.
Control-result determination	Pass: Repeat tests using the same recorded inputs, rules, thresholds, method version, and scope return the same identity result or the same unresolved or exception result. A repeatable unresolved result does not establish that identity is ready for material use. Fail: Any different identity outcome under the same inputs, rule set, threshold, version, and decision scope is Fail. A recorded explanation does not convert that failed determinism test into Pass; a changed rule, threshold, version, or scope is a different test case.
Common failure modes	• Probabilistic or approximate resolution returns different identities for the same case. • Tie-breakers are undocumented. • Model or threshold version is not captured. • A steward resolves repeated cases differently because the adjudication was not converted into a governed rule or mapping.
Remediation procedure	Pattern references: R-03 - Unstable identity or grain; R-06 - Threshold or rule failure; R-11 - Human adjudication If the same identity case produces different outcomes under the same governed conditions: identify the source of the variation and establish a deterministic rule or governed unresolved outcome If tie-break logic is undocumented: define and approve the tie-break rule used when more than one candidate satisfies the primary rule If the model, method, rule, or threshold version is not captured: version the identity-resolution method and record the version and threshold used for the assessed case If human adjudication produces inconsistent repeated outcomes: convert the adjudication into a governed mapping, rule, tie-break decision, or recorded exception that can be applied consistently
Repeatable fix	The same inputs, rule version, thresholds, and scope produce the same identity or the same unresolved/exception result. Human adjudications become governed mappings or rules with effective dates.
Controlled disposition	Disposition reference: D-06, Determinacy or repeatability. Use this reference while identity resolution does not reproduce the same result, or the same governed unresolved or exception result, under the same governed conditions.
Example	Two duplicate account candidates resolve to the same mastered account after the steward approves a tie-break rule and the replay test repeats the result.
Non-example	A reviewer manually chooses a different account each time without recording why or converting the choice into a governed rule.
Authority and execution	Authority: Identity authority owns the resolution rule; steward adjudication must be converted into governed rule, mapping, or exception evidence when repeatability is required. Execution: The same identity case must be replayable under the same inputs, rule version, thresholds, and scope so the result can be compared.
Retest	Repeat the identity test under the same recorded conditions and compare results. If remediation changed a rule or configuration, assess a new version and retain the original failure. A repeatable unresolved result does not permit material identity use.

CORE-011: Discovered Evidence Is Quarantined Until Governed

Prerequisites	Recorded result required: CORE-002, CORE-003.
Specification requirement	Candidate evidence shall be held under a recorded disposition that prevents material reliance unless the applicable Gate explicitly permits the stated use.
Why this control exists	Quarantined allows candidate evidence to remain available for exploration while preventing untested evidence from being relied on for material decisions by default.
When this applies	When evidence enters the decision path through discovery, inference, generation, retrieval, import, or another candidate-evidence process.
Evidence to inspect	Candidate evidence log, recorded disposition and holding or use evidence, Gate Record when evaluated, exception record where applicable, owner or review authority, and next action.
Evidence sufficiency	Recorded handling shows candidate evidence held as Quarantined or used only as the applicable Gate permits. Any constrained use has a valid authorizing exception and stays within its bounds. Insufficient: Review or exception paperwork alone is insufficient if actual material use violates Stop, Quarantined, scope, validity, or exception limits.
Assessment procedure	1. Identify candidate evidence and retrieve its holding or use records. 2. For held evidence, verify Quarantined handling prevents material reliance. 3. For used evidence, compare actual use with the recorded Gate state, scope, authority, validity, and constraints. 4. Where Caution permits use, verify the valid authorizing exception and its limits.
Control-result determination	Pass: Candidate evidence is held as Quarantined, or its actual use follows the recorded Gate disposition. Any constrained use has a valid authorizing exception and remains within its recorded bounds. Fail: Candidate evidence is relied on as evidence for stated use without applicable Gate evaluation, a recorded readiness state, or approved exception handling.
Common failure modes	• Candidate evidence enters a dashboard or model before Gate review. • AI-generated evidence is treated as ready for stated use because a human viewed it. • Discovered relationships have no candidate status. • Constrained use occurs with no exception record.
Remediation procedure	Pattern references: R-07 - Unsupported discovery; R-10 - Prohibited or out-of-scope use If candidate evidence entered a dashboard, model, or decision path before Gate review: remove it from stated use and assign the evidence to Quarantined until the applicable controls are completed If AI-generated evidence is being treated as ready for stated use because a human viewed it: treat the generated item as candidate evidence and route it through the same applicable controls as other evidence If a discovered relationship has no candidate status: record the relationship as candidate or Quarantined evidence and route material relationships to Extended Ontology review If constrained use is occurring without an exception record: record an authorized bounded exception with its limits and review condition or Stop the use
Repeatable fix	Discovery workflows label candidate evidence separately from evidence that is ready for stated use and route it through a defined review path.
Controlled disposition	Disposition reference: D-03, Ungoverned candidate evidence. Use this reference for candidate evidence that has not yet passed the applicable controls or received an approved constrained-use exception.
Example	An AI-discovered customer relationship is retained for investigation but remains Quarantined until ontology controls pass.
Non-example	A newly inferred relationship is added directly to an executive risk score without completing the required ontology review.
Authority and execution	Authority: Discovery owner may capture candidate evidence; the applicable governance, semantic, identity, relationship, or AI authority controls promotion toward stated use.
Retest	Compare the affected evidence’s actual holding or use with its Gate disposition. Verify prevention of prohibited reliance and compliance with any authorized constrained-use bounds. Containment Pass does not change another control’s Fail.

CORE-012: DACS Normative Version Is Pinned

Prerequisites	Pass required: CORE-001.
Specification requirement	Each control evaluation, Gate Record, and Conformance Record shall identify the exact normative DACS Specification version and applicable control-set version used for the evaluation.
Why this control exists	A historical Pass, Fail, Gate state, or conformance claim is not reconstructable unless the exact normative control definitions used at that time are known.
When this applies	Whenever any normative DACS evaluation, Gate Record, or Conformance Record is created or relied upon.
Evidence to inspect	DACS Specification version reference, applicable profile/control-set version reference, evaluation record, Gate Record where present, and Conformance Record where present.
Evidence sufficiency	DACS version/control-set references must be explicit and retrievable.
Assessment procedure	1. Inspect each evaluation and each Gate or Conformance Record where present. 2. Retrieve the exact Specification and applicable control-set/profile definitions referenced. 3. Confirm the definitions are those used by that evaluation; a later completed record is not a prerequisite for inspecting earlier independent evaluation evidence.
Control-result determination	Pass: The evaluation evidence, Gate Record, and Conformance Record where present identify the exact DACS Specification version and applicable profile/control-set version in force for the evaluation, and those references are retrievable. Fail: The normative DACS version cannot be determined, a later version is substituted retroactively for the version actually used, or the record cannot establish which control definitions governed the result.
Common failure modes	• Version omitted. • “Current DACS” used instead of exact version. • Later control wording substituted retroactively.
Remediation procedure	Add exact normative version references and preserve the referenced definitions; if the historical version cannot be established, the affected historical claim fails.
Repeatable fix	All DACS record schemas require normative-version fields.
Controlled disposition	Disposition reference: D-01, Missing prerequisite.
Example	Gate G-22 records DACS Specification v1.13 and the exact applicable profile/control-set version. Historical records retain the earlier version actually used.
Non-example	A historical Gate says only “DACS compliant” with no version.
Authority and execution	Authority: DACS record owner preserves version references; evaluator confirms the normative version used.
Retest	Reinspect the record and verify the exact normative definitions can be retrieved.

CORE-013: Context, Version, and Causal Order Are Preserved

Prerequisites	Pass required: CORE-012. Recorded result required: CORE-004, CORE-005, CORE-006, CORE-007, CORE-008.
Specification requirement	Each decision path relied on for stated use shall preserve the minimum context, artifact versions, and causal ordering required to reconstruct the state of information and control at the time of use. Distributed paths may use logical causal-order markers together with declared wall-clock uncertainty rather than requiring a universal DACS clock tolerance.
Why this control exists	Accountability depends on the state and causal order that existed at the time, not on current definitions, current artifacts, or assumptions that unavailable historical AI models can be recreated.
When this applies	When a decision path relied on for stated use must later be reconstructed using the context that was in force at the time of use.
Evidence to inspect	Context record, time-source reference, timestamps/effective periods, declared clock uncertainty where applicable, correlation/logical-order markers, source record, Semantic Contract/taxonomy/ontology/identity/data/data-model/process/AI-model version references where material, DACS Specification version, and historical-model reproducibility limitation where applicable.
Evidence sufficiency	Preserved evidence establishes the context and artifact versions effective at use. Distributed paths include the recorded ordering rule, authoritative time source, declared clock uncertainty, and correlation or logical-sequence evidence. Historical AI evidence distinguishes reconstruction from rerunning the original model. Insufficient: Current artifacts, timestamps without adequate ordering evidence, or a newer AI model run cannot establish the historical state.
Assessment procedure	1. Retrieve context, source assertions, scope and contract references, and all required effective versions. 2. Inspect time-source evidence and, for distributed paths, clock uncertainty and correlation or logical-sequence markers under the recorded ordering rule. 3. For unavailable historical AI models, inspect contemporaneous provider/model/version, inputs/context, output, available material parameters, tool/API use, and trace. 4. Confirm reproduction limitations are recorded and no current artifact is substituted for historical evidence.
Control-result determination	Pass: Preserved context establishes the timestamp or effective period, authoritative time source, source assertion, decision-scope identifier, Semantic Contract version, and applicable taxonomy, ontology, identity-rule, and DACS Specification versions. Record material data, data-model, AI-model, or process versions where available. Distributed paths also preserve declared clock uncertainty and correlation or logical-sequence evidence sufficient to establish causal order under the recorded ordering rule. When the historical AI model is unavailable, preserve contemporaneous provider/model/version identity, inputs and context, output, material parameters where available, tool/API use, and execution trace. Record that the original execution cannot be rerun. Complete contemporaneous evidence may support reconstruction even when reproduction is unavailable. Fail: Causal order cannot be established under the declared ordering rule, required historical artifact versions cannot be identified, a current artifact is substituted for a historical version, or an unavailable historical model is treated as reproducible without the original model. Unavailability of the historical model does not by itself fail reconstructability when contemporaneous evidence is otherwise complete, but the reproducibility limitation must be recorded.
Common failure modes	• Current definitions explain a historical decision. • Causal order cannot be established across distributed traces. • Model/provider/version is missing. • A newer AI model is treated as reproduction of the original.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-09 - Missing execution record If current definitions are being used to explain a historical decision: restore or reference the semantic versions that were effective at the time of use If a required taxonomy, ontology, identity, or context version is missing: add the missing historical version reference or reassess the evidence if the original state cannot be established If the Gate Record or readiness state was not preserved: restore the contemporaneous Gate evidence when it exists; otherwise rerun the applicable Gate before relying on the evidence for stated use If source assertions were overwritten: restore the historical source assertion from verifiable evidence when possible; if the original assertion cannot be established, reassess the affected evidence and do not claim historical reconstructability If required context exists only in memory, email, or informal notes: convert verifiable context into a governed historical context record; if the required historical state cannot be proven, do not treat the decision path as reconstructable
Repeatable fix	Context is recorded as part of the evidence package at execution or Gate time, not reconstructed from memory later.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when required historical context cannot yet be retrieved for the decision path relied on for stated use.
Example	The record preserves source assertion time, Semantic Contract v4, taxonomy v7, identity rule v2, Gate G-12, and readiness state.
Non-example	Only the current glossary and current mapping are available, so the meaning used three months earlier cannot be established.
Authority and execution	Authority: Decision-scope owner defines required context; evidence custodians preserve the historical versions and Gate records.
Retest	Reconstruct the state and event order from the required context and effective versions. Verify distributed-ordering evidence and any historical-model reproduction limitation. Do not use a newer model as proof of the original execution.

CORE-014: Gate Record Is Created

Prerequisites	Pass required: CORE-012. Recorded result required: CORE-002, CORE-003, CORE-013.
Specification requirement	Each controlled transition toward stated use shall capture the Gate determination and required record fields before or at that transition, using the exact DACS version applied. A completed Gate Record shall exist before the transition unless the path uses the bounded Buffered Gate Capture procedure in Section 9.1. That procedure permits delayed durable persistence, not delayed authorization.
Why this control exists	Gates convert governance from policy into operational control.
When this applies	At each material transition from candidate or governed evidence toward stated use.
Evidence to inspect	Gate Record with complete minimum payload including DACS Specification/control-set version references.
Evidence sufficiency	A completed Gate Record has the full Section 9.1 payload and the exact normative versions. A permitted buffered path captures the complete determination before action and durably persists it within the declared interval measured from capture time. Insufficient: A later approval, partial capture, promised future record, or missed persistence deadline does not satisfy the record requirement.
Assessment procedure	1. Retrieve the Gate Record and check every Section 9.1 field against its scope and effective versions. 2. Compare the determination and capture time with the transition or action time. 3. If buffering is used, verify complete pre-action capture, stable Gate ID, trace link, and declared maximum persistence interval. 4. Verify durable completion within that interval. Assess completion when the evidence exists or the deadline expires; do not pre-record Pass. 5. Verify required follow-up evaluations are separate from controls actually evaluated before action and later events preserve the original determination.
Control-result determination	Pass: The completed Gate Record contains Gate ID, scope identifier/version, DACS Specification version, applicable profile/control-set version, evaluated control IDs and results, evidence references, timestamp/effective period, authority or approved automated rule reference, readiness state, applicable constraint/exception reference, validity condition for Proceed or Caution, and review condition. Where buffering is used, the complete pre-action capture and subsequent durable record also satisfy Section 9.1. Fail: A required field or valid normative-version reference is missing, the transition occurs without the required completed record or authorized complete pre-action capture, or buffered persistence violates Section 9.1.
Common failure modes	• Approval occurred in a meeting or chat but no Gate record exists. • Gate record omits evaluated controls or readiness state. • Responsible authority or approved rule reference is unclear. • A Gate is recorded after the transition it was supposed to control.
Remediation procedure	Pattern references: R-09, R-14, R-18 If fields or version references are missing: recover only verifiable evidence and record a linked finding; do not invent historical authorization. If action preceded authorization or complete capture: record the failure and correct the future execution barrier. If buffering lacks a bound or misses its deadline: record a linked failure, apply CORE-017 failure handling, and reassess affected further reliance. If later completion overwrote the original event: restore verifiable history and create linked completion or replacement records.
Repeatable fix	The Gate captures a complete versioned determination before the transition. Permitted buffering has a measured persistence interval and creates linked completion or failure events.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when the required Gate Record does not exist or is incomplete for the transition.
Example	Gate G-12 captures the scope, versions, controls actually evaluated, evidence, authority, Caution bounds, validity, and trace link before action. Required execution follow-up evaluations are listed separately. Durable persistence completes within the declared interval.
Non-example	An action runs first; a later approval is backdated and the record marks execution-completion controls Pass before their evidence exists.
Authority and execution	Authority: The recorded decision-scope authority or approved rule governs the Gate determination. Execution: Authorization and complete capture precede the controlled transition. Only durable persistence may be delayed under Section 9.1; later completion does not authorize an earlier action.
Retest	Inspect a controlled transition and the complete Section 9.1 payload. For buffering, verify capture precedes action, persistence meets its declared interval, completion checks are evidence-backed, and all later events link to the unchanged original capture.

CORE-015: Gate Record Is Structured

Prerequisites	Recorded result required: CORE-014.
Specification requirement	Each Gate Record shall be structured so its required fields are machine-readable or exportable as a data object.
Why this control exists	A Gate Record must be inspectable and exchangeable evidence, not merely a human-readable statement.
When this applies	Whenever a completed Gate Record is created, queried, exported, exchanged, or assessed, including completion of a permitted buffered record.
Evidence to inspect	Completed structured Gate Record, exportable Gate object or equivalent, field-level evidence for Section 9.1, and authorized retrieval or export evidence. Where buffering is used, include the pre-action capture, declared persistence interval, and durable-persistence result.
Evidence sufficiency	An authorized query or export exposes every Section 9.1 field as structured data. If buffering is used, the record includes complete pre-action capture and evidence of durable persistence within its declared interval. Insufficient: A readable narrative, screenshot, approval email, or partial structured object does not establish that every required Gate field can be retrieved as structured data.
Assessment procedure	1. Retrieve the completed Gate Record through an authorized query or export. 2. Compare its structured fields with the Section 9.1 payload and applicable control requirements. 3. Verify stable scope, control, evidence, authority, timing, readiness, validity, review, and reconstruction references. 4. For a buffered path, inspect complete capture, declared interval, and durable-persistence result. Do not claim Pass before required completion evidence exists.
Control-result determination	Pass: The Gate Record can be consumed, queried, exported, or exchanged as structured data. It contains every required field under Section 9.1. Fail: The Gate outcome exists only as unstructured narrative, slide content, email approval, log text without the required fields, or undocumented assertion.
Common failure modes	• Gate outcome exists only in narrative or email. • Structured export omits required payload fields. • Evidence or control references are flattened into untraceable prose. • Buffered capture is incomplete or persistence misses its deadline.
Remediation procedure	Pattern references: R-01, R-09, R-14, R-18 If the outcome is narrative only: represent every required Gate field in a structured record. If fields or stable references are omitted: correct the schema and preserve traceable references. If authorized consumers cannot retrieve the fields: provide a queryable or exportable representation. If buffering is incomplete or late: record the failure and correct capture/persistence handling without rewriting the original Gate event.
Repeatable fix	A versioned Gate schema or equivalent structured record exposes the complete required payload to authorized consumers and retains linked capture and persistence evidence.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when the completed Gate Record or its required structured fields cannot be established. Apply the actual Gate logic; a structure check does not grant permission for material use.
Example	An authorized JSON export exposes Gate ID, scope/version, control results, evidence, authority, timing, readiness, validity, constraints, review, and reconstruction references.
Non-example	Approval is available only as an email paragraph, and required Gate fields cannot be retrieved as structured data.
Authority and execution	Authority: The Gate record owner is accountable for its required fields; the platform or evidence custodian maintains authorized structured retrieval. Execution: Test the completed record’s structure and any applicable buffered-completion evidence separately from the original authorization.
Retest	Query or export the remediated completed Gate Record. Confirm every required field is structured and retrievable. Verify buffering completion where used; preserve any earlier creation or timing failure as a separate result.

CORE-016: Readiness Validity Is Declared and Enforced

Prerequisites	Recorded result required: CORE-014.
Specification requirement	Each Proceed or Caution Gate readiness state shall declare and enforce a Readiness Validity Condition for new material reliance. Historical Gate Records remain immutable evidence of the state determined at their original evaluation time.
Why this control exists	Readiness is scope-bound and time-bound. A prior permitted state shall not remain valid silently after its declared validity condition ends.
When this applies	Whenever a Proceed or Caution Gate state is relied on for new material use, and when its recorded expiration or reassessment trigger occurs.
Evidence to inspect	Gate Record, Readiness Validity Condition, expiration/trigger evidence, reassessment record where triggered, new Gate Record where reassessed, and immutable prior Gate Record.
Evidence sufficiency	Each Proceed or Caution state has a recorded validity condition. Evidence shows that expiration or a declared trigger blocks new material reliance or invokes the required reassessment. Original Gate Records remain unchanged. Insufficient: A review date alone does not establish enforcement when use continues after expiry or triggering change without reassessment.
Assessment procedure	1. Inspect validity conditions for each Proceed or Caution state under review. 2. Verify an expiration, effective-period end, event trigger, or authorized no-fixed-expiration rule with defined triggers. 3. Inspect or test expired and triggered conditions; confirm new reliance is blocked or reassessed. 4. Trace any new evaluation to the preserved original Gate Record.
Control-result determination	Pass: Each Proceed or Caution state has an expiration timestamp, effective-period end, event-triggered reassessment rule, or explicitly authorized no-fixed-expiration rule with defined reassessment triggers; new material reliance is blocked or reassessed when the condition expires or triggers; and historical records are not retroactively rewritten. Fail: New material reliance continues after expiration/trigger without reassessment, or historical Gate Records are retroactively changed rather than linked to a new evaluation.
Common failure modes	• Proceed or Caution has no declared validity condition. • New use continues after expiration or a declared trigger. • No-fixed-expiration is assumed without authority or triggers. • A new state overwrites the historical Gate Record.
Remediation procedure	Pattern references: R-08, R-18 If validity is missing: record an authorized expiration or reassessment rule. If use continues after expiry or a trigger: block affected new reliance and reassess it. If no-fixed-expiration is assumed: obtain explicit authority and define reassessment triggers, or set a bounded validity period. If history was overwritten: restore verifiable prior records and link the new evaluation.
Repeatable fix	Recorded Gate validity is checked before new reliance. Expiration and material-change triggers invoke reassessment and preserve the earlier determination.
Controlled disposition	Disposition reference: D-04, Change or reassessment. Use this reference when readiness has expired or a declared trigger requires reassessment before new reliance.
Example	A Proceed state expires Friday. On Monday, the workflow blocks new use until a linked Gate evaluation establishes a current readiness state; Friday’s record remains unchanged.
Non-example	A prior Proceed state is reused indefinitely after its validity period ends.
Authority and execution	Authority: The decision-scope authority approves the validity condition and any no-fixed-expiration rule. The responsible workflow or process owner enforces it. Execution: Check validity for new reliance and preserve linked reassessment evidence when the condition expires or triggers.
Retest	Test an expiration and an applicable reassessment trigger. Verify affected new reliance is blocked or reassessed and the historical Gate Record remains unchanged.

CORE-017: Runtime Enforcement Failure Is Governed

Prerequisites	Recorded result required: CORE-014, CORE-015, CORE-016.
Specification requirement	Each material automated or hybrid path that depends on a Gate or Context Enforcement Point shall declare and enforce behavior for enforcement-service failure, loss of authoritative state, stale cached policy, or unavailable prerequisite evidence.
Why this control exists	Control infrastructure failure must not silently become permission to act.
When this applies	When a material automated or hybrid path depends on Gate or Context Enforcement Point availability.
Evidence to inspect	Runtime failure policy, fail-closed rule, degraded-mode authorization where applicable, action-class boundary, authority reference, constraints, expiration, invalidation triggers, execution evidence, and Gate/trace records.
Evidence sufficiency	A fail-closed rule or pre-authorized bounded degraded mode must exist before failure.
Assessment procedure	1. Simulate or inspect enforcement-service failure. 2. Confirm material actions stop by default. 3. If degraded mode exists, verify pre-authorization, action class, constraints, expiry, invalidation, and evidence capture.
Control-result determination	Pass: The path fails closed by default for material action, or uses a previously authorized bounded degraded mode whose action class, authority, constraints, evidence requirements, expiration, and invalidation triggers were recorded before the failure; no action outside that degraded-mode authorization is permitted. Fail: A material action proceeds because the enforcement mechanism is unavailable, a degraded mode is improvised after failure, the authorization is expired or broader than the action, or required evidence cannot be preserved.
Common failure modes	• “Fail open” on service outage. • Degraded mode improvised during outage. • Cached state expired but still used.
Remediation procedure	Pattern reference: R-16 Implement fail-closed behavior for material action. If continuity requires a degraded mode, obtain prospective authorization for its exact bounded action class, authority, constraints, evidence requirements, expiration, and invalidation triggers. Do not improvise permission during an outage or infer that reversibility alone authorizes action.
Repeatable fix	Runtime design includes tested fail-closed behavior and governed degraded-mode policy.
Controlled disposition	Disposition reference: D-05, Threshold, constraint, or conflict.
Example	A payment recommendation service blocks external release when Gate service is unavailable; a pre-approved read-only advisory mode may continue for 15 minutes under Caution.
Non-example	Transactions continue because the policy service timed out.
Authority and execution	Authority: Business/risk owner authorizes any degraded mode before an outage; engineering enforces it.
Retest	Test outage behavior and confirm unauthorized material action cannot occur.

CORE-018: Conformance Record Exists

Prerequisites	Pass required: CORE-012. Recorded result required: CORE-003, CORE-014, CORE-016.
Specification requirement	Each claim of decision-scope conformance, or recorded DACS determination of readiness for stated use, shall be supported by a completed Conformance Record bound to the exact DACS version used. A readiness determination may preserve failed controls and authorized constraints; the record does not make those results conformant.
Why this control exists	A claim of stated use without an evidence record is an assertion, not a DACS conformance outcome.
When this applies	Whenever decision-scope conformance is claimed or a DACS determination of readiness for stated use is recorded.
Evidence to inspect	Conformance Record, DACS Specification/control-set version references, profile-applicability determination, control results, evidence links, Gate/readiness references, authority, timestamp/effective period, review condition, and recorded limitations.
Evidence sufficiency	The completed Conformance Record supports the exact scope-bound readiness or conformance determination and includes every Section 9 field and applicable control requirement. It preserves failed results and constraints where present. Insufficient: The existence of a record, badge, or readiness claim does not prove the other controls passed. A complete record of Caution with failed controls does not establish full scope conformance.
Assessment procedure	1. Identify the readiness or conformance determination being assessed. 2. Retrieve its completed Conformance Record and exact scope and normative-version references. 3. Verify every Section 9 field and CORE-018 criterion, including independently established profile applicability, all applicable results, evidence, Gate, authority, timing, review, and limitations. 4. Check that any full-conformance claim is supported by all applicable mandatory results, rather than by the record’s existence.
Control-result determination	Pass: The record includes decision scope/version, DACS Specification version, applicable profiles/control-set versions, the independently established profile-applicability determination, applicable controls and Pass/Fail/Not Applicable results, evidence links, Gate Record/readiness state, responsible authority or approved rule reference, timestamp/effective period, review condition, and any recorded limitations including unavailable historical-model reproducibility where relevant. Fail: A required readiness or conformance determination lacks a complete Conformance Record, required fields are missing, or the normative version used cannot be established.
Common failure modes	• A readiness-for-stated-use claim appears in a report or presentation with no Conformance Record. • The record exists but omits failed controls or exceptions. • Evidence links are out of date. • The review condition or responsible authority or approved rule reference is missing.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-09 - Missing execution record If DACS conformance is claimed without a Conformance Record: create the required Conformance Record before making the claim or remove the claim If the Conformance Record omits failed controls, exceptions, or other required results: complete the record so the full control outcome is visible If evidence links are outdated or broken: repair the links to the evidence used for the stated determination If the review condition or responsible authority or approved rule reference is missing: record the required authority or approved rule reference and review condition before relying on the claim
Repeatable fix	A Conformance Record is produced from a standard record structure after Gate evaluation, with required control, evidence, authority, timestamp, and review fields.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when stated-use readiness is claimed but the required Conformance Record is missing.
Example	The decision scope has a Conformance Record listing all applicable controls and their results, evidence links, readiness state, responsible authority or approved rule reference, and review condition.
Non-example	A slide claims that evidence is ready for stated use under DACS, but no scope-bound Conformance Record exists.
Authority and execution	Authority: The responsible authority approves the Conformance Record within the stated scope. An approved rule may generate or populate the record under that authority.
Retest	Retrieve the completed record supporting each affected determination. Verify all required fields and links, and ensure failed controls, exceptions, and limitations remain visible. Check any full-conformance claim independently against the applicable results.

CORE-019: Conformance Record Is Structured

Prerequisites	Recorded result required: CORE-018.
Specification requirement	Each Conformance Record shall be structured so that decision scope, control IDs, control results, evidence references, readiness state, timestamp, and responsible authority or approved rule reference are machine-readable or exportable as a data object.
Why this control exists	A Conformance Record must be actionable evidence, not merely a presentation artifact.
When this applies	Whenever a Conformance Record is created, queried, exported, exchanged, or relied upon by an authorized downstream process or reviewer.
Evidence to inspect	Structured Conformance Record, exportable control result object, metadata record, API response, table record, graph record, JSON/XML/YAML document, or equivalent structured evidence.
Evidence sufficiency	Every required Conformance Record field under Section 9 is available as structured data to an authorized process or reviewer. Insufficient: A partial structured export or free-form explanation does not satisfy the requirement when any required scope, version, profile, result, evidence, Gate, authority, timing, rule, validity, constraint, review, or reconstruction field is missing.
Assessment procedure	1. Query or export the Conformance Record through an authorized mechanism. 2. Compare all fields with Section 9 and the applicable control requirements. 3. Verify required values and stable references remain structured and retrievable; do not treat a partial field list as the complete payload.
Control-result determination	Pass: The record contains every required Conformance Record field under Section 9. An authorized process or reviewer can consume, query, export, or exchange those fields as structured data. Fail: The DACS conformance determination exists only as unstructured narrative, slide content, email approval, or undocumented assertion.
Common failure modes	• The DACS conformance determination exists only as narrative, email, or slide content. • Structured record omits stable control IDs. • Exports flatten evidence links into prose. • Downstream systems cannot query result or readiness state.
Remediation procedure	Pattern reference: R-01 - Missing evidence If the DACS conformance determination exists only as narrative, email, slide content, or another unstructured artifact: create a structured Conformance Record with stable fields for the required DACS elements If the structured record omits stable control identifiers: add the applicable DACS control IDs and their results If an export converts evidence references into prose that cannot be followed: preserve structured evidence references or stable links in the exported record If authorized downstream users or processes cannot query the result or readiness state: make the required fields machine-readable or exportable without relying on narrative interpretation
Repeatable fix	A defined schema, table, record type, or export format is used consistently and can be queried or exchanged.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Use this reference when the Conformance Record exists only as unstructured narrative and cannot support structured review or exchange.
Example	The Conformance Record is stored as structured records and exportable as JSON for authorized review.
Non-example	Approval exists only as an email paragraph and cannot be queried by control or decision scope.
Authority and execution	Authority: Evidence or platform owners maintain the structured record. The accountable record owner ensures that the required DACS fields remain available to authorized consumers. Execution: The Conformance Record must be queryable or exportable as structured data with stable control, result, evidence, readiness-state, timestamp, and responsible-authority or approved-rule fields.
Retest	Query or export every required Conformance Record field under Section 9. Confirm authorized consumers can retrieve structured values and references without interpreting free-form narrative.

CORE-020: Evidence and Record Integrity Is Verifiable

Prerequisites	Recorded result required: CORE-005, CORE-013, CORE-014, CORE-018, CORE-019.
Specification requirement	Material evidence, Gate Records, Conformance Records, execution traces, and control-result records shall preserve verifiable integrity appropriate to the stated decision scope.
Why this control exists	Reconstruction is not defensible when the organization cannot establish that the evidence and records being reviewed are the records that existed when the decision was made.
When this applies	When material evidence or DACS records are stored, transferred, reviewed, or relied upon.
Evidence to inspect	Integrity mechanism reference, hash/signature/immutable-log/WORM/ledger or equivalent evidence, record identifier and version, authority/custodian, effective period, and integrity-verification result.
Evidence sufficiency	An implementation-neutral integrity mechanism must detect unauthorized alteration/substitution.
Assessment procedure	1. Select material records. 2. Verify hash/signature/immutable log/WORM/ledger or equivalent evidence. 3. Attempt or inspect change detection. 4. Verify authority and effective period.
Control-result determination	Pass: Each required material record has a verifiable integrity mechanism that can detect unauthorized alteration or substitution and the integrity evidence is itself attributable and retrievable for the applicable effective period. Fail: A material record can be altered without detection, the integrity evidence is missing or unverifiable, or a substituted record cannot be distinguished from the record originally used.
Common failure modes	• Mutable spreadsheet with no revision integrity. • Hash exists but is stored with the file and can be changed silently. • Gate Record altered without audit evidence.
Remediation procedure	Pattern references: R-14, R-18 Add a verifiable integrity mechanism appropriate to the recorded scope and preserve its verification evidence. Recover original integrity only from verifiable contemporaneous support. If original integrity cannot be established, retain the historical failure or limitation; a new protected record and evaluation do not prove the old record was unchanged.
Repeatable fix	Material DACS records use a standard integrity-control pattern.
Controlled disposition	Disposition reference: D-01, Missing prerequisite.
Example	Gate Records are stored in an immutable audit log with signed record digests.
Non-example	A JSON export can be edited and replaced without any detectable change.
Authority and execution	Authority: Evidence custodian operates the integrity mechanism; decision-scope authority determines required protection.
Retest	Verify the integrity mechanism against representative records and confirm alteration is detectable.

CORE-021: Rule and Threshold Changes Are Prospective and Versioned

Prerequisites	Pass required: CORE-012. Recorded result required: CORE-002.
Specification requirement	Materiality Rules, Applicability Rules, Equivalence Rules, Multi-Value Rules, vector criteria, thresholds, authority rules, and other decision-scope predicates shall be versioned and effective before the dependent evaluation whose result they govern.
Why this control exists	DACS does not permit moving the decision boundary or threshold after observing evidence in order to manufacture a Pass.
When this applies	Whenever a materiality, applicability, threshold, equivalence, vector, or authority rule governs an evaluation.
Evidence to inspect	Versioned rule/threshold record, authority reference, effective period, change record, prior version reference, dependent evaluation timestamp, and replacement-evaluation reference where applicable.
Evidence sufficiency	Rule version/effective time must precede the dependent evaluation.
Assessment procedure	1. Compare rule effective time to evaluation time. 2. Inspect change history. 3. Confirm later rule changes created new evaluations and did not rewrite prior results.
Control-result determination	Pass: Each governing rule or threshold has a version, authority, effective period, and change record showing that it was established before the dependent evaluation; any later change creates a new evaluation version and does not retroactively alter the prior result. Fail: A rule or threshold is changed after observing the result and applied retroactively, an effective period cannot be established, or the prior rule version is overwritten.
Common failure modes	• Threshold lowered after a failure. • Prior rule version overwritten. • New applicability rule applied retroactively.
Remediation procedure	Restore prior rule history, create governed prospective versions, and retest under the valid rule. Do not re-label the prior result.
Repeatable fix	Rule-management process enforces effective dating and immutable version history.
Controlled disposition	Disposition reference: D-06, Determinacy or repeatability.
Example	Confidence threshold v3 became effective Monday; Friday’s failed v2 evaluation remains failed and a new v3 evaluation is linked.
Non-example	The reviewer changes the threshold in the same record after seeing the score.
Authority and execution	Authority: Rule owner approves prospective changes; evaluator verifies effective dating.
Retest	Replay the audit trail and confirm each result used the rule effective before that evaluation.

CORE-022: Evaluation and Remediation History Is Append-Only

Prerequisites	Recorded result required: CORE-014, CORE-018, CORE-020, CORE-021.
Specification requirement	Control evaluations, Gate Records, Conformance Records, failures, exceptions, remediation actions, and retests shall preserve append-only historical lineage; later results shall not overwrite prior results.
Why this control exists	A corrected state does not erase the historical state on which earlier decisions were made.
When this applies	Whenever a control is retested, remediated, replaced, or re-evaluated.
Evidence to inspect	Evaluation history, prior-result references, remediation/change records, retest records, version links, timestamps, authority, and retention/deletion evidence where applicable.
Evidence sufficiency	Each new evaluation must append and link rather than overwrite.
Assessment procedure	1. Select a remediated control. 2. Retrieve original result and all retests. 3. Verify version links, timestamps, remediation cause, and Gate/Conformance transitions.
Control-result determination	Pass: Each retest or replacement evaluation creates a new versioned event linked to the prior result, preserves the prior Pass/Fail/Not Applicable result and Gate state, and records the remediation or change that caused reassessment. Fail: A prior failure or Gate state is overwritten, deleted without lawful authority, or replaced without a traceable version link.
Common failure modes	• Failed result deleted after fix. • New Gate state overwrites old state. • Retest has no link to remediation.
Remediation procedure	Restore append-only history from verifiable evidence where possible and change the workflow so every retest creates a linked event.
Repeatable fix	Evaluation service/workflow uses immutable event history or versioned records.
Controlled disposition	Disposition reference: D-04, Change or reassessment.
Example	CORE-007 fails, remediation R-44 is recorded, then a new CORE-007 evaluation passes and links to the failed result.
Non-example	The same spreadsheet cell is changed from Fail to Pass with no history.
Authority and execution	Authority: Record owner preserves history; assessors create new evaluation events.
Retest	Trace a sample from initial result through remediation and retest without losing any prior state.

CORE-023: Material Semantic Binding Change Triggers Forward Reassessment

Prerequisites	Pass required: CORE-021, CORE-022.
Specification requirement	Each decision path relied on for stated use shall define change-detection rules for material physical, logical, conceptual, Semantic Contract, taxonomy, ontology, identity, context, model, policy, or authority changes that could affect future readiness or conformance. Historical Gate and Conformance Records shall remain immutable evidence of what was evaluated under the versions effective at that time.
Why this control exists	Change should govern active and prospective reliance without rewriting history or forcing unnecessary retroactive execution of completed historical decisions.
When this applies	When physical, logical, conceptual, semantic, taxonomy, ontology, identity, or context bindings can materially change after a prior readiness or conformance determination.
Evidence to inspect	Version/change event, impact rule, affected-scope record, readiness-cache invalidation or suspension evidence, reassessment/new Gate or Conformance Record where required, and immutable prior record references.
Evidence sufficiency	The change-control evidence must show which semantic-binding changes are considered material, how affected decision scopes are identified, and how those changes trigger impact review, Gate reassessment, readiness-state update, or conformance-status update. Insufficient: A change log is not sufficient when a material change can be recorded without identifying affected decision scopes previously allowed for stated use or triggering the required reassessment and status update.
Assessment procedure	1. Inspect detection rules for material physical, logical, conceptual, contract, taxonomy, ontology, identity, context, model, policy, and authority changes. 2. Inspect or test a qualifying change and trace affected active or prospective scopes. 3. Verify required readiness invalidation or suspension and reassessment before future reliance. 4. Confirm historical records remain unchanged and new determinations link to prior evidence.
Control-result determination	Pass: Qualifying changes identify affected active or prospective decision scopes, invalidate or suspend cached readiness for new reliance as defined, and trigger impact review, Gate reassessment, readiness-state update, or Conformance Record replacement before future material use; historical records remain unchanged and linked to the new assessment when reused. Fail: A material change can affect future reliance without detection/reassessment, historical results are retroactively rewritten, or historical evidence is reused for a new decision without evaluation under current applicable rules.
Common failure modes	• Mappings change without impact detection. • Version changes are logged but do not trigger Gate reassessment. • Changes in identity or context are outside the monitoring rule. • Readiness for new reliance is not reassessed after a material binding change.
Remediation procedure	Version the changed artifact, identify only affected active/prospective scopes, invalidate readiness for new reliance where required, and reassess before future use. Do not retroactively rewrite historical Gate/Conformance Records.
Repeatable fix	Version/change events invoke a repeatable impact-assessment rule that identifies affected scopes and required reassessment.
Controlled disposition	Disposition reference: D-04, Change or reassessment. Use this reference after a material semantic-binding change until affected decision scopes have been identified and reassessed.
Example	A taxonomy grain change automatically opens reassessment for all decision scopes previously allowed for stated use that reference that node.
Non-example	A source field is repurposed, but dashboards previously allowed for stated use continue with no review.
Authority and execution	Authority: Owners of affected semantic, identity, taxonomy, ontology, source, and context bindings participate in impact review under the decision-scope authority. Execution: Change detection must identify affected decision scopes and invoke the defined reassessment path when a material binding changes.
Retest	Inspect or trigger a representative qualifying change. Confirm affected active or prospective scopes are identified, cached readiness is invalidated or suspended as defined, required reassessment precedes new reliance, and historical records remain unchanged.

CORE-024: Lawful Evidence Preservation and Deletion Are Governed

Prerequisites	Recorded result required: CORE-013, CORE-020, CORE-022.
Specification requirement	When law, regulation, contract, privacy policy, or authorized retention rule requires evidence minimization or deletion, DACS evidence preservation shall comply while retaining the strongest lawful reconstruction anchor available.
Why this control exists	DACS must preserve accountability without requiring organizations to violate privacy, GDPR, retention, contractual, or other lawful deletion obligations.
When this applies	When material evidence is subject to lawful minimization, deletion, retention, or contractual destruction requirements.
Evidence to inspect	Retention/deletion rule, legal or policy authority, affected evidence identifier/version, deletion/minimization record, lawful reconstruction anchor where retention is permitted, integrity/provenance metadata where permitted, timestamp, and the resulting reconstruction limitation where applicable. If no lawful anchor may remain, record that limitation.
Evidence sufficiency	Evidence establishes the applicable deletion or minimization authority, action, affected evidence identity and time, and the strongest reconstruction anchor that may lawfully remain. If no anchor may remain, the limitation and constrained reconstruction claim are recorded. Insufficient: An anchor is not sufficient if retaining it violates the applicable rule. Unrecorded deletion or a claim of full reconstruction without lawful supporting evidence also fails the test.
Assessment procedure	1. Identify required deletion/minimization. 2. Verify authority and timing. 3. Inspect Lawful Reconstruction Anchor. 4. Verify reconstructability claims are constrained if the law forbids retaining enough evidence.
Control-result determination	Pass: Required deletion or minimization is authorized and recorded, the affected evidence is handled according to the applicable rule, and a lawful reconstruction anchor preserves the evidence identity, provenance, version/effective period, integrity reference where permitted, deletion authority, deletion time, and the metadata needed to establish what evidence existed and why it is no longer retained. If no lawful reconstruction anchor may be retained, that limitation shall be explicitly recorded and affected reconstructability claims shall be constrained accordingly. Fail: Unlawful retention, undocumented deletion, deletion without authority, substitution of current evidence for deleted historical evidence, or a claim of full historical reconstructability when required evidence and all lawful anchors are unavailable.
Common failure modes	• Raw personal data retained beyond lawful period “for DACS.” • Evidence deleted with no record of what existed. • Current evidence substituted for deleted historical evidence.
Remediation procedure	Follow the lawful retention/deletion rule, create the strongest permitted reconstruction anchor, record the resulting limitation, and revise any overstated reconstructability claim.
Repeatable fix	Retention workflows integrate DACS reconstruction metadata with privacy/legal deletion controls.
Controlled disposition	Disposition reference: D-04, Change or reassessment.
Example	A governed deletion removes raw customer data and retains only the provenance, evidence identity, version, integrity reference, authority, and timing permitted by the applicable rule. If no anchor may remain, that limitation constrains the reconstruction claim.
Non-example	Data is either retained unlawfully or deleted without any governed record.
Authority and execution	Authority: Privacy/legal/records authority governs deletion; DACS evidence owner preserves only what is lawful.
Retest	Verify deletion compliance and confirm the surviving anchor supports only the reconstructability claim actually made.

CORE-025: Decision Path Is Reconstructable

Prerequisites	Pass required: CORE-013, CORE-018, CORE-020, CORE-022. Recorded result required: CORE-010, CORE-024.
Specification requirement	Each analytic output, AI-assisted recommendation, automated action, human decision, or decision path relied on for stated use shall be linked to a reconstructable decision path using preserved governed evidence. Human-operated paths may satisfy this requirement through a Human Decision Record. Reconstructability does not require reproduction of an unavailable historical proprietary AI model.
Why this control exists	Defensibility requires evidence of what actually supported the decision at the time. Reproduction is desirable when possible, but unavailable proprietary historical models must not be falsely recreated with newer models.
When this applies	Whenever a material analytic, AI-assisted, automated, or human decision path is relied on for stated use or later challenged/reviewed.
Evidence to inspect	Decision-path record, Human Decision Record where applicable, identity/taxonomy/ontology/context/version references, causal-order evidence where applicable, Gate Records, output/action/decision record, authority, exception record where applicable, AI execution evidence/model identity where applicable, and explicit reproducibility limitation where the original model is unavailable.
Evidence sufficiency	The path must be explainable from recorded evidence, not undocumented memory. Human steps may use a Human Decision Record. If an original proprietary AI model is unavailable, contemporaneous execution evidence may establish reconstruction but the record must explicitly distinguish non-reproducibility.
Assessment procedure	1. Select a material decision. 2. Traverse identities, meanings, relationships, artifact versions, context, causal order, Gates, authority, evidence, exceptions, and output/action. 3. For human steps inspect Human Decision Records. 4. For AI steps verify model/provider/version and contemporaneous trace; if the model is unavailable, verify the non-reproducibility limitation is explicit. 5. Confirm no newer model is being used as proof of the historical result.
Control-result determination	Pass: An authorized reviewer can retrieve the material identities, classifications, applicable relationships, context and artifact versions, applicable causal order, Gate Records and readiness states, evidence references, output/action/decision state, exceptions, and authority that existed at the time of use. Reconstruction shall use preserved evidence rather than undocumented memory. For a material human step, the Human Decision Record preserves the actor or role, authority, material inputs and evidence, applicable rule or criterion, decision or action, timestamp/effective period, material override or exception, and Gate reference. If the historical AI model is unavailable, contemporaneous model/provider/version identity, inputs and context, material parameters where available, tool/API use, output, and execution trace shall establish what occurred. Record the reproduction limitation. A result from a newer model is comparison evidence and shall not be represented as reproduction of the historical execution. Fail: Reconstruction depends on undocumented human memory, required contemporaneous AI execution evidence is unavailable, a newer model is substituted as proof of the historical model result, or causal/artifact-version evidence cannot establish the state used at the time.
Common failure modes	• Reconstruction depends on analyst memory. • Historical taxonomy/model/version is unknown. • A newer AI model is rerun and presented as reproduction. • Human approval has no recorded basis or authority.
Remediation procedure	Preserve or restore verifiable historical references, create Human Decision Records for future manual steps, strengthen execution traces, and record non-reproducibility when the original model is unavailable. If the historical basis cannot be established, do not claim reconstructability.
Repeatable fix	Decision outputs retain stable links to versioned evidence, Gates, Human Decision Records where applicable, execution traces, and explicit reproducibility status.
Controlled disposition	Disposition reference: D-01, Missing prerequisite. Do not claim the path is reconstructable while a required material element remains unprovable.
Example	An auditor can establish the exact evidence, taxonomy/ontology versions, authority, Gate state, human override, model/provider/version and output used at the time, even though the retired proprietary model itself cannot be rerun.
Non-example	The team reruns the same prompt against a newer model and treats a different output as proof of the original decision.
Authority and execution	Authority: Decision-scope owner is accountable; evidence/model/process owners preserve the records they control. Reconstruction and reproduction are explicitly distinguished.
Retest	Repeat the historical reconstruction from records only. Confirm required elements are retrievable and any unavailable-model limitation is accurately stated.