Skip to content

D-07

Data Readiness

A decision-data readiness pattern backed by observed pipeline runs, source and history coverage, versioned rule results, signed reconciliations, and owned action history — with missing required evidence kept unknown rather than averaged into a score.

There is a reference build of this pattern: the Data Readiness dashboard in the showcase renders it over frozen, simulated data — not a live client system.

See the working synthetic reference build. The ERP data quality checklist and source history guide are supporting methods, not proof that any source is available.

What it answers

Can the selected decision use this run’s data? The answer is blocked when a required critical condition fails, unknown when required evidence is missing or unobserved, and satisfied only when every required source, history, rule, and reconciliation condition is evidenced.

Optional warnings stay visible beside a satisfied result. Raw pass counts and average scores cannot override one failed critical condition, and a prior run cannot fill a missing result in the selected run.

The wireframe

Data readiness dashboard with run and scope controls, three measures, decision status, exception worklist, and evidence tables

Evaluation Run | Data As Of | Decision Scope
Required Evidence %
Critical Failures
Open Actions
Ready / Blocked / Unknown by decision area
Accountable exceptions: rule, population, affected measure/view, owner, due date, evidence
Reconciliation | Retained History | Contract Version and Result
Filters
KPI / Metric
Primary Chart
Secondary Viz
Detail / Table

Layout basis

  • L-04 Tabbed Views separates readiness, accountable exceptions, and evidence history without changing the selected run
  • L-03 Master-Detail / Drill-Down keeps affected metrics, views, owners, and source evidence attached to each exception
  1. Run context one immutable run and its as-of date govern every figure.
  2. Measure row coverage, critical failures, and actions remain separate quantities.
  3. Decision status the state follows required evidence, never an average score.
  4. Exceptions each row retains affected measures, views, ownership, and evidence.
  5. Evidence history signed reconciliation, history start, and rule version remain auditable.

The evaluation model

The published evaluation is a snapshot over several canonical facts. Pipeline run supplies the immutable identity. A versioned readiness profile independently declares the source, history, rule-version, and reconciliation obligations pinned to that run and decision scope. Observations may satisfy those obligations; their absence never removes one.

Source coverage records one requirement version per run. Rule results key by rule version, population, and run. Reconciliations retain canonical minor-unit integer strings, declared decimal scale, units, tolerance, and sign. The profile reference arrays are the JSON transport for logical profile-to-source, profile-to-rule-population, and profile-to-reconciliation bridge rows.

fct_decision_readiness_evaluationPeriodic snapshot

Grain required condition × decision scope × evaluation run

Stored components

  • condition_kind
  • required_flag
  • observed_status
  • observed_count
  • reason
  • run_id

Foreign keys

  • dim_readiness_profile
  • dim_source_object
  • dim_rule_contract_version
  • dim_decision_scope
  • dim_issue_action
dim_evaluation_rundegenerate
  • run_id
  • snapshot_id
  • started_at
  • completed_at
  • status
  • data_as_of

One immutable identity for the evidence a readiness verdict is allowed to use.

dim_source_object
  • source_id
  • object_id
  • expected_population_status
  • required_history_start

Source/object expectations are versioned inputs; unknown expectations never become zero.

dim_decision_scope
  • scope_id
  • affected_metric_id
  • affected_view_id

Failures remain tied to the decisions and displays they can invalidate.

dim_readiness_profile
  • profile_id
  • version
  • decision_scope
  • source_requirement_ref
  • rule_population_ref
  • reconciliation_contract_ref

The run pins one immutable profile per scope, so missing observations cannot shrink the required population and later contracts cannot rewrite history.

dim_rule_contract_version
  • rule_id
  • version
  • population_id
  • severity
  • observation_requirement
  • failure_effect
  • empty_population_policy
  • owner

Rule identity includes its version and population; results from another version do not substitute.

dim_issue_action
  • issue_id
  • owner
  • due_date
  • status
  • evidence_ref

Action history is attached to the run that raised or resolved it.

Evaluation output joins observed facts by exact run identity; it never carries a previous result forward.

Measures and states

Data Readiness measures and their aggregation behavior.
MeasureFormulaAdditivityNote
Required evidence coveragesatisfied required conditions / required conditionsNon-additiveUnavailable when no required conditions exist; 100% is necessary but does not certify a customer deployment.
Critical failurescount(required condition where observed status = failed)AdditiveAny required critical failure blocks the selected decision scope.
Open actionscount(issue where status in open, monitoring)AdditiveCount within one selected run; old resolved actions never clear a newer failure.
Reconciliation differencesource amount - reference amountAdditiveCanonical minor-unit integers preserve sign and compare with an absolute tolerance only when units and decimal scale match.

A genuine zero is available evidence. Unknown expected population, missing count, and unobserved rule result render as unavailable and keep the decision state unknown.

Implementation notes

  • Declare canonical keys and reject duplicate run, source/object/run, rule/version/population, reconciliation/run, and issue identities.
  • Compare exact minor-unit integers only when units and declared decimal scale match; retain the signed difference and apply tolerance to its absolute value.
  • Version rule contracts independently from results and join on rule ID, version, population, and run.
  • Keep source availability claims outside the pattern until a customer adapter and observed reconciliation prove them.

Maintained by Summit Analytics, a supply chain analytics practice. The tools and references are free — the consulting is selective.

Part of the Summit Analytics reference library.

Work with the practice

Not affiliated with or endorsed by SAP, Oracle, Microsoft, or Infor. Product names are trademarks of their respective owners.