5. Profile 1: Core Decision-Scope Controls
Purpose: Establish the minimum control foundation for any DACS decision scope. Core controls apply to every DACS conformance evaluation.
CORE-001: Decision Scope Is Declared
Prerequisites: None.
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.
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.
Evidence required: 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.
Rationale: 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.
Application guidance (informative): Choose one named business decision or use. Record its included and excluded uses, grain, owner, identifier, and version before reviewing its evidence.
CORE-002: Materiality and Conditional Applicability Are Bound Before Dependent Controls
Prerequisites: Pass required: CORE-001.
Requirement: The decision scope shall establish recorded rules or authority references for every conditional predicate it uses. These include materiality, applicability, approval, authorization, equivalence, compatibility, multi-value, and any other condition that affects a requirement or its test. Each rule shall exist independently of the result it governs.
Pass: Every conditional predicate required by the decision scope has a recorded rule or authority reference. Each reference includes an 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 the assessor inventing a rule or interpretation. No predicate relies on Circular Reliance. The organization has supplied the governing rule, so no DACS fallback threshold is required.
Fail: A required predicate rule is missing, incomplete, expired, or subjective. The control also fails if the rule is created from the dependent result, relies on Circular Reliance, or cannot resolve the predicate from recorded facts. DACS does not supply a fallback materiality or vector threshold.
Evidence required: 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.
Rationale: Binary controls require conditions that can be resolved from recorded facts and a defined evaluation order. Conditional language cannot be left to assessor discretion. A predicate cannot be justified by a downstream result that depends on that same predicate.
Application guidance (informative): Identify the conditions used by the selected scope and controls. Retrieve the approved rules or authority references that resolve each condition from observable facts.
CORE-003: Applicable Profiles Are Declared
Prerequisites: Pass required: CORE-002.
Requirement: Each conformance evaluation shall record which DACS profiles apply to the stated decision scope, using the recorded profile Applicability Rules.
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.
Evidence required: Profile Applicability Rules, profile-applicability record, scope mapping, and reasons for excluded profiles.
Rationale: Profiles keep DACS narrow while preventing material controls from being skipped.
Application guidance (informative): Apply the recorded profile rules to the scope. Record why each profile applies or is excluded, then link that determination to the final assessment record.
CORE-004: Semantic Contract Exists
Prerequisites: Pass required: CORE-003.
Requirement: A decision scope shall have an identified Semantic Contract before evidence is relied on for material use.
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.
Evidence required: Semantic Contract record, identifier, owner, version, decision-scope mapping, and references to every component required by the applicable profiles.
Rationale: Without a Semantic Contract, meaning, identity, relationship, context, and Gate controls cannot be tested consistently.
Application guidance (informative): Locate the governed agreement for meaning, identity, relationships, context, and use. Check its owner, version, scope, and links to applicable components.
CORE-005: Physical Attribution or Boundary Evidence Anchor Is Recorded Where Required
Prerequisites: Pass required: CORE-002.
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.
Pass: One of two evidence paths establishes attribution for the decision scope. The evidence item records source-level attribution that allows it to be located, interpreted, and tested. Alternatively, when direct source-level visibility is legitimately unavailable, a Boundary Evidence Anchor records the exact external evidence consumed. That anchor includes 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, and contract/SLA/attestation reference where available. It also records 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.
Evidence required: 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.
Rationale: Material evidence must be traceable without making conformance impossible when the organization cannot lawfully or technically inspect a third-party or legacy internal schema.
Application guidance (informative): Trace each material evidence item to its source. If direct inspection is unavailable, inspect the boundary anchor and its exact external-evidence reference.
CORE-006: Logical-to-Conceptual Binding Exists Where Required
Prerequisites: Pass required: CORE-004, CORE-005.
Requirement: Each logical information element used in a material decision path shall map to an approved business concept.
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.
Evidence required: Logical-to-conceptual mapping record, business concept identifier, owner, version, source reference where required, decision-scope mapping.
Rationale: Logical meaning must be tied to governed business meaning before it supports DACS conformance for the stated scope.
Application guidance (informative): List the logical fields or information elements used by the decision. Verify their mappings to approved business concepts for this use.
CORE-007: Business Identity Anchors Exist Where Required
Prerequisites: Pass required: CORE-004.
Requirement: Each identity-bearing concept used in a material decision path shall have a Business Identity anchor.
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.
Evidence required: 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.
Rationale: Without identity, the enterprise cannot reliably compare history, reconcile systems, reconstruct decisions, or defend analytics.
Application guidance (informative): For each concept whose instances matter, locate the identifier or resolution rule that distinguishes the specific business instance involved.
CORE-008: Semantic Grain Is Declared for Identity-Bearing Evidence
Prerequisites: Pass required: CORE-007.
Requirement: For each material Business Identity, semantic grain shall be recorded for each identity-bearing evidence item at every point where the decision path consumes it. Where that evidence is transformed, aggregated, split, or reconciled across grains, the source grain, transformation rule, and resulting grain shall be recorded.
Pass: Every identity-bearing evidence item records the business level at which it is unique and meaningful where it is consumed. That grain is linked to the decision scope. Each material grain transition records the source grain, resulting grain, and 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.
Evidence required: 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.
Rationale: 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.
Application guidance (informative): Check the grain where each identity is consumed. Inspect the source grain, governing rule, and resulting grain for every material transition.
CORE-009: Business Concept Is Not Assumed to Be Business Identity
Prerequisites: Pass required: CORE-007.
Requirement: A business concept shall not be treated as a Business Identity unless identity evidence is recorded.
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.
Evidence required: Business concept record, decision-scope mapping, and the distinct identity rule, identifier mapping, or approved resolution method used for each identity-bearing use.
Rationale: A concept defines meaning; identity distinguishes a specific instance.
Application guidance (informative): Check that a concept label is not the sole identity evidence. Find the identifier or resolution method for the instance being counted or acted upon.
CORE-010: Identity Resolution Produces Determinate Results
Prerequisites: Pass required: CORE-002. Recorded result required: CORE-007, CORE-008.
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.
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.
Evidence required: Identity-resolution method and version, tested inputs, rule set, threshold, scope reference, repeat-test results, and exception record where applicable.
Rationale: Material decisions require repeatable identity outcomes.
Application guidance (informative): Repeat the identity-resolution test with unchanged inputs and configuration. Compare outcomes, including unresolved results; repeatability alone does not resolve an identity conflict.
CORE-011: Discovered Evidence Is Quarantined Until Governed
Prerequisites: Recorded result required: CORE-002, CORE-003.
Requirement: Candidate evidence shall be held under a recorded disposition that prevents material reliance unless the applicable Gate explicitly permits the stated use.
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.
Evidence required: 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.
Rationale: Quarantined allows candidate evidence to remain available for exploration while preventing untested evidence from being relied on for material decisions by default.
Application guidance (informative): Check how candidate evidence is held and reviewed. Inspect the Gate or exception evidence before accepting any material reliance on it.
CORE-012: DACS Normative Version Is Pinned
Prerequisites: Pass required: CORE-001.
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.
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. 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.
Evidence required: DACS Specification version reference, applicable profile/control-set version reference, evaluation record, Gate Record where present, and Conformance Record where present.
Rationale: A historical Pass, Fail, Gate state, or conformance claim is not reconstructable unless the exact normative control definitions used at that time are known.
Application guidance (informative): Retrieve the exact DACS and control-set versions used by the assessment. Check that recorded historical results have not been relabeled with a newer version.
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.
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.
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.
Evidence required: 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.
Rationale: 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.
Application guidance (informative): Retrieve the context and versions effective at the time of use. For distributed execution, inspect the recorded evidence of event order and clock uncertainty.
CORE-014: Gate Record Is Created
Prerequisites: Pass required: CORE-012. Recorded result required: CORE-002, CORE-003, CORE-013.
Requirement: Each controlled transition toward stated use shall capture the Gate determination and required record fields before or at that transition. The capture shall identify 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.
Pass: The completed Gate Record contains Gate ID, scope identifier/version, DACS Specification version, applicable profile/control-set version, evaluated control IDs and results, and evidence references. It also contains 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.
Evidence required: Gate Record with complete minimum payload including DACS Specification/control-set version references.
Rationale: Gates convert governance from policy into operational control.
Application guidance (informative): Inspect the Gate payload and its timing relative to the transition. For a buffered path, also inspect capture completeness and the persistence deadline.
CORE-015: Gate Record Is Structured
Prerequisites: Recorded result required: CORE-014.
Requirement: Each Gate Record shall be structured so its required fields are machine-readable or exportable as a data object.
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.
Evidence required: 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.
Rationale: A Gate Record must be inspectable and exchangeable evidence, not merely a human-readable statement.
Application guidance (informative): Inspect the completed Gate fields through an authorized structured export or query. Readable prose alone does not demonstrate a structured record.
CORE-016: Readiness Validity Is Declared and Enforced
Prerequisites: Recorded result required: CORE-014.
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.
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. 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.
Evidence required: Gate Record, Readiness Validity Condition, expiration/trigger evidence, reassessment record where triggered, new Gate Record where reassessed, and immutable prior Gate Record.
Rationale: Readiness is scope-bound and time-bound. A prior permitted state shall not remain valid silently after its declared validity condition ends.
Application guidance (informative): Check when the recorded readiness expires or requires reassessment. Verify that new use is blocked or reassessed when that condition occurs.
CORE-017: Runtime Enforcement Failure Is Governed
Prerequisites: Recorded result required: CORE-014, CORE-015, CORE-016.
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.
Pass: The path blocks material action by default when enforcement fails, or uses a previously authorized bounded degraded mode. For that mode, the 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.
Evidence required: 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.
Rationale: Control infrastructure failure must not silently become permission to act.
Application guidance (informative): Inspect the approved failure policy. Test whether loss of enforcement blocks material action or permits only a previously authorized, bounded degraded mode.
CORE-018: Conformance Record Exists
Prerequisites: Pass required: CORE-012. Recorded result required: CORE-003, CORE-014, CORE-016.
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.
Pass: The record includes decision scope/version, DACS Specification version, applicable profiles/control-set versions, and the independently established profile-applicability determination. It also includes applicable controls and Pass/Fail/Not Applicable results, evidence links, Gate Record/readiness state, responsible authority or approved rule reference, timestamp/effective period, and review condition. It preserves 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.
Evidence required: 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.
Rationale: A claim of stated use without an evidence record is an assertion, not a DACS conformance outcome.
Application guidance (informative): Retrieve the completed record supporting the readiness or conformance determination. Check required results, evidence, authority, versions, and recorded limitations.
CORE-019: Conformance Record Is Structured
Prerequisites: Recorded result required: CORE-018.
Requirement: Each Conformance Record shall contain structured fields for decision scope, control IDs, control results, evidence references, readiness state, timestamp, and responsible authority or approved rule reference. Those fields shall be machine-readable or exportable as a data object.
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.
Evidence required: Structured Conformance Record, exportable control result object, metadata record, API response, table record, graph record, JSON/XML/YAML document, or equivalent structured evidence.
Rationale: A Conformance Record must be actionable evidence, not merely a presentation artifact.
Application guidance (informative): Check that every required Conformance Record field can be retrieved or exported as structured data by an authorized reviewer.
CORE-020: Evidence and Record Integrity Is Verifiable
Prerequisites: Recorded result required: CORE-005, CORE-013, CORE-014, CORE-018, CORE-019.
Requirement: Material evidence, Gate Records, Conformance Records, execution traces, and control-result records shall preserve verifiable integrity appropriate to the stated decision scope.
Pass: Each required material record has a verifiable integrity mechanism that can detect unauthorized alteration or substitution. 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.
Evidence required: Integrity mechanism reference, hash/signature/immutable-log/WORM/ledger or equivalent evidence, record identifier and version, authority/custodian, effective period, and integrity-verification result.
Rationale: 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.
Application guidance (informative): Verify the integrity evidence for the records under review. Confirm that an altered or substituted material record would be detected.
CORE-021: Rule and Threshold Changes Are Prospective and Versioned
Prerequisites: Pass required: CORE-012. Recorded result required: CORE-002.
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.
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.
Evidence required: Versioned rule/threshold record, authority reference, effective period, change record, prior version reference, dependent evaluation timestamp, and replacement-evaluation reference where applicable.
Rationale: DACS does not permit moving the decision boundary or threshold after observing evidence in order to manufacture a Pass.
Application guidance (informative): Compare governing-rule effective times with evaluation times. A later rule change belongs to a new evaluation, not a revised historical result.
CORE-022: Evaluation and Remediation History Is Append-Only
Prerequisites: Recorded result required: CORE-014, CORE-018, CORE-020, CORE-021.
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.
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.
Evidence required: Evaluation history, prior-result references, remediation/change records, retest records, version links, timestamps, authority, and retention/deletion evidence where applicable.
Rationale: A corrected state does not erase the historical state on which earlier decisions were made.
Application guidance (informative): Follow the links from a retest to the prior evaluation and remediation. Confirm that the earlier result remains available rather than overwritten.
CORE-023: Material Semantic Binding Change Triggers Forward Reassessment
Prerequisites: Pass required: CORE-021, CORE-022.
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.
Pass: Qualifying changes identify affected active or prospective decision scopes. They invalidate or suspend cached readiness for new reliance as defined. Before future material use, they trigger impact review, Gate reassessment, readiness-state update, or Conformance Record replacement. Historical records remain unchanged and are 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.
Evidence required: 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.
Rationale: Change should govern active and prospective reliance without rewriting history or forcing unnecessary retroactive execution of completed historical decisions.
Application guidance (informative): Inspect a material change event and its affected scopes. Check the resulting invalidation or reassessment before new reliance on the changed evidence.
CORE-024: Lawful Evidence Preservation and Deletion Are Governed
Prerequisites: Recorded result required: CORE-013, CORE-020, CORE-022.
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.
Pass: Required deletion or minimization is authorized and recorded. The affected evidence is handled according to the applicable rule. A lawful reconstruction anchor preserves the evidence identity, provenance, version/effective period, integrity reference where permitted, deletion authority, and deletion time. It also preserves 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. 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.
Evidence required: 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.
Rationale: DACS must preserve accountability without requiring organizations to violate privacy, GDPR, retention, contractual, or other lawful deletion obligations.
Application guidance (informative): Inspect the applicable retention or deletion authority, the action taken, lawful remaining anchors, and any resulting reconstruction limitation.
CORE-025: Decision Path Is Reconstructable
Prerequisites: Pass required: CORE-013, CORE-018, CORE-020, CORE-022. Recorded result required: CORE-010, CORE-024.
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.
Pass: An authorized reviewer can retrieve the material identities, classifications, applicable relationships, context and artifact versions, and applicable causal order that existed at the time of use. The reviewer can also retrieve the Gate Records and readiness states, evidence references, output/action/decision state, exceptions, and authority from that time. 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.
Evidence required: 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.
Rationale: 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.
Application guidance (informative): Reconstruct a decision from preserved records without relying on memory. Trace the material evidence, authority, context, Gate determination, and resulting decision or action.