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, and analyze 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, and optimize plans with semantics-preserving rewrites — all read-only, no execution engine required.

Quick start · User docs · 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 · inspect · diagnostics · compat · evolve · lineage · registry · version

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

# 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

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"])

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.8:

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)
        │
        ▼
Transformation Plan

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.

Execution, backend compilation, and runtime behavior remain out of scope. See docs/implementation/non-goals.md.

Repository layout

Contributing

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

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.