DACS v1.14 Release Candidate

Available at: https://dacs.datavaultalliance.com/documents/dacs-specification/

Founding Authors & Committee Leads:

Daniel Linstedt - CEO, DataVaultAlliance Holdings, LLC

Cindi Meyersohn - Chief Operating Officer, DataVaultAlliance Holdings, LLC

Companion doctrine: The Defensible Analytics Control Specification Manifesto

Control principle: Readiness for stated use is scope-bound and evidence-backed. Before material reliance can be evaluated or established, DACS requires testable evidence and recorded control results. It also requires a Gate Record that preserves the resulting readiness state.

Core assertion: A material decision path is defensible only when the organization can reconstruct and verify why it was permitted to rely on the evidence, meaning, identity, relationships, context, authority, and controls used for that stated use.

Document intent: Lean, implementable, binary, vendor-neutral, evidence-based control specification.

DataVaultAlliance maintains the authoritative DACS Specification and official DACS publications. Redistributed copies may become outdated. Verify the current authoritative version at dacs.datavaultalliance.com before relying on this publication.

What Is DACS?

DACS addresses the decision-accountability gap between information that is available or technically usable and evidence that is ready for a stated material use. It combines mature disciplines without replacing them, including data governance, metadata management, taxonomy, ontology, provenance, data quality, identity, analytics controls, AI output evaluation, drift detection, audit evidence, and decision-path reconstruction. DACS defines the control evidence required when outputs from those disciplines are relied on within a stated decision scope.

Acknowledgments

DataVaultAlliance Holdings LLC may acknowledge individual reviewers who provide their critique and subject-matter feedback during the review process. Reviewer names are published only with the reviewer's permission. Named reviewers are advisory contributors, not authors or approvers, and listing does not imply endorsement of every provision or of the final specification. DataVaultAlliance Holdings LLC retains editorial control and may revise, defer, reject, or reframe feedback based on DACS doctrine, field evidence, legal review, and release governance.

Abstract

The Defensible Analytics Control Specification, or DACS, defines binary controls for determining whether decision evidence is ready for the stated use within a stated decision scope. DACS is vendor-neutral and implementation-neutral. It is not a product category, software platform, consulting slogan, data model, governance program, or AI tool.

DACS exists because an enterprise can have governed data, lineage, catalogs, semantic layers, AI controls, observability, and complete execution logs and still be unable to show why a material decision was permitted to rely on the evidence it used. The unresolved issue is decision-scope accountability: whether the identities, meanings, classifications, relationships, context, authority, and evidence supporting the stated use were governed, applicable, and reconstructable at the time of reliance.

DACS defines the controls and evidence obligations used to establish that readiness. Accountable authorities own the obligation. Governed human, procedural, or automated mechanisms execute the controls, record the results, apply Gate logic, and preserve the evidence needed to reconstruct and challenge the decision path when necessary.

DACS controls may be executed manually, procedurally, automatically, or through hybrid workflows. The implementation mechanism does not determine conformance with this specification. Conformance requires testable evidence, recorded control results, applicable Gate readiness states, and the required structured records for the stated decision scope. For every applicable normative control, all mandatory Pass criteria and required evidence elements must be satisfied; otherwise the control result is a Fail.

Introduction

Enterprises can now connect data, infer patterns, generate recommendations, and automate actions faster than they can explain the authority and evidence behind a material decision. They must be able to reconstruct why that decision was permitted to rely on the evidence it used. Analytics, AI-assisted recommendations, automated decision paths, and agentic execution operate across many environments. These include operational systems, SaaS platforms, data warehouses, lakehouses, data fabrics, data mesh domains, semantic layers, catalogs, BI tools, machine learning pipelines, workflow engines, and AI agents.

These technologies are valuable. Their presence can establish availability, movement, visibility, execution, or technical control. They do not, by themselves, establish that the evidence was valid, authorized, and ready for the stated decision use.

Discovery identifies candidate identities, classifications, relationships, patterns, signals, risks, outputs, and decision evidence. DACS treats those discoveries as candidates until applicable controls and Gate evaluation establish the permitted readiness state for the stated use. Full DACS conformance requires all applicable mandatory controls to Pass or be Not Applicable with a reason.

DACS therefore focuses on the evidence conditions that make material reliance testable: governed meaning, stable identity, physically anchored classification and relationships, preserved context, accountable authority, explicit constraints, Gate Records and resulting readiness states, and reconstructable records. Extended Taxonomy and Extended Ontology exist to make semantic and relationship claims testable against the physical evidence used in the decision path, not merely to document concepts.

Candidate evidence may be captured, explored, reviewed, remediated, or routed through additional Gates without being treated as decision-ready. It must not be relied on for material decisions until the applicable controls and Gate logic establish the permitted readiness state. An authorized constrained-use exception may support a Caution state, but it does not convert a Fail into a Pass or establish full DACS conformance.

How to use this Specification

This specification is written for managers, practitioners, assessors, governance teams, and technical implementers who define a decision scope, collect evidence, execute controls, or review the result. Executives may also use it to inspect the requirements behind a decision.

Start with CORE-001 to record the decision or use being reviewed and its boundaries. Use CORE-002 to establish the recorded rules needed to resolve conditional requirements. Then determine the applicable profiles and evaluate their controls in dependency order. A control ID identifies a requirement; its catalog position does not determine execution order.

Each control lists its immediate prerequisites first. It then states its own requirement, Pass and Fail conditions, required evidence, and rationale. Apply the global prerequisite and assessment rules in Section 3.2 before recording Pass. Application guidance explains a practical next action and adds no mandatory requirement. A control that tests failure handling, containment, recording, or enforcement can Pass even when another control remains Fail. Inspect the Gate disposition before relying on such evidence.

1. Specification Architecture

DACS is organized into conformance profiles. Profiles keep the specification narrow enough to apply to one decision scope while ensuring that material concepts, identities, relationships, AI behavior, and evidence are not left untested.

Profile	Applies when	Primary question	Control families
Core Decision-Scope Controls	Every DACS decision scope.	Is the decision scope bounded, evidenced, gated, and reconstructable?	Scope, Semantic Contract, identity, context, materiality and applicability rules, Gates, readiness validity, evidence, Conformance Record.
Extended Taxonomy Controls	Material business concepts, terms, labels, classifications, identifiers, or meanings affect the decision path.	Can governed meaning be tied to the physical data estate and tested for the decision scope?	Classification, labels, semantic grain, physical anchors, source systems, identifiers, ownership, risk, usage boundaries.
Extended Ontology Controls	Material relationships or relationship paths affect the decision path.	Can governed relationship meaning be tied to physical relationship evidence and tested for the decision scope?	Relationship type, orientation, vector, provenance, joins, source evidence, permitted/prohibited paths, constraints, compatibility.
AI Context Contract Controls	AI, machine inference, generated classifications, generated relationships, agents, or AI-assisted recommendations affect the decision path.	Can AI behavior be tested against governed meaning, permitted relationships, valid context, and Gate criteria?	Binding AI Context Contract, AI inputs/outputs, drift, violations, execution trace, agent authority.

1.1 Document Architecture and Companion Materials

The DACS Specification is the normative control source. It defines what must be true, evidenced, gated, and reconstructable before evidence can be treated as ready for stated use within a stated decision scope.

Companion materials support use of this specification but do not replace it. The Manifesto explains doctrine; the Executive Brief explains sponsorship rationale; practitioner handouts, Gate templates, assessment workbooks, adoption guides, reference-alignment guidance, partner enablement materials, pilot kits, and future companion specifications provide examples, implementation patterns, training support, and maturity guidance. Partner-facing materials and pilot kits are designed to lower the cost of first adoption without relaxing normative control requirements.

Unless explicitly incorporated into a normative DACS control, companion materials are informative. A control passes only when the evidence required by the applicable control exists and satisfies the Pass condition for the stated decision scope.

1.2 Control Verification Method

Each normative DACS control is verified by inspecting evidence against the stated decision scope. The accountable authority owns the obligation; an assessor or authorized human, procedural, or automated mechanism performs the assessment. DACS defines the requirements and does not create its own authority.

First, resolve applicability using recorded rules and scope facts. Do not treat unresolved applicability as Not Applicable.

Next, inspect every required evidence element. Check its connection to the scope, the responsible owner or authority, and the version and period in which it is valid. Evaluate every mandatory Pass criterion.

Record Pass, Fail, or Not Applicable with the required reason and evidence references. Apply the relevant Gate logic under recorded authority. Preserve the results and references in the required records using the assessment and record-completion rules in Section 3.2.6.

Each normative control is supported by companion remediation guidance that explains common failure modes, remediation options, repeatable-fix patterns, controlled-disposition paths, examples, and non-examples without modifying the control requirement.

Detailed examples, sampling methods, assessor checklists, and worked artifacts belong in the DACS Assessment Guide and Example Workbook. Training may teach application. The normative test remains the control requirement, Pass condition, Fail condition, and required evidence in this specification. Examples, workbooks, pilot kits, and training materials illustrate how to apply controls. They do not create, modify, or relax normative DACS requirements unless incorporated into a future DACS release.

1.3 Sparse Specification Principle

DACS is intentionally sparse. It does not attempt to restate adjacent standards, prescribe every implementation pattern, or teach every assessment technique. It defines the mandatory control points that must be evidenced when adjacent disciplines, tools, models, standards, or governance practices produce information used in a material decision path.

1.4 Low-Friction Adoption and Ecosystem Boundary

DACS is designed for low-friction adoption. A first DACS use may begin with one decision scope, one Gate, one evidence packet, and one Gate Record with a resulting readiness state. This specification intentionally avoids requiring a complete enterprise implementation, a new platform, or full companion-specification adoption before first use.

Training partners, implementation partners, vendors, and internal teams may use DACS companion materials to teach, implement, pilot, or automate the controls. Those materials are informative unless incorporated into a normative control. Partner participation, training authorization, or tool support does not create DACS conformance by itself; conformance remains tied to evidence, control results, a Gate Record, the resulting readiness state, and the Conformance Record for a stated decision scope.