A data dictionary presentation should resolve a disagreement about meaning, not project a spreadsheet of every column onto a screen. Start with a business question people already interpret differently. Trace it to a few records, agree on the definition, then show who maintains it and what changes for reports that use it.
Consider a fictional appointment business. Its dashboard says “three appointments completed,” but the operations manager says only one customer received the service. Neither person has invented a number: the dashboard counts closed appointments, including cancellations and no-shows. The label makes three different outcomes look like the same thing. All records, roles, and changes in the example below are invented to demonstrate a dictionary review—not customer data or a Presenti implementation.
After your team settles the definitions, Presenti's text-to-presentation workflow can turn the approved explanation into an editable slide draft. Paste the selected field definitions and example rows, not a confidential database export. The dictionary remains your source of truth; the presentation is the small, audience-specific view used to make a decision.
Begin with the term that caused the disagreement
In this example, the audience is the operations manager, reporting analyst, and engineer responsible for the booking export. They need to approve what “completed appointment” means before the next reporting release. They do not need a tour of every field in the booking system.
A useful dictionary connects the language people use to the data they can inspect. The USGS guide to data dictionaries describes names, definitions, data types, nullability, reference values, and business rules as useful dictionary contents. For this meeting, those details should answer a concrete question: does the row represent a delivered service, or only an appointment that will no longer take place?
Set the scope on the opening slide: “One row per appointment in the daily booking snapshot, for one location.” For this example, the snapshot was taken at 08:00 UTC on 9 October 2026; it records the state at that cutoff, not the latest state today. Show that time and the dictionary version on the slide. An appointment is not a customer; the same customer can have several appointments. A snapshot is also not a history of every status change. These two sentences prevent plausible but incorrect uses of otherwise valid data.
| Appointment ID | Status in the snapshot | Completion time, UTC | Business interpretation |
|---|---|---|---|
| 000271 | completed | 2026-10-08T09:30:00Z | Service was recorded as delivered |
| 000272 | cancelled | Missing | Booking was cancelled; not a delivered service |
| 000273 | no_show | Missing | Customer did not attend; not a delivered service |
| 000274 | booked | Missing | No final outcome has been recorded in this snapshot |
With the old dashboard rule, completed, cancelled, and no_show are all closed statuses, so the displayed total is three. Under the proposed definition of completed, only 000271 qualifies. The fourth row must not be silently treated as another no-show merely because the service date has passed. Its outcome is unresolved in this extract.
Separate a field's format from its business meaning
A type answers what a value can look like. A definition answers what it stands for. A date-shaped value does not tell the reader whether it is the booking date, service date, or export date. Likewise, a number-shaped ID is not necessarily a quantity that should be added or rounded.
| Field | Type and allowed values | Definition | Misuse to prevent |
|---|---|---|---|
appointment_id | Required string; unique within the snapshot | Stable identifier for one appointment, such as 000271 | Do not convert to a number and drop leading zeros; it is not a customer ID |
service_date | Required date, YYYY-MM-DD | Scheduled service date in the location's Europe/London time zone | Do not substitute the booking creation date or a date obtained by truncating a UTC timestamp |
status | Required string: booked, completed, cancelled, or no_show | Recorded appointment state as of the snapshot time | Do not use closed as a synonym for completed; closed is a separate derived grouping |
completed_at | UTC timestamp, or missing | Recorded service-completion time | Missing does not mean midnight, zero duration, or confirmed non-attendance |
The W3C Metadata Vocabulary for Tabular Data provides ways to describe column types, required values, keys, and other constraints in machine-readable metadata. Such validation can help detect malformed or missing values. It cannot, by itself, decide whether your business should count a cancelled appointment as completed. Keep the technical constraint and the business agreement together, but do not confuse them.
For a business audience, show one row and one possible mistake beside the field, rather than introducing every database term first. The leading zeros in 000271 make the string type understandable immediately. The difference between service date and completion timestamp makes the time-zone rule worth discussing, rather than looking like an obscure engineering footnote.
Make missing and conflicting values explicit
In the four-row extract, the same missing completion timestamp appears with three different statuses. For a cancellation it is expected. For a no-show it is also expected, for a different reason. For the unresolved booking it says only that completion has not been recorded. Replacing all three with “not completed” may be convenient for one calculation, but it destroys distinctions the team needs to manage the work.
Now add a fifth hypothetical record during the meeting. This record is an exception: its status is completed, but it has no completion timestamp. The operations manager may know the service happened; the analyst cannot infer the time from this row. The proposed rule is to classify it as a definition exception, investigate it, and show the excluded exception count alongside the completed total. Do not rewrite the underlying status just to make the report reconcile.
This is an important choice, not a universal rule. A different business might accept the status alone as evidence of completion. If so, document that policy and define when a timestamp is required. What is unsafe is letting two report authors choose different policies without a visible distinction.
| Card entry | Example to take to the approval meeting |
|---|---|
| Business term | Completed appointment |
| Meaning | An appointment recorded as delivered, with a recorded completion time |
| Included records | Status is completed and completed_at is present |
| Not included | Cancelled, no_show, and booked records; completed records missing the required timestamp are reported separately as exceptions |
| Unit and scope | Distinct appointment_id, not distinct customers; one location and one dated snapshot |
| Time convention | Reporting period uses service_date in Europe/London; completed_at is retained in UTC |
| Source mapping | Daily booking snapshot: appointment_id, service_date, status, completed_at |
| Authority and version | Operations manager approves the meaning; reporting analyst maintains the card; proposed dictionary v2.0 |
| Known limitation | The current snapshot alone cannot reconstruct what the status was at an earlier reporting cutoff |
Reuse the left-hand entries for another disputed term, but replace the whole right-hand column. “Active customer,” “resolved ticket,” and “recognized revenue” need different inclusion rules and authorities; swapping their names into this example would not produce valid definitions.
Assign ownership of meaning, mapping, and changes
A row marked “owner: data team” often hides three unanswered questions. Who can approve the meaning? Who can repair the source mapping? Who will tell report users that the meaning changed? In the fictional appointment team, assign those duties separately.
- Operations manager: approves whether a delivered service requires the completion timestamp and resolves operational exceptions.
- Booking-system engineer: confirms how statuses and timestamps reach the export, including delays and correction behavior.
- Reporting analyst: maintains the dictionary entry, identifies affected reports, and records the approved version.
- Dashboard owner: changes the label and formula, then provides examples that the business owner can accept.
These are responsibilities for the example, not a requirement to create four jobs. A small team can combine roles, but the decision record still needs a named accountable person and a usable contact route. An engineer should not have to invent a commercial definition, and a business owner should not approve a mapping nobody has verified.
Keep unresolved scope out of the approval. The team has not yet agreed on whether a no-show fee belongs in revenue for this report. The presentation should not imply that a clean appointment definition settles revenue recognition, refunds, or tax treatment. Those are separate terms with different source records and decision owners.
Show what the definition change does to history
The proposed v2.0 release separates two terms: closed appointment and completed appointment. The old dashboard label “completed” pointed to the broader closed rule. Changing only the label or only the formula would leave users comparing unlike numbers.
| Report version | Displayed term | Rule | Count |
|---|---|---|---|
| v1.0, old dashboard | Completed | completed, cancelled, or no_show | 3 |
| v2.0, clarified grouping | Closed | completed, cancelled, or no_show | 3 |
| v2.0, new operational measure | Completed | completed with a recorded completion time | 1 |
The change from three to one is not evidence that service performance deteriorated. The records are identical; the definition changed. Show this bridge before presenting any time-series chart that crosses the release boundary.
For the fictional rollout, propose v2.0 from the reporting week beginning 2 November 2026. Preserve the v1.0 dictionary and exported reports. Where retained snapshots contain the necessary fields, calculate a separate restated history and label it with v2.0. Where they do not, keep the series separate and identify the break. A current-state export cannot reliably recreate every historical reporting cutoff.
The change record should identify the old rule, new rule, effective reporting period, approving owner, affected reports, and treatment of history. Also state whether the source export changes or only the report interpretation changes. Here the export stays the same; the business definition, dashboard label, and calculation change together. This distinction lets engineering estimate work without mistaking a semantic decision for a schema migration.
Present the definition decision in five slides
A business review needs the dictionary behind it, not the entire dictionary on screen. For this example, use these five slides:
- “Three closed appointments are not three delivered services.” Put the disputed dashboard label beside the operations question.
- “The same four rows explain both totals.” Show the small record table; distinguish completed, cancelled, no_show, and unresolved booked.
- “Approve this meaning of completed.” Show the field-and-term card, concentrating on inclusion, exceptions, and time convention.
- “v2.0 changes the comparison, not the underlying events.” Show the three-to-one bridge, the effective period, and the limits of historical restatement.
- “Approve the definition and assign the reporting change.” Name the decision owner, mapping owner, and report owner; leave the revenue question outside this approval.
Attach the full dictionary and change record to the presentation so the team can retrieve the approved details after the meeting. If you create a slide draft from these notes, keep field identifiers exactly as written, preserve the word “fictional,” and do not let a shorter heading erase the distinction between closed and completed. No automatic database scan or catalog synchronization is implied by turning the notes into slides.
The proposed outcome is specific: approve completed as a delivered appointment with a recorded completion time; retain closed as a separate grouping; publish the v2.0 report definition with a visible history break or a separately labeled restatement. The team now has an agreement someone can implement, not just a glossary everyone can interpret differently.
