6. The DACS Control Model

DACS defines the control model for determining whether information is ready for stated use within a stated decision scope.

It does not rely on general confidence, informal trust, tool presence, governance intent, or data availability. It requires evidence.

DACS controls apply to the things that make decision paths defensible:

• governed business meaning;
• physically anchored classification;
• verified and validated Business Identity;
• approved relationship paths;
• preserved context;
• source and provenance evidence;
• usage boundaries;
• Gate criteria;
• readiness states;
• exceptions and remediation;
• reconstructable decision evidence.

The manifesto describes these requirements at the doctrine level. The DACS specification expresses them as binary controls through conformance profiles.

This distinction matters.

For a stated decision scope, each applicable control evaluates to Pass, Fail, or Not Applicable. Not Applicable requires a recorded reason. An exception may support constrained use and a Caution readiness state, but it does not convert Fail into Pass. An enterprise may begin with one decision path, one Gate, one evidence packet, and one readiness determination.

DACS therefore separates two concepts:

• Decision-scope conformance is established only when every applicable mandatory control for that scope Passes, or is recorded as Not Applicable with a recorded reason, in accordance with the DACS Specification.
• A DACS Capability Level describes organizational adoption across a declared boundary. It does not change control semantics, cause a control to Pass, or confer conformance on an unevaluated decision scope.

The purpose of the DACS control model is not to create bureaucracy. Its purpose is to make decision evidence testable, accountable, and reconstructable before information is treated as reliable for a stated use.

6.1 Identity Anchor

Every material decision path must begin with stable Business Identity.

DACS does not require every system to share one physical key. It requires the enterprise to know which business instance a decision path refers to, which source asserted that instance, which identifier or resolution rule established it, and at what semantic grain the identity is unique and meaningful for the stated decision scope.

Source-system identifiers, operational keys, generated IDs, matched records, mastered records, reference records, and semantic identifiers may all contribute identity evidence. They do not automatically constitute enterprise identity. For material use, identity evidence must be governed, repeatable, and tied to approved meaning.

Probabilistic, approximate, or AI-assisted identity methods may be valuable for discovery and resolution. For material use, as determined by the applicable Materiality Rule for the stated decision scope, the identity method may remain probabilistic, but the DACS control evaluation does not: the applicable control result is Pass, Fail, or Not Applicable. The associated Gate readiness state is Proceed, Caution, Stop, or Quarantined, as appropriate. An exception may support constrained Caution but does not convert Fail to Pass.

Without stable Business Identity, there is no reliable history. Without reliable history, there is no accountability. Without accountability, analytics cannot be defended.

In an implementation-neutral DACS context, this anchor may be represented by a stable business identifier, durable identity rule, approved resolution method, identity registry, semantic identifier, governed master or reference record, data model structure, metadata object, knowledge-graph node, or equivalent evidence construct. The requirement is not a specific artifact. The requirement is stable Business Identity anchored to governed meaning and a stated decision scope, as evidenced by the applicable control results, Gate Record, and resulting readiness state.

6.2 Accountable Relationship Vector

Every material relationship used in a decision path must be evaluated through an accountable relationship vector.

A relationship is not ready for stated use merely because it appears in a source system, lineage view, model, graph, dashboard, analytic output, or AI response. It is ready only when the relationship meaning, source, direction, evidence, constraints, and decision-scope applicability satisfy the associated controls and Gate criteria.

The vector records three elements:

• Confidence: How much evidence supports the relationship? Confidence measures evidence quality, support, repeatability, recency, and reliability.
• Strength: How strong is the relationship or signal? Strength measures the practical force of the relationship and whether it meets the decision-scope threshold for influencing a decision.
• Orientation: Which way does the relationship point? Orientation identifies direction, authority, sequence, dependency, ownership, lineage, hierarchy, flow, inclusion, identification, support, or causality when causality has been separately established.

These vector elements govern use, not merely describe risk. The decision scope must define the thresholds or qualitative criteria that determine whether a relationship is sufficient for the stated use. A detected association may show that two things are related, but it does not by itself establish the meaning or authority of that relationship. Temporal sequence establishes order, not causation. Dependency establishes reliance or connection, not ownership or accountability. And a relationship that is valid in one direction may not be valid in the reverse direction.

6.3 Preserved Context

Relationships, classifications, identities, and AI outputs do not exist in isolation. They exist at a point in time, under a set of conditions, from a source, within a process, under a definition, and inside a decision context.

DACS requires preserved decision context because meaning changes over time. A relationship may have been valid last quarter and invalid today. A policy may have changed. A hierarchy may have shifted. A customer may have moved segments. A product may have been reclassified. A regulatory interpretation may have evolved. A source system may have overwritten operational history.

If context is lost, the enterprise may still know what result was produced, but it cannot explain why that result was defensible at the time.

Preserved context allows the organization to compare what was true then with what is true now. It protects institutional memory, supports challenge and remediation, and makes reconstruction possible.

In an implementation-neutral DACS context, preserved context may be represented by temporal descriptive records, versioned assertions, provenance records, context logs, event history, semantic annotations, data model structures, or equivalent evidence objects. DACS requires the capability to preserve descriptive context over time, not a single physical implementation.

6.4 Reconstructable Decision Path

A defensible result must be reconstructable.

The enterprise must be able to show which identity was used, which classification applied, which relationships were followed, what context applied, which Gate Record and readiness state governed use, what evidence existed, what Conformance Record or other structured evidence record was produced, and what state of information was available at the time.

This is not limited to technical lineage. Technical lineage shows how data moved. DACS requires decision lineage: how identity, meaning, classification, relationship path, context, control results, Gate Records, readiness states, and evidence supported the result.

Reconstructability is not the same as reproducibility. A decision path can remain reconstructable even when the original model, service, or technology is no longer available, provided contemporaneous evidence preserves what was executed, the relevant versions, inputs and context, output, authority, control results, and Gate Record. A later run with a different model or version is comparison evidence; it is not reproduction of the original execution.

A result that cannot be reconstructed may still be useful. It may even be correct. But it is not defensible in the DACS sense.

6.5 Structured Evidence and Conformance Records

A Conformance Record preserves the scope-bound DACS determination in a structured form that supports review, exchange, audit, and reconstruction. Supporting evidence may remain in different systems or formats, but the record must preserve the required references. Narrative approval alone is not sufficient.

At minimum, the record identifies the decision scope, applicable DACS Specification and control-set versions, applicable Profiles and controls, control results, evidence references, Gate Records and resulting readiness states, the responsible authority or approved rule reference, timestamp or effective period, constraints or exceptions, and review conditions.

The Conformance Record preserves a scope-bound determination. It does not establish universal truth, guarantee decision correctness, or create organization-wide conformance.

Authorized downstream processes, auditors, governance workflows, and automation may use the recorded control results and readiness state to permit, constrain, block, review, or remediate use within the responsible authority.

DACS does not require all evidence to live in one tool. It requires sufficient records and evidence references to reconstruct and challenge the decision path.

Evidence preservation also requires integrity and lawful retention. DACS does not require indefinite retention of every raw artifact. When law, regulation, contract, privacy policy, or an authorized retention rule requires deletion or minimization, the organization preserves the most complete lawful reconstruction anchor available, the authority for the action, and any resulting limitation on reconstruction.

6.6 Controls Make Readiness Testable, Accountability Remains Assigned

DACS defines the criteria and evidence obligations. Accountable authorities own the obligation. Assessors, governed processes, or authorized automation execute controls. Evidence demonstrates what existed and whether the requirements were satisfied. Gates apply approved logic and record the resulting readiness state. Conformance Records preserve the scope-bound determination.

Execution does not create authority. An automated mechanism may execute a DACS control without becoming the accountable authority. A person may own an obligation without personally executing the control. Authority, execution, evidence, and recorded outcome must remain distinguishable.

This distinction allows organizations to formalize accountability without inventing a new bureaucracy. Existing business owners, stewards, risk functions, operational teams, technical teams, and executive decision routines can retain their responsibilities when authority, execution, and evidence are explicit.

Defensible Analytics is not created by documentation alone. It depends on controls being executed consistently, evidence being preserved, accountable authorities remaining visible, and decisions being reconstructable and challengeable when necessary.

6.7 Evidence-Based Readiness

DACS does not accept subjective confidence or general assertions of trust as conformance evidence.

Readiness is not established by saying information feels trustworthy, accountable enough, or appropriate enough. The assessment records what passed, what failed, what is Not Applicable, what remains constrained, what is Quarantined, what evidence exists, and what readiness state applies.

For DACS, readiness is evidenced through control results, required evidence, thresholds or approved rules, Gate Records and resulting readiness states, exceptions or constraints, and reconstructable decision paths. If a claim cannot be tested, it may be useful discussion language, but it is not sufficient to establish readiness for stated use.

Operational measurement may include relationship readiness, AI context readiness, Gate readiness, evidence readiness, and Quarantine visibility. Detailed indicator definitions belong in the DACS Specification and operational guidance; the Manifesto retains the doctrine that readiness must be observable and testable rather than asserted.