A data dictionary describes what each field in a record means. Start with one record category from your inventory, then record field names, definitions, formats, missing-value rules, relationships and the person who can verify them. Use descriptions and invented examples; keep the underlying records in your company systems.
- The inventory lists record categories. The dictionary explains fields inside one category.
- A blank cell, an unknown value and a zero can mean different things.
- Documentation does not establish permission to share records or an accepted licensing opportunity.
FREE WORKING TOOL · NO ACCOUNT REQUIRED
Build a data dictionary and download your CSV
Describe the fields in one record category. Add a row for each field, document what is unknown, then download a CSV your team can review.
This builder creates the file in your browser. Your entries are not submitted by this tool and disappear when you leave or reload. Use descriptions and invented examples, without private records or access details.
1 row in your working file. Save a download before leaving this page.
To share the tool, link to this page. Your downloaded file is a working document; it does not establish approval, rights, eligibility or an outcome.
Download the template and a fictional example.
Use the free CSV builder on this page to create your own working dictionary. Your entries stay in this browser tab; download a copy before leaving.
Open the blank data dictionary template in your spreadsheet, or compare it with the completed fictional example. Both files use the same 12 columns. No email or account is required.
Keep completed worksheets inside your company. The example describes an invented support-resolution history; it contains no customer records. Replace its assumptions with definitions your responsible team verifies.
Choose the inventory or dictionary for the question.
Use an inventory when the question is what the company retains and who understands it. Use a dictionary when someone needs to interpret the fields of a particular record category. A dictionary can link back to its inventory row without moving the records.
| Working aid | Question it answers | Example |
|---|---|---|
| Data inventory | Which record categories exist? | Support-resolution histories retained by the support team |
| Data dictionary | What do the fields mean? | Whether resolved_at means first resolution or final closure |
| Workflow map | How do records connect? | Issue, investigation, approved decision and outcome |
Write definitions someone else can check.
Choose one category and inspect its schema or documentation with the responsible team. Describe each field in a separate row. Record the source and version used for the definition. Use UNKNOWN when a rule has not been established.
| Columns in the worksheet | What to record |
|---|---|
| Record category; field name | A category label and the exact field identifier |
| Meaning; format and units | The business definition, type, date format, time zone or unit |
| Allowed values; missing-value rule | Permitted codes and what blank, null or an unavailable value means |
| Relationship or join | A description of the link to another record; do not paste live identifiers |
| Source and version; definition owner | Where the definition came from and who can confirm it |
| Review question; verification status; checked date | The unresolved decision, its status and the actual check date |
Keep a missing outcome distinct from a zero.
In this fictional support system, outcome_code is filled only after someone reviews the resolution. A blank means the outcome has not been recorded. It does not mean that the issue failed, succeeded or had zero commercial impact.
The support lead can check when this field is populated and whether the rule changed during the retained period. Until that check occurs, the example dictionary marks it UNVERIFIED. A field description and a reliable observation are separate pieces of evidence.
| Fictional field | Working definition | Question to verify |
|---|---|---|
| resolved_at | Final recorded closure time, expressed in UTC | Was this always final closure, or did earlier versions record first resolution? |
| outcome_code | Internal resolution category; blank is not yet recorded | Who sets the code, and did the allowed categories change? |
| investigation_link | An internal reference connecting the investigation to the issue | Does the linked material contain customer or third-party information? |
Use the dictionary to surface review questions.
A team may understand a field while still needing to review restrictions on its use. Describe where customer, employee or third-party material could appear, and assign the question to the appropriate internal reviewer. Do not put sensitive values or access links in a document intended for an initial conversation.
A dictionary supports explanation. It does not establish licensing rights, de-identification, a buyer’s interest or an offer. An initial conversation with Origin starts with company details and record categories; no dictionary upload or system connection is required.
Give changes an owner and a check date.
Update the working dictionary when a field is renamed, a code list changes, a source system moves or a definition is corrected. Retain the earlier version and explain what changed. Record an actual verification date rather than the date someone last opened the file.
If an operational record cannot be interpreted consistently across its retained history, document the boundary. That is a useful review finding. It should not be hidden by filling gaps from memory.
Common questions
Is this data dictionary template free?
Yes. The blank CSV and fictional completed example are available without an email address or account. Keep your completed copy inside your company.
Is a data inventory the same as a data dictionary?
No. An inventory lists record categories, retained history and responsible teams. A dictionary explains individual fields, their meanings, formats and missing-value rules.
Should we send company records to use the template?
No. Describe the fields using internal documentation and invented examples. Origin’s initial inquiry asks for company details, without records or system access.