AI-Ready Data Foundation Sprint

AI-ready data is data fit for a specific AI workflow, with known origin, permissions, quality, representativeness, freshness, access path, owner, limitations, and monitoring. A generic claim that the organization's data is clean does not establish readiness.

Map the workflow before the platform. Name the decision or task, the people affected, the inputs used at each step, any labels or outcomes used for evaluation, and the systems that create, transform, join, export, or manually correct the data.

For industrial AI, the map may cross sensors, a historian, MES and ERP records, equipment identifiers, timestamps, units, maintenance logs, operator notes, and local spreadsheets. Asset identity, time alignment, operating state, and units belong in the map because a plausible join can still describe the wrong machine or moment.

NIST's AI Risk Management Framework asks teams to document intended use, context, data, dependencies, assumptions, limitations, and affected parties. Source: NIST, AI Risk Management Framework 1.0. The Workflow Data Map turns that guidance into a source-to-use inventory.

Data is ready only when it is suitable for the intended workflow and evaluation. Test the dimensions that can change the decision: correctness, completeness, consistency, freshness, representativeness, provenance, label quality, permission, retrieval reliability, and leakage risk.

Define each test from the workflow requirement. Freshness means something different for live equipment alerts, quarterly forecasting, and policy retrieval. A high average score can hide one blocking field, class, site, or access rule.

NIST's AI RMF Playbook asks teams to examine data suitability, representativeness, quality, provenance, assumptions, limitations, and ongoing measurement. Source: NIST, AI RMF Playbook.

The Workflow Data Fitness Scorecard uses pass, watch, or block for each requirement and attaches the test method, evidence, threshold, affected segment, owner, and action. A block stops the dependent test or release until resolved or explicitly accepted.

A blocking failure mode is a data condition that makes the intended workflow unsafe, unusable, unevaluable, or economically unjustified. Rank failure modes by their effect on the workflow, not by the number of fields affected.

Common blockers include unknown origin, incompatible identifiers, misaligned timestamps or units, stale extracts, missing outcome labels, target leakage, permission mismatch, unreliable retrieval, unrepresentative samples, undocumented manual corrections, schema drift, and no accountable owner.

The U.S. Government Accountability Office's AI Accountability Framework calls for attention to data origin, reliability, processing, intended use, performance, and ongoing monitoring. Source: U.S. GAO, AI Accountability Framework.

The Blocking Data Failure Register connects each failure mode to the affected workflow step, evidence, consequence, current control, detectability, decision status, owner, and required proof of closure.

The goal is to remove the blocking conditions for the target workflow, not to clean every source system. Choose the smallest coherent set of fixes that can satisfy the failed tests and make the next workflow decision possible.

A fix can change collection, identifiers, timestamps, units, labels, access, transforms, controls, evaluation design, or workflow scope. Sometimes the right action is to narrow or stop the AI use case because the required data cannot be obtained lawfully, reliably, or economically.

Define done as a rerunnable test result. A completed ticket, new pipeline, or revised policy is an implementation step; closure requires evidence that the workflow requirement now passes or that an authorized residual risk is recorded.

The Blocking Data Fix Plan names the failure mode, selected intervention, dependency, owner, cost and effort boundary, rollback, acceptance test, proof location, and release decision.

AI-ready data can stop being fit when collection changes, source systems migrate, schemas drift, permissions expire, populations shift, operating conditions change, or labels arrive differently. Monitoring must cover the data and the workflow outcome.

Assign separate responsibilities for source data, pipeline or retrieval, workflow outcome, access policy, and release decisions. One person may hold several roles, but an unnamed team cannot accept a failed test or close a blocker.

Use a cadence proportionate to workflow risk and rate of change, plus event triggers for source, schema, model, vendor, permission, population, or policy changes. Monitor the same segments and thresholds used in the fitness scorecard so drift has an operational meaning.

The Data Readiness Monitoring Plan records metric, population, threshold, owner, evidence location, review cadence, event triggers, escalation, containment, retraining or revalidation rule, and retirement condition.