Data Dictionary Template

A data dictionary turns vague phrases like “the system has the data” into a field-by-field picture of what exists, who owns it, and whether it can be trusted. It is one of the most useful things a deployed team can bring to a technical feasibility conversation.

You do not need engineering in the room to start this. Program staff, analysts, vendors, and system owners can usually identify the fields, reports, exports, and definitions that matter.

Why It Helps

Engineering uses a data dictionary to validate source-of-truth claims, migration risk, reporting feasibility, privacy constraints, and whether success metrics can actually be measured.

The key is not perfection. The key is showing where the team is relying on real data versus assumptions.

What Good Enough Looks Like

Question	Useful answer
What data does the project need?	Field names, plain-English definitions, and where each field appears today.
Where does it come from?	Source system, report, form, spreadsheet, vendor export, or manual process.
Who owns it?	A named team or person who can explain the data and approve use.
Can we trust it?	Known quality issues, missing values, duplicates, timing lag, or manual edits.
Is it sensitive?	PII, PHI, CJIS, IRS, financial, legal, or other constraints.

What to notice: the most helpful column is often the source and owner, not the field name.

Copy This Template

| Field / data element | Plain-English definition | Source today | Owner / steward | Format / example | Update frequency | Quality notes | Sensitivity | Needed for |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Case ID | Unique identifier for one service request | Legacy case management system | Program operations lead | `CASE-2026-004219` | Created at intake | Sometimes duplicated after manual reopen | Internal identifier | Migration, reporting, support |
| Applicant email | Email address used for notices | Online intake form | Contact center manager | `name@example.gov` | User-entered at submission | About 8% blank in older records | PII | Notifications, account matching |
| Eligibility status | Current benefit decision state | Eligibility rules engine | Eligibility policy owner | `pending`, `approved`, `denied` | Nightly batch | Status can lag source documents by 24 hours | PII / program data | Workflow, reporting, user status |
| Submission date | Date the request entered the process | Online intake form and paper intake log | Intake supervisor | `2026-07-02` | Created at intake | Paper submissions are keyed later | PII-adjacent | Timeliness metric |

Bring This to Engineering

Bring the filled table plus three notes:

Which fields are required for day-one delivery
Which fields are needed only for reporting or future phases
Which fields are unknown, disputed, sensitive, or controlled by a vendor

This lets engineering separate “we can build with this” from “we need more discovery before this becomes an implementation plan.”