Adoption Overview¶

This document helps architects and enterprise evaluators assess DTCS for their organization.

Not production-certified. Spec 3.0.0 is a draft. Tools 0.13.0 are alpha. Tables labeled Covered mean the reference implementation exercises that draft area — they are not a green-light procurement matrix or an external certification.

What DTCS provides¶

DTCS standardizes transformation semantics as portable, vendor-neutral contracts. A DTCS contract captures:

Input and output schemas (with optional field constraints)
Semantic actions (field transforms and dataset operators), expressions, functions, and rules
Lineage with explicit operation / information-flow flow
Guarantees and compatibility declarations
Metadata (governance, ownership, lifecycle, provenance, classification, deprecation)
Versioning policies
Distinctions among null, missing, and invalid values at runtime

It does not define execution engines, storage, orchestration, or SQL dialects.

Reference implementation maturity¶

Maturity: Spec 3.0.0 (draft) · tools alpha (0.13.0). The table below is a reference-exercise map, not a certification or procurement scorecard. Prefer reading limits.md and what-dtcs-is-not.md before treating any row as “done for production.”

Limitations first¶

Spec is a draft; tools are alpha
dtcs run is an in-memory teaching runtime, not warehouse ETL
Advanced A.9 profiles are Experimental; kernel/relational /2 and portable-window/2 are Candidate (not Standard)
WASM/Node expose parse/validate/declare only

Coverage map (reference exercises draft SPEC areas)¶

Component	Reference impl status
Specification	Draft (`3.0.0`, 27 chapters + Appendix A catalog)
Parser (YAML/JSON)	Exercises draft COM parse
Seven-phase validation	Exercises draft validation
Metadata validation	Exercises draft metadata rules
Type system (incl. expressions)	Exercises draft typing
Compatibility analysis	Exercises five classification levels
Evolution analysis	Exercises same-identity revisions
Versioning validation (Ch 25)	Exercises draft versioning
Lineage analysis (dataset-level)	Exercises `operation` / `flow` in COM
Identifier registry & extensibility	Exercises registry merge
Standard libraries (Ch 17–19)	Exercises full catalog
Static semantic analysis	Exercises analyzer profile
Transformation plan lowering	Exercises planner
Plan optimization	Exercises optimizer
Capability matching	Exercises match against reference profile
Compilation	Exercises compiler
Reference runtime	Exercises small in-memory runs
Portable Relational (0.12 `/1`)	Exercises joins, windows, datetime, complex access, portable plans
Rich Portable Analytics (0.13 / Ch 27)	Exercises plan v2; `/2` Candidate; A.9 Experimental families
Conformance certification (Ch 23)	Exercises offline profiles + portable fixtures
SPEC completeness matrix	Living implementer matrix — not external certification

Released reference implementation: 0.13.0.

See ROADMAP.md for the full milestone plan and spec-completeness.md for the chapter matrix.

Pip-first evaluator path (no clone)¶

pip install 'dtcs==0.13.0'
dtcs version
# quick first success — prefer validate before full conformance:
curl -fsSL https://raw.githubusercontent.com/eddiethedean/dtcs/main/examples/minimal.dtcs.yaml \
  -o contract.dtcs.yaml
dtcs validate contract.dtcs.yaml
# optional deeper gate:
dtcs conformance run --profile all

Then follow getting-started.md for a pasteable validate + dtcs run micro-example. Clone the repository only when you need examples/ or tests/fixtures/.

What you can use today¶

Contract authoring — write YAML/JSON contracts with IDE/CI validation
CI gates — fail builds on invalid contracts (dtcs validate --json)
Standard library usage — reference the full dtcs: action, function, and rule catalogs; validate against embedded definitions (dtcs registry list)
Static semantic analysis — check transformation semantics and expressions without runtime evaluation (dtcs analyze)
Version management — compare contract revisions for breaking changes (dtcs compat, dtcs evolve)
Impact analysis — trace which outputs depend on an input (dtcs lineage --impact)
Plan lowering — produce canonical transformation plans from validated contracts (dtcs plan)
Plan optimization — apply semantics-preserving rewrites to lowered plans (dtcs optimize)
Capability matching — verify a plan against an engine profile (dtcs match)
Compilation — produce execution plans from transformation plans (dtcs compile)
Reference execution — run contracts end-to-end with sample inputs (dtcs run)
Conformance certification — offline profiles via dtcs conformance declare / dtcs conformance run (including portable profiles)
Portable plan export — dtcs export-portable (Rust and Python CLIs); Python plan_export_portable
Governance hooks — metadata validation enforces owner/steward on restricted classifications

What is explicitly out of scope¶

Production ETL execution (Spark, Polars, SQL compilation)
Multi-backend compilers beyond the reference profile
External certification authority (Ch 23 §13)

See non-goals.md.

WASM and Node bindings (@eddiethedean/dtcs-wasm, @eddiethedean/dtcs) are available for parse, validate, and conformance declare.

Security considerations¶

Normative security guidance is in SPEC.md Chapter 24. At a high level:

Contracts are declarative documents — the validator parses and analyzes them; it does not execute arbitrary code from contract bodies
Extension fields are preserved but validated for structure
Namespace validation rejects ambiguous http: / https: identifiers
Governance metadata can enforce owner/steward requirements on restricted classifications

The reference validator performs static analysis only. It does not connect to external systems, networks, or secrets.

For governance requirements, see SPEC Chapter 26 and the metadata validation rules in Chapter 5. Automated probes: security-checklist.md.

Distribution¶

Channel	Package
Rust	crates.io/crates/dtcs
Python	pypi.org/project/dtcs
WASM	`@eddiethedean/dtcs-wasm`
Node	`@eddiethedean/dtcs`
Source	github.com/eddiethedean/dtcs

Rust and Python packages install the same dtcs CLI.

Evaluation checklist¶

Pip-first (no clone):

[ ] pip install 'dtcs==0.13.0' and dtcs version shows Spec 3.0.0
[ ] Validate the curlable minimal sample (getting-started.md)
[ ] Run the no-clone hello contract with dtcs run
[ ] Run offline conformance: dtcs conformance run --profile all
[ ] Review security-checklist.md for Ch 24 probes
[ ] Read versioning.md and limits.md

Clone-required (richer fixtures):

[ ] Review diagnostic output for schema and lineage gaps (operation / flow)
[ ] Author or review a dataset action with parameters (for example dtcs:project)
[ ] Exercise null / missing / invalid tokens with dtcs run and inspect JSON carefully
[ ] Compare current and proposed contract versions with dtcs compat
[ ] Trace lineage for critical inputs with dtcs lineage --impact
[ ] Match / compile / run examples/customer_pipeline.dtcs.yaml with its fixture input
[ ] Skim migration-0.13.md if upgrading to tools 0.13 / Spec 3.0 (historical 0.12: migration-0.12.md)
[ ] Read SPEC Chapters 1–3 and Appendix A

Conformance certification is available via dtcs conformance declare and dtcs conformance run. See conformance.md. External certification authority remains out of scope per Ch 23 §13.

Getting started¶

Practitioners: getting-started.md · cli-guide.md · writing-contracts.md

Relationship to other standards¶

Standard	Relationship
JSON Schema / Avro / Protobuf	Schema formats; DTCS adds transformation semantics, lineage, and governance
OpenAPI	API contracts; DTCS focuses on data transformation semantics
dbt	Transformation execution; DTCS contracts could describe dbt model semantics portably
W3C PROV	Provenance; DTCS lineage covers dataset-level input→output mappings

DTCS is complementary — it does not replace schema or API standards but adds a transformation contract layer above them.

Questions¶

Open a GitHub issue or see faq.md.