QUICK ANSWER
What should a data dictionary template include?
A data dictionary template should identify each dataset and field, then record the field definition, business term, data type, format, nullability, classification reference, owner, steward, permitted values, lineage, and measurable quality checks. Use stable versioned IDs and reciprocal references so missing or stale metadata fails review instead of becoming invisible.
A useful data dictionary explains what each field means, where it belongs, how it is represented, whether it may be absent, which classification label applies, who owns and stewards it, where it came from, which values are permitted, and how quality is checked. It preserves those decisions as versioned records instead of scattered comments.
This original provider-neutral pack includes editable Markdown, a completed fictional JSON dictionary, a closed JSON Schema Draft 2020-12 contract, and a dependency-free validator with mutation tests. It checks cross-references and reciprocal quality coverage while keeping database design, migration execution, handling policy, retention, legal review, and production approval outside the template.
Create a dictionary around meaning, not storage choices
Start with stable dataset and field identities, connect each field to accountable meaning and evidence, and preserve changes as reviewed versions. Keep implementation and policy decisions with their proper owners.
Version the dictionary and register each dataset
Give the dictionary a stable ID, version, status, owner role, steward role, review date, scope, and change policy. Register each dataset separately from its distribution or storage location, with a bounded description and current source reference. A catalog record helps people discover and interpret data but does not contain or validate the underlying data itself.
Sources: [data-dictionary-pack], [dcat-3], [data-gov-inventory]
Define one field without hiding null or format semantics
Record one unambiguous definition, shared business term, logical type, serialization format, and explicit nullability decision. Distinguish null, blank, zero, false, unknown, not applicable, and redacted states where the domain needs them. Keep physical columns, indexes, storage engines, and framework choices in a separate design record.
Sources: [data-dictionary-pack], [json-schema-2020]
Reference classification, ownership, and stewardship
Link each field to one label from the organization-owned classification scheme and name separate accountable owner and maintenance steward roles. The dictionary records the current reference and handling note; qualified policy, security, privacy, legal, and domain owners decide which labels and obligations actually apply.
Sources: [data-dictionary-pack], [uk-data-quality]
Connect permitted values and field-level lineage
Use one versioned value set when a field has controlled values, then link source and target fields with an explicit copy, derived, aggregated, or reference relationship. Record the semantic transformation and owner. The relationship documents intended provenance but does not prove that a pipeline ran or that records reconcile.
Sources: [data-dictionary-pack], [prov-o]
Make quality expectations reciprocal and reviewable
Give every field at least one named completeness, uniqueness, validity, consistency, or timeliness rule with a measurable expectation, repeatable verification method, and owner. Link fields to rules and rules back to fields. Review the metadata whenever the dataset changes so a stale dictionary cannot imply current quality.
Sources: [data-dictionary-pack], [uk-data-quality], [uk-dcat-guidance]
The data dictionary owner boundary
Use this template to agree what data fields mean and how their metadata is reviewed. It is a semantic catalog and evidence map, not a database implementation or governance approval system.
Included
- Dictionary identity, version, status, scope, change policy, review date, accountable owner, and maintenance steward
- Dataset identity, bounded description, owner, steward, source system, and reserved fictional source reference
- Field identity, definition, business term, logical type, format, nullability, classification reference, owner, and steward
- Versioned permitted values, field-level lineage relationships, measurable quality rules, and reciprocal cross-references
- Editable Markdown, fictional JSON, closed Draft 2020-12 schema, dependency-free validator, mutation tests, and reproducible ZIP
Not included
- Database solution design, physical tables or columns, keys, indexes, partitions, query plans, storage engines, APIs, or application code
- Schema migration design or execution, backfill, cutover, rollback, reconciliation, deployment, monitoring, or target-environment smoke
- Classification scheme selection, access or handling policy, retention, deletion, legal basis, privacy, security, compliance, or contractual decisions
- Inspection of real data, live lineage execution, measured quality results, production approval, certification, or proof that a source system follows the dictionary
DOWNLOADABLE RESOURCE
Download the data dictionary template pack
Use the Markdown file for review, the fictional JSON for a controlled metadata graph, the closed schema for structural tooling, and the validator for references, permitted values, lineage, reciprocal quality coverage, reserved sources, and unsafe fields.
Data dictionary template pack
An original provider-neutral dictionary connecting dataset and field meaning to types, formats, nullability, classification references, owners, stewards, value sets, lineage, and quality rules.
Format: Editable Markdown, fictional JSON, closed JSON Schema, dependency-free validator, tests, and deterministic build script in one ZIP
Locally reproduced August 1, 2026. SHA-256: c2106f34153523d75b816c342841e5148939e4c5d116beae4aca0bb5649e881a
Included
- Editable human-review template plus a completed fictional two-dataset, seven-field JSON dictionary
- Closed JSON Schema Draft 2020-12 contract with explicit record shapes and additional-property denial
- Dependency-free semantic validator and 30 positive and mutation tests for IDs, references, formats, value sets, lineage, quality reciprocity, reserved URLs, sensitive fields, credentials, malformed arrays, and archive safety
- Fixed-timestamp exact-eight-file ZIP builder with source-byte parity and cross-time-zone reproduction checks
Verification boundary
The exact eight-file archive allowlist, source-byte parity, UTC and Pacific/Auckland rebuild identity, clean extraction, closed object shapes, cross-family unique IDs, dataset and classification references, type-format pairs, value-set type and value integrity, lineage references and copy compatibility, reciprocal quality links, reserved example.test sources, unsafe fields, credential patterns, malformed arrays, and em-dash prohibition were checked locally.
Four data dictionary shapes for different review jobs
Reuse the metadata structure, not the fictional labels or rules. Every organization needs current source owners, definitions, classification policy, quality evidence, and review cadence for its own data.
Operational record dictionary
Use when: A form, portal, CRM, or internal tool creates records whose fields are interpreted by several teams.
Define each request, customer, order, case, or status field once, distinguish null and blank states, link controlled values, and name the owner and steward who resolve semantic conflicts.
Structure
- Dataset and field IDs with definition, business term, type, format, nullability, and classification reference
- Controlled lifecycle value sets and reciprocal quality rules for identity, required values, validity, and cross-record consistency
Watch for: A dictionary does not implement authorization, validate production records, choose retention, or prove that the application preserves the documented meaning.
Sources: [data-dictionary-pack], [uk-data-quality]
Analytics handoff dictionary
Use when: Source fields feed a report or derived metric and reviewers need to understand the semantic transformation.
Link the source and target field IDs, record whether the relationship is copy, derived, aggregated, or reference, and state the transformation meaning, time basis, quality expectation, and accountable owner.
Structure
- Field-level provenance from source entity through activity to target field
- Quality rule for source coverage, transformation validity, timeliness, and reconciliation evidence
Watch for: Recorded lineage is not proof that a pipeline executed, that late data was handled, or that a displayed metric reconciles to authoritative records.
Sources: [data-dictionary-pack], [prov-o], [uk-data-quality]
Public dataset companion dictionary
Use when: A published dataset needs a stable explanation of its fields alongside catalog metadata and distributions.
Keep dataset-level title, publisher, contact, description, update context, and distribution metadata in the catalog, then link a field-level dictionary that explains structure, values, null states, caveats, and quality checks.
Structure
- DCAT-style dataset and catalog record plus an explicit dictionary URL and type
- Field definitions, permitted values, known quality caveats, update date, and contact or steward role
Watch for: Publishing a dictionary does not make sensitive data public, grant reuse rights, satisfy policy, or guarantee that the dataset is complete and current.
Sources: [dcat-3], [data-gov-inventory], [uk-dcat-guidance]
Controlled value and classification review
Use when: Several systems use the same status, category, sensitivity, or outcome field and drift creates conflicting reports.
Create one versioned value set with exact stored values and definitions, reference the current organization-owned classification scheme, and record which owner approves semantic changes and which steward maintains the metadata.
Structure
- Stable value-set and value IDs with exact stored value, label, definition, type, and owner
- Classification reference and review note that point to policy without copying or inventing the policy itself
Watch for: A generic template cannot determine which classification, handling, retention, deletion, legal, security, or compliance obligations apply.
Sources: [data-dictionary-pack], [json-schema-2020], [uk-data-quality]
Decide whether the dictionary is ready for accountable review
A dictionary is reviewable when field meaning, references, owners, and evidence are explicit. Structural completeness starts human review; it does not approve implementation or production use.
A field has no bounded definition, format, nullability decision, classification reference, owner, or steward.
Choose: Keep the dictionary in draft and resolve the missing semantic owner before building downstream reports, migrations, or integrations around it.
Tradeoff: Delivery waits, but teams do not encode conflicting assumptions into several systems and call them the same field.
A controlled field repeats an inline list of values in several records or documents.
Choose: Create one versioned value set with stable value IDs, exact stored values, readable labels, definitions, data type, and accountable owner.
Tradeoff: The value set needs change control, but consumers can detect and review a semantic change instead of silently accepting drift.
A derived field has no current source-field or transformation relationship.
Choose: Add a field-level lineage record and a reconciliation rule, then keep the output untrusted until target-environment evidence confirms the actual pipeline.
Tradeoff: The dictionary carries more links, but users can distinguish intended provenance from measured execution.
A classification or retention decision is disputed or absent.
Choose: Stop at the metadata reference and escalate to the accountable policy, security, privacy, legal, records, and domain owners rather than inventing a generic rule.
Tradeoff: The template cannot close the decision, but it preserves the blocker and prevents a false approval signal.
The field meaning, value set, lineage, or quality expectation changes.
Choose: Create a new dictionary version, identify affected consumers and rules, preserve the prior meaning, and obtain explicit semantic review before migration or release work begins.
Tradeoff: Versioning creates review work, but historical records and downstream consumers are not reinterpreted silently.
START WITH FIELD MEANING
Download the data dictionary pack and replace every fictional record
Adapt the datasets, fields, definitions, owners, stewards, classification references, value sets, lineage, and quality rules to sources your accountable reviewers can inspect.
Download the data dictionary packThe ZIP is locally reproduced. Public availability, real data, policy, implementation, migration, and production use remain unverified until their separate reviews and environment checks.
Plan the separate data migrationUse the migration owner when the next job is source-to-target mapping, backfill, cutover, reconciliation, rollback, and target-environment evidence.
Limits to review before adopting the pack
A strict dictionary can expose missing metadata and broken references. It cannot decide policy, inspect real records, or prove that software and operations follow the documented meaning.
- The template is original editorial material and does not reproduce or claim conformance with a copyrighted data-management standard or another publisher's template.
- The fixed fictional classification labels demonstrate reference integrity only. Qualified owners must select and maintain the real classification, access, handling, privacy, legal, security, compliance, retention, and deletion rules.
- The dependency-free validator checks the included structure, IDs, types, formats, references, value sets, lineage, reciprocal quality links, and selected safety rules. It does not inspect a database or validate real data.
- Recorded lineage and quality expectations describe intended evidence. They do not prove pipeline execution, freshness, completeness, accuracy, reconciliation, monitoring, or fitness for purpose.
- An active dictionary version is a metadata lifecycle state, not database design approval, migration authorization, deployment approval, production certification, or business outcome evidence.
- This ordinary informational article does not grant AI signup credits. Any linked Playcode product page follows its own current eligibility policy.
Primary guidance and verification sources
The same-release pack is the direct source for the fictional records and tests. Current W3C, JSON Schema, Data.gov, and GOV.UK sources support catalog, lineage, structural, ownership, and freshness boundaries without endorsing this template.
[data-dictionary-pack] Playcode:Data dictionary template pack
Checked August 1, 2026. Supports: The exact same-release archive containing the original Markdown template, completed fictional JSON, closed schema, dataset and field records, classification references, value set, lineage, quality rules, validator, mutation tests, and deterministic builder.
[dcat-3] World Wide Web Consortium:Data Catalog Vocabulary (DCAT) Version 3
Checked August 1, 2026. Supports: The W3C Recommendation model for interoperable descriptions of catalogs, catalog records, datasets, distributions, data services, versions, and related metadata. It does not prescribe this field-level template.
[prov-o] World Wide Web Consortium:PROV-O: The PROV Ontology
Checked August 1, 2026. Supports: The W3C provenance model connecting entities, activities, and agents. The pack uses a narrower provider-neutral field-lineage relation and does not claim full PROV-O conformance.
[json-schema-2020] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The declared dialect and structural validation vocabulary used by the included closed JSON Schema. The dependency-free validator adds pack-specific reference, reciprocity, and safety rules.
[data-gov-inventory] United States General Services Administration:Inventory.data.gov Guide
Checked August 1, 2026. Supports: The current public guide distinguishes dataset metadata from stored data and provides separate data-dictionary URL and type fields. It does not define this fictional field-level contract.
[uk-dcat-guidance] United Kingdom Government Digital Service:Using metadata to describe data assets in a data catalogue
Checked August 1, 2026. Supports: Using DCAT 3 for consistent dataset and data-service metadata in catalogs, including discoverability and catalog-owner maintenance. It does not decide field semantics or policy.
[uk-data-quality] United Kingdom Government Digital Service:The Government Data Quality Framework: guidance
Checked August 1, 2026. Supports: Keeping metadata current, exposing known quality limitations, assigning catalog ownership, measuring fitness for purpose, and reviewing automated quality measures. It does not certify this pack or any dataset.
Data dictionary template questions
What is a data dictionary?
A data dictionary is a versioned catalog of data meaning. It identifies datasets and fields, defines each field, records its business term, type, format, nullability, classification reference, owner, steward, permitted values, lineage, and quality expectations, and preserves the evidence boundary for review.
What is the difference between a data dictionary and a database schema?
A data dictionary owns semantic meaning and review metadata. A database schema owns physical or logical implementation such as tables, columns, keys, constraints, indexes, and storage-specific types. They should link, but a dictionary should not silently become the database design or migration plan.
Should a data dictionary include nullable fields and permitted values?
Yes. Record whether null is permitted and what null, blank, zero, false, unknown, not applicable, or redacted mean for the field. When values are controlled, link one versioned value set with exact stored values, labels, definitions, type, and owner rather than copying lists into several documents.
How should a data dictionary record lineage?
Link stable source and target field IDs, classify the relationship as copy, derived, aggregated, or reference, state the semantic transformation and owner, and attach a reconciliation or quality rule. This records intended provenance but does not prove that a pipeline executed or produced current results.
Who owns and maintains a data dictionary?
Use an accountable data or domain owner for business meaning and decisions, plus a steward for day-to-day metadata quality and updates. Policy, security, privacy, legal, records, and technical owners remain separately accountable for the decisions in their domains.
Can the included validator prove that data quality is good?
No. It checks only the fictional dictionary structure, IDs, references, type-format pairs, value-set integrity, lineage links, reciprocal quality coverage, reserved sources, and selected safety rules. Real quality needs current source data, repeatable measurements, reconciliation, limitations, monitoring, and accountable review.
Does this data dictionary template grant Playcode AI credits?
No. This is an ordinary informational resource and does not grant AI signup credits. Downloading or adapting it also does not create a Playcode project, inspect a database, approve a migration, decide policy, or authorize production use.
BUILD FROM REVIEWED DATA MEANING
Turn the accepted record boundary into a working internal tool
Give Playcode the reviewed records, roles, field meanings, states, permitted values, quality checks, and acceptance boundary after accountable owners resolve real policy, security, privacy, retention, and migration decisions.
Explore internal tool buildingThis informational article does not grant AI signup credits. Playcode does not inspect, classify, approve, migrate, or guarantee the quality, safety, compliance, delivery, or business outcome of your data.