Write the data contract for a table other teams depend on

Write the data contract for a table other people and systems depend on. State the guarantees precisely enough that a consumer can tell when one has been broken.

The table: {{name, and one sentence on what a single row represents}}
How it is produced: {{source systems, the transformation, the schedule}}
Columns consumers read: {{name, type, and what the value means in business terms — especially any column whose meaning someone could reasonably get wrong}}
Known consumers: {{dashboards, scheduled reports, downstream models, an application, a retrieval index or agent}}
Decisions that ride on it: {{e.g. the revenue figure in the board deck, a churn alert, what a support agent tells a customer}}
How it has broken before: {{late loads, a silent schema change upstream, duplicates after a backfill, a definition that changed without a rename — or "no history"}}
Tests that exist today: {{paste them, or "none"}}

Produce the contract in these parts.

**What one row means.** The grain in one sentence, and what is deliberately excluded from it. Most arguments about a number turn out to be two people holding different grains.

**Column guarantees.** For each column a consumer reads: the type, whether null is legal and what a null signifies, the allowed range or value set, and the business definition. Flag every column whose name suggests a different meaning from the one it carries, because those are the ones that get misread quietly for months.

**Freshness and volume.** When the data lands, how stale it may be before consumers should stop trusting it, and the row-count range a healthy run produces. Write these as numbers a check can evaluate rather than as "daily".

**Ownership.** Who owns the table, who a consumer contacts when it breaks, and what that consumer should do in the hour before anyone answers.

**Checks, tiered by consequence.** Put every check in exactly one tier:
- *Block the load.* Failing this would put a wrong number in front of a person. Uniqueness on the grain, referential integrity to the entities being counted, non-null on the columns a decision reads.
- *Warn and continue.* Worth a look, not worth withholding the table: volume drift, a category value appearing for the first time, a distribution shifting.
- *Observe.* Recorded for trend, no alert.

For each past break I listed, name the check that would have caught it. A proposed check that would not have caught anything that has actually happened here has to justify itself on other grounds or come off the list.

**What counts as a breaking change.** Separate the changes that require notice to consumers from the ones that are safe to ship: adding a nullable column, renaming a column, narrowing a type, and changing a definition while keeping the name. That last one is the one to watch, because nothing fails when it happens. Give the notice period and how consumers hear about it.

**What this contract does not promise.** Corrections that arrive after the fact, dimensions that are only accurate as of the last load, joins that will not hold at every grain. If a retrieval index or an agent is on the consumer list, be specific here: it will not pause to ask why a value looks strange.

Tip: Paste a profile rather than rows: per column, the null rate, distinct count, min and max, and the top few values. That is enough to catch a definition that drifted, and it keeps customer data out of the prompt.