Review the Data Contract

A data contract is the machine-readable description of a source’s objects: their properties, types, keys, and the descriptions that carry their meaning. Amfelt writes contracts in the Open Data Contract Standard, so they are readable by tools other than Amfelt (see the Data Contract Reference ).

The contract matters because it is the input to everything downstream. Layers are generated from it, the catalog is populated from it, and consumers can rely on it as the description of what they are reading.

Where It Lives  

In the project’s Git repository, alongside the rest of the project configuration. That means a contract change is reviewable and reversible the same way a code change is (see Review and Commit Changes ).

What to Check Before Data Moves  

• Types. Discovery reads what the source declares, and that is the type the data platform gets; a text property that holds dates stays text. Choosing a different type is on the roadmap.
• Keys. Primary and foreign keys drive how objects are historized (every change kept as a dated version) and related. A missing key is the most common cause of a layer that behaves oddly later.
• Descriptions. These are what the catalog and the generated documentation show. A column called st_cd with no description stays meaningless to everyone who finds it.

If a key or type is wrong, fix it at the source and run discovery again before the data platform objects exist and something is reading them. See Layers and Naming for what gets generated from the contract.

Versions  

Contracts are versioned. A later discovery run produces a new version rather than editing the old one in place, so earlier versions stay in the repository’s history.

Next  

Decide how the data should move: Choose a Load Strategy .