Data dictionary: agreeing what the fields actually mean

A data dictionary is the document that says what each field in your systems means. Not its type and length — that is in the schema — but what it represents in the business, who decides its definition, and what values are allowed. It exists because two departments will otherwise report different customer counts for the same month and spend a fortnight discovering that one of them counts trial accounts.

What a data dictionary records per field

• The business name, and the technical name it maps to, because these diverge everywhere.
• A definition written so someone outside the team could apply it — "active customer" needs a rule, not an adjective.
• The owner: a named role that decides the definition when it is disputed.
• Allowed values or format, including whether blank is legitimate and what it means when it is.
• Source of truth, where the same concept exists in several systems — one of them wins, and saying which is most of the value here.
• Sensitivity: whether the field holds personal or special category data, which connects it to your information asset register rather than restating it.

Building one people actually use

1. Start with the fields that appear in reporting or in a regulator’s questions, not with the whole schema. Twenty fields defined properly beat six hundred stubs.
2. Write definitions where the disagreement is, and expect the exercise to surface disagreements that have been quietly costing time for years.
3. Get the owner to approve the wording, so the dictionary carries authority rather than opinion.
4. Put it where the people who query the data will see it, not in a governance folder they have no reason to open.
5. Review when a system changes, and treat an undefined new field as an incomplete change rather than a documentation debt.

The dictionary is worth building only if it is allowed to settle arguments. If a report can still be produced on a definition nobody wrote down, the document becomes an archive of what someone once believed. The value comes from one sentence of policy: reported numbers use dictionary definitions, and changing a definition is a decision with an owner and a date.

Where dictionaries fail

• Generated automatically from the schema, so it lists every field and defines none of them.
• Written once during a migration and never touched, describing a system that has since changed twice.
• Definitions that describe the calculation rather than the meaning, which makes them impossible to check against the business.
• No owner, so a dispute has no resolution route and the dictionary is simply ignored.
• Kept separately from the data quality rules that enforce it, so the definition and the validation drift apart.

Where the dictionary lives

Ettex Sheets is a good fit at the scale most companies actually need: a row per field with definition, owner, allowed values and source of truth, filterable by system or by owner. Keeping it as a table rather than a document means someone can check a single field in seconds, which is the only usage pattern that matters. It sits alongside the information asset register and the wider data governance work rather than duplicating them. Ettex is not a data catalogue and does not connect to your databases — there is no automatic profiling or lineage, and above a few hundred managed fields a dedicated catalogue tool earns its cost.