Data Readiness Triage Loop

By Juan Beltrán, Industrial B2B AI Transformation Executive.

Is the data truly blocking the AI idea, or can we redesign around it? Use this when a team says the data is not ready and leadership needs to know whether that is a blocker, constraint, repair task, or excuse. Data Readiness Triage Loop Decision to make: Is the data truly blocking the AI idea, or can we redesign around it? Decision owner: AI product owner with data owner and process owner. Working-session setup: - Timebox: 45 min working session - People in the room: Process owner, frontline representative, delivery owner, and affected manager. - Preparation: Working prep: bring representative evidence, constraints, and a named owner. Context: [Paste your notes, excerpts, draft, meeting transcript, CRM fields, proposal text, public research, or examples here.] Context I should provide: - Use case - Required decisions - Data sources - Data quality concerns - Access constraints - Sample records Safety boundary: - Use only information I provide in this conversation. - Do not infer personal, confidential, regulated, pricing, customer, employee, or supplier facts. - If the material belongs in an approved enterprise environment, tell me before analyzing it. Instructions: Act as a data readiness triage lead. For the AI use case below, identify the minimum data required, inspect the stated quality issues, and classify each gap as blocker, constraint, repair task, or irrelevant. Recommend proceed, redesign, repair, or stop. Run the session in this order: 0. Inspect the context. If a missing fact could materially change the recommendation, ask no more than five focused questions and wait. If I ask you to continue, mark each missing fact as unknown. 1. Name the decision: State what the AI system must decide, recommend, generate, or route. 2. List minimum data: Identify only the data needed for that decision, not every possible dataset. 3. Sample reality: Inspect examples for missingness, freshness, consistency, bias, and access. 4. Classify the gap: Mark each issue as blocker, constraint, repair task, or irrelevant. 5. Choose the path: Proceed, redesign, repair, or stop. Evidence rules: - Separate supplied facts, interpretations, assumptions, and unknowns. - Reference the exact note, excerpt, metric, or example supporting every material claim. - Show the strongest credible counterargument to the recommendation. - Do not invent customer facts, benchmarks, financial numbers, policy approvals, or system access. - Do not turn missing evidence into a confident recommendation. - Keep the answer useful for AI Product Owner. Output contract: A proceed, redesign, repair, or stop recommendation tied to the minimum data actually needed. Return: 1. BLUF: the decision, recommendation, or draft in plain language. 2. Evidence table: claim, supplied evidence, confidence, and gap. 3. Assumption ledger: what is assumed and how to verify it. 4. Counterargument: the strongest reason the recommendation may be wrong. 5. Decision record: decision status, accountable owner, next action, and due date or trigger. 6. Evidence still needed: only the gaps that could change the decision. 7. Stop condition: state when the work is complete and when it must pause. Evidence checklist: - Decision definition - Minimum data list - Sample records - Quality issue - Impact on output - Owner Human operating ritual: - Inspect sample records together. - Do not accept abstract data quality complaints. - Let the process owner define usefulness, not only the data team. Do not use this loop when: Do not use it when nobody in the room owns the workflow or can change the operating conditions. Stopping condition: Stop when the team can say exactly which data issue blocks which decision.

Canonical URL: https://juanbeltran.ch/operating-loops/data-readiness-triage-loop