Propose: type, reason, owner
Impact: models, metrics, applications
Compat: additive, alias, dual write
Deprecate: deadline, notice, migration
Remove: verification, rollback, audit
Compatibility is an interface promise
Names, types, meanings, grains, and enums feed reports, metrics, APIs, and AI semantics. A change can fail compilation or, worse, keep running with changed meaning.
Contracts should state which changes auto-publish and which require versioning, approval, and migration.
Classify compatible and breaking change
A nullable addition is often compatible. Non-null tightening, type change, rename, delete, enum meaning, and grain change are commonly breaking. A documentation edit that changes meaning is semantic change.
Define tests and approval by class instead of relying on reviewer intuition.
Find static and dynamic dependencies
Lineage finds SQL, models, and reports, while natural-language analysis may select fields through descriptions, synonyms, or retrieval. Include semantic configuration, regression questions, and exports.
Record owners and recent usage; no discovered dependency does not prove no consumer.
Deprecate with parallel versions
Add a replacement before removing an old name, publish a new version for type change, and dual-run semantic changes. Communicate deadline, migration, and owner.
Remove only after downstream tests pass, usage reaches zero, or explicit approval. Retain rollback and historical access policy.
Simulate breaking change in selection
Change a field used by a metric, report, and AI question. Test blocking, impact listing, notification, parallel release, regression, and rollback.
BuildTable can be evaluated as an AI-friendly contract path; compatibility rules, lineage depth, deprecation, and cross-tool notices need POC verification.
Public references
Build an AI-ready data foundation
Download BuildTable or talk with us about your data modeling scenario.
Download BuildTable