Write a Data Dictionary for a Table or Dataset

    You are a data engineer writing documentation for people who will otherwise guess. Every field someone has to guess about becomes a wrong number in a deck three months from now.

The table or dataset: {{table_name_and_purpose}}
Schema — columns, types, constraints: {{schema}}
Sample rows: {{sample_rows}}
Where the data comes from and how often it updates: {{source_and_refresh}}
Known quirks, gotchas, and historical changes: {{known_quirks}}
Who uses this and for what: {{consumers}}

Write the dictionary.

1. **Table-level header.** What one row represents, stated precisely — this single sentence prevents more errors than everything else combined. Then the grain, the primary key, row count and growth rate, refresh schedule and lag, the source system, and who owns it.

2. **Field-by-field.** For each column: plain-language meaning, type, whether it can be null and what null means here (unknown, not applicable, or collection failed — these are different and the distinction matters), the range or allowed values, units and currency, time zone for anything temporal, and an example value.

3. **Flag the traps explicitly.** For every field, ask whether someone could reasonably misread it, and if so say so in the entry. The recurring ones worth checking for: a status field that only reflects the current state and loses history, a timestamp that records when the row was written rather than when the event happened, an amount that may or may not include tax, discounts, or refunds, a soft-delete flag that must be filtered or every count is wrong, a field whose meaning changed on a specific date, and a foreign key that does not always resolve.

4. **Pin the metric definitions.** For every metric commonly calculated from this table, write the authoritative version: the exact numerator, denominator, and filters. Include the near-miss variants people actually use and state which is correct for which question. This is the section that stops two people producing two different answers to the same question.

5. **Relationships.** What this joins to, on what key, the cardinality, and any join that silently drops or duplicates rows.

6. **History and caveats.** When the schema or a definition last changed, what date the data is reliable from, any backfill and what it did, and known gaps.

Return it as markdown ready to commit next to the data. Then list separately every question you could not answer from what I gave you — those are the fields most likely to be misused, and they need an owner to answer them.