Enforceable Quality Expectations

From Fitness for Purpose to Enforceable Expectations 🧩

The last lesson framed quality as a relationship between data and a stated decision. That relationship becomes usable only when someone records what must be true, how a breach is recognized, and what happens next.

In this lesson, you will learn to:

  • Translate a consumer need into a quality expectation with all seven components
  • Distinguish preventive, detective, and corrective controls by purpose and conceptual placement
  • Judge whether a control is proportionate to the decision impact and risk it retires

Most phrases that pass for quality requirements are moods: “reliable,” “accurate enough,” or “trusted.” None can be breached consistently, which is precisely why they survive so long.

Seven Components, or It Is Not an Expectation 📋

A quality expectation is complete when it carries all seven components:

  1. Consumer and purpose: who relies on this and for what decision
  2. Relevant dimension: which quality dimension is at stake
  3. Expected condition: what good looks like for that dimension
  4. Tolerance or threshold: how much deviation is acceptable
  5. Accountable party: who is answerable for the expectation
  6. Evidence: how the condition is demonstrated
  7. Response: what happens when the expectation is not met

Drop any one and something specific breaks. Without a dimension, you can argue about the wrong failure. Without a tolerance, every deviation can become either a crisis or a shrug. Without an accountable party, the response has no clear owner. Without evidence, you are asserting quality rather than showing it.

In this conversation, Jessica owns a weekly figure for product leadership, and Ryan is helping her turn a vague need into an expectation that can be tested.

> **Jessica:** The requirement is simple. We need the weekly figure to be accurate. > > **Ryan:** Accurate against what? Which real-world condition are we comparing it to? > > **Jessica:** Against what actually happened, I suppose. > > **Ryan:** If next Tuesday's figure moves by four percent overnight, is that a breach or a normal week? > > **Jessica:** I genuinely do not know. Nobody has said. > > **Ryan:** Then there's nothing to breach. Any response is just someone's call, and we can't hold anyone to it. That's a preference, not an expectation.

Ryan does not need to invent the threshold. The accountable owner must agree it. But without a tolerance, a breach and its response cannot be judged consistently. A complete expectation could read:

ComponentExplicit expectation
Consumer and purposeProduct leadership uses the weekly adoption figure to decide where to intervene.
Relevant dimensionAccuracy
Expected conditionThe published count represents qualifying product activity from the reported week.
Tolerance or thresholdA variance greater than the agreed tolerance, 5% in this example, against the validated activity record is a breach.
Accountable partyThe product-analytics measure owner
EvidenceA weekly reconciliation to the validated activity record
ResponseMark the figure provisional, investigate the variance, and restate it if the issue is confirmed.

The number is not universal. The point is that every field is explicit enough to test, assign, and act on.

Control Purpose and Placement Are Separate 🛡️

A control has a primary purpose, but its placement must be judged separately against the consumer decision it protects. Classify what it does first, then assess when it acts.

SafeguardPurposeConceptual placementRisk retired
Require a valid cost-centre code before a transaction is savedPreventiveAt captureTransactions that cannot be attributed to a report
Reconcile the published revenue total against the source ledger before releaseDetectiveAt publicationAn overstated or understated figure reaching leadership
Re-run the affected report and withdraw the old version when a post-publication audit failsCorrectiveAfter consumptionDecisions left standing on a figure later found wrong

The four conceptual placements are at capture, in transformation, at publication, and after consumption. Placement does not determine purpose: a control running late may be detective rather than preventive. The test is whether its purpose and timing retire the stated risk before it materially affects the consumer’s decision.

A preventive control reduces the chance an issue occurs at all. A detective control reveals that an issue has occurred. A corrective control restores acceptable conditions or addresses consequences after a failure. A corrective control with no reliable detection or escalation trigger may not fire in time, or at all, within the designed control set. A complaint, audit, or manual observation can still expose the issue, but that is weaker coverage than a defined trigger.

Expectation to control map: define a quality expectation, place a control, test coverage, then act and refine.

What Risk Does This Control Actually Retire? ⚖️

Here is the question that should follow every proposed safeguard: what specific risk does this retire, for which consumer, and what would happen if we did not do it? Ask it out loud and a surprising number of controls stop justifying themselves.

Proportionality depends on the decision impact, the likelihood and consequence of failure, and the residual risk after the control operates. A heavyweight manual reconciliation may be unjustified for a low-stakes internal report. A regulatory submission may require additional or differently timed controls. In either case, ask which risk each control retires and what remains uncovered.

A stack of four controls can still leave the material risk untouched. If every control watches value correctness and none watches whether the load arrived at all, timeliness is undefended no matter how impressive the list looks. A reconciliation that runs monthly against a weekly measure may detect a problem three weeks after the decision was made.

Control coverage is not the same as expectation coverage. Controls without the seven components are unjudgeable because you cannot say whether a control is adequate until you know the tolerance it is meant to hold.

The takeaway is this: a control is only judgeable against an expectation that can fail, and an expectation can only fail consistently when all seven components are on the record. Three practices follow. Two quick checks first, on control purpose and the seven components, then a written assessment you could put in a review pack: classifying proposed safeguards by purpose and placement, naming unrecorded expectation components, and stating what remains uncovered. Before that, ask yourself: of the controls currently running around you, how many could you name the retired risk for without guessing?

Sign up

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal