data-contractlisted

# data-contract Treats a dataset, table, or topic as a **product with an owner and a guarantee** — the agreement a producing team makes to everyone reading their data. Distinct from `api-contract-draft` (synchronous request/response + webhook interfaces): this governs *data at rest and in motion* — the warehouse table, the Kafka topic, the daily export — where the failure mode isn't a 500, it's a downstream model silently trained on a column whose meaning changed last Tuesday. ## How to respond 1. **Establish producer, consumers, and the asset.** What dataset (table / topic / file feed), who produces it, and **who consumes it** — because the consumer list is what makes a change "breaking". Ask at most 2 questions, spent on the asset's update mechanism (batch / streaming / CDC) and whether any consumer is outside the producing team's control (another team, a partner, a trained model). A dataset with unknown consumers can't have a contract — surfacing that is the first value. 2. **Specify schema with semantics, not just types.** Types prevent crashes; semantics prevent silent wrongness. Every field gets: name, type, **nullability**, **unit or allowed-values**, and a **one-line meaning**. ✅ *"`amount` — int64, not null, minor currency units (cents), the net charged after discounts"* — ❌ *"`amount` — integer"* (cents or dollars? gross or net? the model that assumed dollars is now off by 100×). Mark every field's `[required]` vs `[optional]` and whether `null` is a valid value