DTCS — Data Transformation Contract Standard

Vendor-neutral contracts for data transformation semantics — describe what a transformation means without locking you to Spark, SQL, Polars, or any single runtime.

This repository contains:

• SPEC.md — normative DTCS 1.0 draft (26 chapters)
• Reference tools — parse, validate, analyze, plan, optimize, match, compile, and run contracts in Rust and Python

What you can do today: validate YAML/JSON contracts, resolve dtcs: identifiers through the embedded registry (including standard actions, functions, and rules), compare versions for compatibility, analyze evolution between revisions, trace dataset lineage, lower validated contracts to transformation plans, optimize plans with semantics-preserving rewrites, match plans against engine capabilities, compile to execution plans, run contracts in the reference in-memory runtime, and certify conformance across all eight implementation profiles — including end-to-end execution of sample contracts like customer_normalize.dtcs.yaml.

Documentation · Quick start · User docs · Adoption · Examples · Changelog · Roadmap

Install

Requirements: Python 3.9+ (PyPI package); Rust 1.75+ (cargo install or building from source).

pip install dtcs
cargo install dtcs

dtcs version
dtcs validate examples/customer_normalize.dtcs.yaml

Both packages install the dtcs CLI on PATH:

validate · analyze · plan · optimize · match · compile · run · inspect · diagnostics · compat · evolve · lineage · registry · conformance · version

Bindings: Python (pip install dtcs), WASM (@eddiethedean/dtcs-wasm), Node (@eddiethedean/dtcs).

Develop from source (requires Rust + maturin): see CONTRIBUTING.md.

Quick start

# Validate a contract (exit 0 = valid)
dtcs validate examples/customer_normalize.dtcs.yaml

# Analyze a contract (static semantics; no runtime evaluation)
dtcs analyze examples/customer_normalize.dtcs.yaml

# Lower a validated contract to a transformation plan
dtcs plan examples/customer_normalize.dtcs.yaml

# Optimize a lowered plan (contract path lowers first)
dtcs optimize examples/customer_normalize.dtcs.yaml
dtcs match examples/customer_normalize.dtcs.yaml
dtcs compile examples/customer_normalize.dtcs.yaml
dtcs run examples/customer_normalize.dtcs.yaml --input tests/fixtures/runtime/customer_normalize_input.json

# Human-readable summary
dtcs inspect examples/customer_normalize.dtcs.yaml

# Compare two contract versions
dtcs compat examples/analysis/backward_old.yaml examples/analysis/backward_new.yaml

# Trace lineage impact
dtcs lineage examples/analysis/lineage_multi.yaml --impact customers

# Resolve a standard identifier
dtcs registry resolve dtcs:lowercase

# Run conformance certification
dtcs conformance run --profile integrated-platform

import json
import dtcs

report = dtcs.parse_and_validate(
    open("examples/customer_normalize.dtcs.yaml", "rb").read()
)
assert dtcs.is_valid(report)

plan = dtcs.plan_lower(dtcs.parse_file("examples/customer_normalize.dtcs.yaml")["contract"])
optimized = dtcs.plan_optimize(plan["plan"])
assert dtcs.plan_equivalent(plan["plan"], optimized["plan"])

compiled = dtcs.compile_plan(plan["plan"])
inputs = json.loads(open("tests/fixtures/runtime/customer_normalize_input.json").read())
result = dtcs.runtime_execute(compiled["plan"], inputs)
assert dtcs.is_valid(result)
assert result["outputs"]["customer_clean"][0]["email"] == "alice@example.com"

Read docs/user/getting-started.md for a full walkthrough. For normative definitions, see SPEC.md — start with Chapter 3 (COM) and Chapter 9 (Validation).

Pipeline

The reference implementation through Phase 0.9:

DTCS Document
        │
        ▼
Parser → Canonical Object Model
        │
        ├──────────────────────────────┐
        ▼                              ▼
Validator (0.1–0.6)              Analyzer (0.3, 0.6)
        │                              │
        │  registry::resolve           ├─ compatibility::analyze
        │  stdlib definition checks    ├─ analyze_evolution
        ▼                              ├─ versioning::validate
Diagnostics                            └─ lineage::analyze
        │                              │
        ▼                              ▼
   Plan lowering (0.7)            Analysis reports
        │
        ▼
   Plan optimization (0.8)
        │
        ▼
   Capability matching (0.9)
        │
        ▼
   Compilation (0.9)
        │
        ▼
   Reference runtime (0.9)
        │
        ▼
Transformation Plan → Execution Plan → Outputs

Phase 0.2 adds metadata validation, extended type system checks, expression typing, and I/O interface depth. Phase 0.3 adds compatibility classification, evolution analysis, versioning validation, and dataset-level lineage analysis. Phase 0.4 adds the identifier registry, file/URI loading with offline cache, and registry-aware extension validation. Phase 0.5 embeds starter standard libraries for semantic actions, functions, and rules, and validates contract usage against structured registry definitions (target types, phases, arity, and return types). Phase 0.6 adds static semantic analysis. Phase 0.7 lowers validated contracts into transformation plans with dependency graphs and plan validation. Phase 0.8 optimizes plans with semantics-preserving expression, function, action, and rule passes. Phase 0.9 adds engine capability matching, compilation to execution plans, and a reference in-memory runtime covering all embedded dtcs: stdlib entries.

Production ETL orchestration and external engine backends remain out of scope. See docs/implementation/non-goals.md.

Repository layout

Testing

Integration tests, fixture manifests, and conformance cases are documented in docs/implementation/testing-plan.md. The embedded standard library exercises a starter catalog of semantic actions, functions, and rules (SPEC Ch 17–19); it is not an exhaustive stdlib conformance proof. See test-verification-report.md for current suite confidence.

Contributing

See CONTRIBUTING.md for editorial conventions, implementation guidelines, and the review process. See CODE_OF_CONDUCT.md for community standards.

When implementation guidance conflicts with the specification, SPEC.md wins. See docs/implementation/spec-usage.md.

License

Licensed under the Apache License, Version 2.0. See LICENSE.