A hedge fund was storing large volumes of unnecessary and polluted data, and nobody had noticed. The storage layout duplicated records, and the aggregation step feeding the models was discarding information that mattered for training. Fixing the foundation cut storage costs by more than 60% and made the models perform 2% better — the full account of what happens to data nobody owns sits with the ownership argument.
None of it announced itself. A pipeline that duplicates records still returns rows; an aggregation that destroys variance still produces a table a dashboard can read. That is what makes data readiness expensive to get wrong — the failures that decide whether a model can work do not throw errors. A survey on AI data readiness (Gartner, 2025) found that 63% of organizations either lack the right data management practices for AI or do not know whether they have them, and the second half of that finding is the one worth sitting with.
"We came to Omar with messy data and a deadline we'd already missed once. He turned it into a working system in days, kept us updated throughout, and it held up in production — reliable in a way this field rarely is." — Head of Data, hedge fund
The same principle decided the outcome on the property valuation engine we built for a PropTech platform, which fuses listing photos, satellite imagery, and geospatial features to price homes within 10% of closing price for 90% of cases. What made that bar reachable was not clean data. It was a data path that refused to collapse its channels into a single number too early: the spread between the photo-derived, satellite-derived, and comparables-derived estimates is the signal the confidence bound was calibrated against, and a tidier warehouse that averaged the channels at ingest would leave nothing to calibrate.
Readiness is a threshold measured against one use case, not a grade an organization earns as a whole. A comprehensive survey on data readiness for AI (Hiniduma et al., 2024) finds that readiness metrics vary substantially across use cases, and research on data quality dimensions for machine learning (Mohammed et al., 2022) shows why: the impact of a given defect depends on the algorithm and the task, so the same dataset can be ready for one model and useless for the next. For a specific build, the data has to clear three bars:
- Accessible. Reachable programmatically, without a human exporting a spreadsheet
- Sufficient. Enough volume and history for the approach the model actually needs
- Preserved. The detail the model depends on survives every transformation between the source and the training set
The Three Invisible Failures
Three failure classes sit between data that exists and data a model can learn from. None of them raises an error, which is why they survive every audit built to look for errors. Each one sets the model's ceiling upstream of the model.
graph TD
S["Source records<br/>full detail"] --> A["Aggregation<br/>and rollup"]
A --> W["Warehouse<br/>duplicated layout"]
W --> M["Training set<br/>what is left"]
S -.- N1["Everything the model<br/>could learn from"]
A -.- N2["Variance discarded,<br/>irreversibly"]
W -.- N3["One entity,<br/>counted twice"]
M -.- N4["Ceiling set upstream,<br/>debugged downstream"]
style S fill:#1a1a2e,stroke:#16c79a,color:#fff
style A fill:#1a1a2e,stroke:#e94560,color:#fff
style W fill:#1a1a2e,stroke:#e94560,color:#fff
style M fill:#1a1a2e,stroke:#ffd700,color:#fffStorage you pay for and never read. Volume grows when deletion is nobody's job and retention is nobody's budget line — the hedge-fund foundation above is the shape of it. The diagnostic is blunt: ask which tables the models actually read, and see whether anyone can answer.
Aggregation that discards the signal. The rollup that makes reporting fast is the rollup that deletes the variance a model needed, and this failure runs in one direction only: once the raw detail is gone from the retained record, the model's ceiling is set upstream and no amount of tuning downstream will raise it. Research on multi-source image fusion for property valuation (PLOS One, 2025) found image-derived features such as built-up index and vegetation density ranking among the top predictors of sale price — features that exist for a model only if the images survive the path to the training set. The same argument runs one layer up for agents, where context is the real bottleneck: what a system is allowed to see is a design decision, not a runtime one.
The same entity, stored twice, disagreeing with itself. Two records, two identifiers, conflicting attributes, and no join key that resolves them. Training weights the duplicate twice, evaluation inherits the leak, and the accuracy number that comes back is measuring the wrong thing with great precision.
The cheapest data to store is the data you never collected. The most expensive is the detail you deleted before you knew the model needed it.
Audit The Path, Not The Warehouse
The audit that matters starts at the use case and walks backwards. List every field the AI system reads, trace each one to the system that produces it, and record where it lives, what shape and history it carries, and how stale it is by the time you read it. Missing data is the easy finding. The expensive one is a field that exists but reaches you through a manual export, a nightly rollup, or a system whose owner left.
Then ask the three questions no schema diagram answers. What does this path delete, what does it collapse, and what does it store twice? Every aggregation, deduplication, rounding step, and dropped column between the source and the model is a decision somebody made without knowing what the model would need, and each one now has to be defended or reversed on purpose.
Ownership is the column that decays fastest, so write it down as a contract: the source system, the one person accountable for it, the schema, the freshness it promises, and the validations that must pass. When a schema change breaks the pipeline, the contract names who to talk to. The companion piece on whether a dataset is genuinely build-ready turns this into a go/no-go test, and writing checkable targets before the build starts is what makes the contract enforceable rather than decorative.
Five Checks On One Source
Run these against the source the use case depends on, not against the organization's data estate. Drawing on research on data quality dimensions for ML pipelines (IEEE, 2024), five automated checks cover the ground: completeness (null rates in the fields the model actually reads), uniqueness (duplicate records that double-weight an entity), consistency (the same entity under different identifiers across systems), timeliness (feeds arriving when the model expects them), and validity (values inside the ranges the source claims to produce).
Add one the research does not cover, because it is a legal question rather than a statistical one: what personal data is in here, and are you permitted to train on it? Automated decision-making on personal data (GDPR) is governed specifically, and exposure is assessed before training begins — not after a model has memorized something that cannot be unlearned.
The checks are gates, not a report. A check that logs a warning and lets the load proceed is a check that documents the failure it was supposed to prevent, so wire them to block and let the first run fail loudly. What that first run rejects is the remediation scope, priced — which is the cheapest moment the gap will ever be visible.
Where The Pipeline Stalls
This approach assumes at least one source system that can be reached programmatically. Where the source is paper, a legacy application with no API, or knowledge that lives only in someone's head, the pipeline-first plan stalls at extraction and no tooling downstream rescues it. The work moves upstream to capture design — get the process to emit structured, accessible data in the first place — and that is a product change before it is a data change. Where the blocker is instead a dependency you cannot reach on demand, the EHR integration simulator built for the ECG platform is the pattern: model the dependency well enough to keep building against it.
There is a second stall point, and it is the one that decides whether a build deserves funding at all. On the valuation engine, producing a point estimate was the easy half — calibrating when to trust it was the harder build, and that calibration was only possible because the data path had preserved the per-channel disagreement it needed. Deciding what a foundation must never throw away is a design judgment made once, and it is made before the pipeline is written or it is not made at all.
First Steps
- Name one use case and list its fields. Not a data strategy — the fields. Every column the model reads, traced back to the system that produces it.
- Ask the path what it destroys. Walk from source to training set and mark every step that aggregates, deduplicates, rounds, or drops. Each mark is a decision to defend or reverse.
- Wire the five checks as blocking gates on that one source. Let the first run fail, and cost what it rejects before anyone commits to a build.
Prove The Data Path First
If the use case is named and the data path is the thing nobody can vouch for, the next move is not a warehouse program. It is a spike against the real sources: one pipeline that preserves what the model needs, five checks wired as gates, one named owner per source, and a queryable store — a scheduled script loading into PostgreSQL clears this bar for a first build, and Airbyte, dbt, or Dagster can wait until scale makes them necessary. Research on AI adoption timelines (MIT Sloan, 2018) shows that organizations waiting on universal data readiness take significantly longer to deliver value — and a foundation built for a use case that does not exist yet is a foundation built to a guess.
Proving the path on your own data, with your own sources, before the build is budgeted is exactly what an AI system design engagement produces — a plan, a fixed quote, and a working spike in your stack, credited against the build if you go ahead. The bar for what it must hand back is set out in what a good AI system design includes. The decision it protects is the expensive one: whether the detail your model will need still exists by the time it reaches the training set, and what it costs to keep. The foundation that comes out the other side is small, owned, and specific — and it is the one every model after the first gets to build on.
References
- Gartner. Lack of AI-Ready Data Puts AI Projects at Risk. Gartner, 2025.
- Hiniduma, K., Byna, S., & Bez, J. L. A Comprehensive Survey on Data Readiness for Artificial Intelligence. arXiv, 2024.
- Mohammed, S., Budach, L., Feuerpfeil, M., Ihde, N., Nathansen, A., Noack, N., Patzlaff, H., Naumann, F., & Harmouch, H. The Effects of Data Quality on Machine Learning Performance. arXiv, 2022.
- IEEE. Research on Data Quality Dimensions for ML Pipelines. IEEE, 2024.
- Deng, L. Real estate valuation with multi-source image fusion and enhanced machine learning pipeline. PLOS One, 2025.
- European Union. Article 22 — Automated Individual Decision-Making. GDPR.
- MIT Sloan Management Review. Artificial Intelligence in Business Gets Real. MIT Sloan Management Review, 2018.
