A small data dictionary can save a surprising amount of confusion

A spreadsheet can look self-explanatory right up to the moment two people use it to answer the same question and get different results.

Consider a column named Customer. Does it mean a legal entity, a billing account, an individual contact, or a company that made a purchase during a particular period? A column called Revenue raises similar questions. Is it booked, invoiced, recognized, gross, net of credits, or cash collected?

Neither person needs to be careless for the answers to diverge. The ambiguity was already in the dataset. It just had not been written down.

That is the practical purpose of a small data dictionary. It is not technical paperwork for its own sake. It is a short operating agreement that lets the next person interpret a dataset without having to reconstruct the creator’s assumptions.

Headers are labels, not definitions

A column header can be useful while still leaving out the information that matters most. A CSV or spreadsheet column named status does not say which statuses are valid, whether values can change later, or whether a blank means “not applicable,” “unknown,” or “not yet updated.”

It also does not say whether 2026-09-30 is an order date, a shipment date, a reporting cutoff, or the date someone exported the file.

Standards bodies describe this kind of supporting information as metadata: information about a dataset’s structure, meaning, quality, provenance, and use. That language can sound formal, but the underlying need is ordinary. People need enough context to avoid guessing.

A small dictionary makes the hidden choices visible. It can explain what a field means, what form it takes, which values are expected, and what exceptions mean. It can also state what one row represents, which is often the most consequential fact in a dataset.

For example, “one row per subscription” means something quite different from “one row per customer-month.” Both may include a customer identifier and revenue amount. Summing a column without understanding that difference can produce a confident but incorrect result.

Start with the questions people keep asking

A useful dictionary does not need to document every field at enterprise scale. Start with the fields that affect conclusions or repeatedly prompt clarification.

Dates, amounts, units, status labels, identifiers, categories, and calculated measures are often good candidates. So are fields with deceptively familiar names such as customer, active, closed, qualified, revenue, and region.

A practical rule is this: document a field if a reasonable new user could ask any of these questions:

• What exactly does this mean?
• What does a blank value mean?
• Can these values be added, compared, or grouped?
• What unit or time basis does this use?
• Will this value change after the file is delivered?

The answer does not need to be long. It needs to settle a real ambiguity.

For instance, a field entry for revenue_usd might say:

> Definition: Net invoiced revenue, excluding sales tax and credits issued after month-end. > Unit: U.S. dollars. > Grain: Account-month. > Refresh: Updated after monthly close.

That short entry prevents a reader from quietly treating the number as booked sales, cash received, or a lifetime customer total.

A compact format is usually enough

For many shared spreadsheets, dashboard extracts, and CSV files, a one-page reference or a “Read me” tab is enough to make the data far easier to reuse.

At the dataset level, include a few basic facts:

• Purpose: What question or process is this dataset intended to support?
• Row grain: What does one row represent?
• Source: Which system, report, or process produced it?
• Coverage: What period does it cover, or what is the as-of date?
• Refresh cadence: How often is it updated?
• Owner: Who can clarify meaning or approve changes?
• Known limitations: What should a user avoid assuming?

Then add a compact table for consequential fields. Useful columns include field name, business definition, type or unit, allowed values or rule, blank/null meaning, and an example.

Here is a field definition with enough detail to prevent several common misunderstandings:

The key detail is not the field name. It is the trailing 12-month window and the explanation of the blank state. Without them, “active” can easily become a matter of personal interpretation.

Treat it as a living agreement

A dictionary does not prove that the underlying data is accurate. It cannot correct a bad source value or resolve every edge case. What it can do is clarify the intended meaning, known constraints, and appropriate uses before someone builds an analysis on an unstated assumption.

That requires modest upkeep. Name a person or team responsible for questions, and include a visible “last reviewed” date. If a definition changes, record the change plainly. A status field that was once based on manual review may later come from an automated rule; users should not have to discover that through inconsistent results.

The document also belongs where people will find it. A separate file buried in a project folder is less useful than a tab in the shared workbook, a companion page beside a download, or a plainly linked document.

Before sending data outside the producing team, pause for one question: could a capable colleague tell what the rows and consequential columns mean without asking the creator?

If not, the definition already exists somewhere. It is probably sitting in someone’s head, scattered across old messages, or embedded in a report nobody thought to attach. A small data dictionary puts it where the next user can use it.