Recommended resources
The freely available resources this lesson will direct you to.
Welcome back. In the previous lesson, you segmented customer ingestion needs by source system, volume, freshness need, and integration capability. One distinction is especially useful now: a customer’s desired deadline and the source’s actual publication schedule are not the same thing.
This lesson starts with a downstream decision—such as approving a draft financial report—and works backward to requirements for freshness, completeness, accuracy, and traceability. By the end, you should be able to express each requirement so that a customer and a product team can tell whether the data is fit for that decision, rather than merely whether a file arrived.
Start with the decision, not the feed
Imagine a finance reviewer who must approve a draft report on the business day after a monthly close. The product uses an imported trial balance to prepare that report. “Ingest the trial balance daily” sounds like a requirement, but it leaves the consequential questions unanswered: Which version of the trial balance? Ready by when? What if one account is missing? How can the reviewer check a surprising number?
A more useful starting statement is:
Use case: A finance reviewer needs a draft report based on the customer’s approved, final trial balance for a specified accounting period, ready for review by 09:00 on the next business day after close.
This identifies a user, a decision, a dataset, and a deadline. It also raises a question worth verifying with the customer: does an approved, final export actually exist early enough to support that deadline? Your segmentation notes should tell you who can answer, but not assume the answer.
Read the following discussion of working backward from a use case. The example is outside fintech; focus on the method, not its retail details.
Designing data products - Martin Fowler
Martin Fowler’s “Designing data products” explains why starting with a consumer’s goal helps constrain what data must be provided.
In “Working backwards from a use case,” read from the use-case walkthrough. It includes “How to do it?”, “The setup,” and “The process.” Follow how the authors move from a user’s desired output to the information it depends on, and then to systems of record; stop at the paragraph about identifying those systems.
For the report example, working backward reveals that the needed input is not simply “accounting data.” It is the approved trial balance for the right entity and period, with enough account-level detail to populate and review the report. The reviewer’s decision defines what “usable” means. A successfully uploaded but unvalidated file may not yet qualify.
The quality requirements should therefore describe the boundary between source data and usable product data. Ask both what the customer promises to supply and what the product must demonstrate after processing it. If the customer cannot confirm a final export time or provide a way to identify the final version, record that as an open dependency rather than quietly weakening the requirement.
Give each quality dimension a measurable meaning
A quality adjective becomes useful when it specifies a population, a comparison or clock, and a pass condition. The following video introduces several data-quality dimensions. Its term fidelity is close to part of what we will call accuracy; its discussion of remediation concerns recovery from problems, not the separate requirement for traceability.
Guaranteeing Data Quality SLAs with Deequ & Databand
Watch the data-quality pillars segment of “Guaranteeing Data Quality SLAs with Deequ & Databand” from Databricks. It provides a useful vocabulary for asking what a downstream consumer can rely on.
Watch the four pillars. Notice how the speakers distinguish punctual arrival, presence of expected data, and whether values are credible. When they reach remediation, consider why being able to diagnose a problem would require evidence about a record’s origin and processing history.
Here is how to sharpen those ideas for the trial-balance use case:
Freshness asks whether the usable data is ready in time. Define the start event and the endpoint. “Within 15 hours of receipt” may be measurable but still miss the reviewer’s 09:00 deadline; “daily” says even less. Specify the business calendar and time zone, and distinguish the time the source approves or publishes an export from the time your product receives and makes it usable. If the export arrives late, the product cannot truthfully claim it met an end-to-end deadline that began at close.
Completeness asks whether the expected population is present. First define it: perhaps all account rows for one entity and accounting period in the approved final export, excluding documented headers and subtotals. Then define the evidence for the expected count. Comparing processed rows with received rows detects drops inside your pipeline; it cannot reveal account rows that were absent from the customer’s export. A source manifest, expected row count, or independently agreed totals may support a stronger claim. Null checks on required fields matter too, but “no nulls” alone does not prove that no records are missing.
Accuracy asks whether the product’s values faithfully represent the agreed source and obey relevant financial rules. Check, for example, that account identifiers, debit and credit amounts, signs, currency, entity, and period survive processing as intended; that required account references are valid; and that appropriate totals reconcile. These are stronger than checking that a number is parseable. They still do not prove that the customer’s source ledger reflects economic reality. Separate “matches the approved source” from “the source itself is correct.”
Traceability asks whether someone can explain a displayed figure. A reviewer should be able to identify the source export and the contributing account row or rows, along with the relevant processing and validation result. Traceability is neither a synonym for quality nor a substitute for it: a wrong amount can be perfectly traceable. Its value is that discrepancies can be investigated and the basis of a decision can be reconstructed.
The diagram below shows how a data-product contract can hold source and schema information alongside owners and quality objectives. Its named access system and source are illustrative, not prescriptions for this report.
Write requirements that can be checked
Here is a draft for the reporting use case. The times and thresholds illustrate the required precision; they need confirmation from the reviewer, data owner, and source-system implementer before becoming commitments. Assume the customer can make an approved final export available by 18:00 on close day, using an agreed business calendar and time zone.
| Dimension | Draft requirement | Evidence needed to check it |
|---|---|---|
| Freshness | For each approved final export made available by 18:00 on close day, its validated trial balance is usable in the draft report by 09:00 on the next business day. | Export availability time, receipt time, validation result, and time the report became usable, all interpreted against the agreed calendar. |
| Completeness | Every eligible account row in that approved export is accounted for exactly once as either included in the draft report’s underlying data or identified as an unresolved exception. The report is not presented as ready for approval while a required row is unresolved. | Agreed definition of an eligible row, source row count or manifest, accepted-row count, and exception list. |
| Accuracy | For every included row, entity, period, account identifier, currency, and debit or credit value match the approved export under documented mapping and rounding rules. Required account references are valid, and agreed source and product totals reconcile. | Source-to-product comparisons, mapping rules, reference checks, and reconciliation results. |
| Traceability | For every amount used in the report, an authorized reviewer can identify the contributing source export and account row or rows, the processing version, and the outcome of relevant checks. | Export identifier, stable row reference, processing version, validation record, and a means to retrieve those links. |
The table deliberately says “accounted for” rather than assuming every source row will pass validation. A missing or invalid row must not disappear silently. Equally, an exception list is not permission to label an incomplete report “ready.” The downstream decision determines what must block readiness.
Some checks need domain qualification. A trial balance may be expected to balance under the customer’s accounting convention, but do not impose a blanket sum-to-zero rule without agreeing on the export’s scope, sign convention, and treatment of adjustments. Likewise, “all rows” needs an agreed rule for headers and subtotals. These details are part of making the requirement testable, not reasons to abandon it.
Great Expectations’ discussion of data integrity offers examples of relationships that simple row counts and type checks miss.
Validate data integrity with GX | Great Expectations
Read Great Expectations’ list of common integrity challenges to distinguish valid-looking individual values from relationships that also need to hold.
On “Validate data integrity with GX,” find the list introduced by “Consider these common data integrity challenges.” Read the four challenges, ending with value dependencies, and stop before the paragraph beginning “Failing to validate data relationships.” Focus on referential integrity and consistency between related values as possible sources of financial-reporting errors.
A product requirement should identify which relationship matters to the decision; it need not choose a validation library or dictate implementation. For example, “every included account identifier resolves to the account mapping used for this report version” is clearer than “ensure data integrity.” Later lessons will develop validation rules and operational responses in more detail.
Make the evidence boundary explicit
Return to the last lesson’s source-capability distinction. Suppose the customer supplies a file at 08:50, and the report is usable at 09:05. The product may have processed the file quickly, yet the reviewer’s 09:00 decision deadline was missed. Conversely, if the customer supplies an approved export at 17:00 and the product receives it at 17:05 but cannot validate it until 09:05, the ingestion journey has missed the proposed requirement even though the file arrived on time. Record these timestamps separately rather than collapsing them into “ingestion completed.”
Completeness has a similar boundary. Suppose the product receives 1,000 eligible rows and accounts for all 1,000. That demonstrates completeness relative to the received export. If the source should have produced 1,010, you need independent source evidence to detect the missing ten. A credible requirement states the scope of its claim and names evidence that is unavailable. Do not report “100% complete” without saying complete against what.
Accuracy also needs a reference. A product can compare a report total with the imported approved export and detect a transformation error. It cannot, from that comparison alone, determine whether the approved export omitted a legitimate transaction. When the use case requires a stronger assertion, identify the authoritative reference or reconciliation process the customer can provide.
For traceability, choose identifiers that survive routine processing: an export identifier, accounting period, entity, and a stable source-row reference where available. Record which mapping and validation rules were applied. The reviewer need not see sensitive raw files or internal logs; the requirement is that an authorized person can follow a defensible link from a reported value back to its source evidence. Who can access that evidence is a separate governance decision.
Fowler’s discussion of service-level objectives helps place these requirements in product planning.
Designing data products - Martin Fowler
Return to “Designing data products” for its discussion of how consumer-facing objectives guide implementation and measurement.
In “Defining service level objectives (SLOs),” read the SLO discussion, stopping before “How big should data products be?” Focus on the distinction between defining an objective for the consumer and deriving measurements that can demonstrate whether it is met.
You do not need to call every row in the draft table an SLO. At this stage, the important move is to make the consumer’s expectation explicit, along with its scope and verification method. An objective such as “usable by 09:00” can later be monitored across close cycles. A traceability requirement such as “identify the contributing export and rows” may be checked through review and testing. Neither is improved by a numerical target that lacks a defensible way to measure it.
A compact way to review any draft requirement is to ask:
- Decision: What would the user do incorrectly—or be unable to do—if this failed?
- Scope: Which entity, period, version, and records does it cover?
- Boundary: Where does the customer’s source responsibility end and the product’s claim begin?
- Proof: What observable evidence would show a pass, a failure, or an unresolved unknown?
Those questions keep requirements tied to the use case instead of turning them into an indiscriminate list of desirable data properties.
Key takeaways
Work backward from the downstream decision to the specific dataset and usable state it requires. Define freshness with a source event and user deadline; completeness against an explicit expected population; accuracy against agreed source values and financial rules; and traceability as the ability to reconstruct a reported value’s origin and processing history. For each claim, specify what evidence can support it—and what remains unknown about the customer’s source.
Next, you will examine friction in a current ingestion journey using customer evidence. These requirements will help you recognize which observed problems actually prevent a user from trusting or using the data.