Skip to main content
A data contract is a formal agreement between a data producer and downstream consumers: expected schema, nullability, value ranges, freshness SLAs, and ownership. In Planasonix, contracts attach to datasets or pipeline outputs and drive validation during CI, execution, or both.

​
Contract creation

1

Choose the subject

Select a table, topic, or pipeline output stage the contract governs.
2

Define schema rules

Specify columns, types, keys, allowed enums, and null constraints. Import from Avro/JSON Schema/SQL DDL when supported to avoid transcription errors.
3

Add quality checks

Layer row-level rules (for example, amount >= 0, country in ISO set) beyond raw types.
4

Set severity

Decide whether violations fail the pipeline, quarantine rows, or only emit warnings to diagnostics.
5

Publish

Version the contract; consumers pin to a version until they opt into upgrades.

​
Schema validation

During runs, Planasonix compares incoming batches to the contract:
  • Additive changes (new nullable columns) often pass automatically when policy allows.
  • Breaking changes (type narrowing, dropped columns) fail fast or require a new contract version.
Owning teams update contracts when they ship schema changes; CI blocks merges that skip contract bumps.

​
Violation tracking

The violations view lists timestamps, rule names, sample offending rows (redacted per policy), and pipeline runs. Export violations for incident tickets or compliance evidence.

​
Enforcement

Enforcement hooks include:
Quarantine tables may contain sensitive values. Apply retention, encryption, and access controls identical to production data classes.

​
Lake write enforcement

Contracts can be assigned to Managed Lakehouse destination nodes to validate every record before writing to Iceberg and Delta tables. This is configured in the pipeline canvas under the destination’s Advanced Settings.

​
Enforcement modes on lake writes

​
How it works

  1. Each incoming batch is validated against the assigned contract
  2. In warn mode, all records are written and violations are logged
  3. In block mode, the batch is split — valid records commit to the lakehouse, invalid records are sent to the DLQ with the original payload, failed rule name, and expected vs actual values

​
DLQ routing

When enforcement mode is block, rejected records appear in the DLQ page and include:
  • Original record payload
  • Contract ID and version
  • Failed rule name with expected vs actual
  • Pipeline run ID for traceability
After fixing the source data or relaxing the rule, you can reprocess DLQ entries to land them in the lakehouse.

Contract Enforcement on Lake Writes

Full guide to contract configuration and the partition advisor

Data catalog

Document datasets contracts protect.

Impact analysis

See who breaks when contracts change.

Dead letter queue

Triage contract-failed records from lake writes.