first-mile data
Data as it actually exists at the start of the road: created for one purpose, about to be used for another. It is not wrong. It is not ready.
first-mile data noun — data standing at the beginning of the pipeline, produced by an operational system or a human process for a job that was not analysis and certainly not inference; raw not in the sense of unprocessed, but in the sense of not yet fit to be read by a model.
"Raw" is a processing state. First-mile is a position.
The two get used interchangeably and they are not the same claim. Raw describes how much has been done to a dataset: untransformed, as landed, straight off the source. It is a statement about pipeline stage.
First-mile describes where data is standing and what it was for. Data can be extracted, cleaned, deduplicated, modelled into a tidy dimensional schema and served from a governed warehouse — and still be first-mile data, because every one of those steps served the purpose it was originally collected for. None of them asked whether it answers the question a model is about to put to it.
This is why "we already have a data platform" is not a reply to the first-mile problem. A mature platform moves first-mile data very efficiently across all seven layers of the ecosystem. Efficiency of transport is not readiness of cargo.
Defined by the operational job it was created for. Its correctness is judged against that job — did the transaction complete, did the record save, did the form validate.
Defined by the question about to be asked of it. Its correctness is judged against that question — can the model resolve the entity, trust the definition, trace the origin, and can you tell afterwards whether it worked.
Six properties, and accuracy is not one of them.
Accuracy is assumed, not sufficient. These are the properties that decide whether a true fact survives contact with a model — each one routinely absent from data that passes every quality test it has.
Resolved
One real-world thing is one thing in the data. The same customer is not four records, the same product not three SKUs with different spellings. Ambiguity that a human silently reconciles, a model confidently averages.
Defined
The field means one stated thing, that statement is written down, and someone owns it. Not four teams with four sincere answers to what counts as an active account.
Traceable
You can reconstruct where the value came from and what transformed it — not approximately, and not only up to the boundary where your lineage tool stops looking.
Current
Fresh enough for the decision it feeds. Freshness is not a global setting; it is a per-question requirement, and most staleness incidents are a mismatch rather than a failure.
Governed
The policy travels with the data. Rules enforced on the source table and not on the extract someone took for a prototype are rules that describe your intentions rather than your systems.
Evaluable
There is some way to tell whether using it worked. Without it you have not built a system, you have built an opinion generator with excellent latency.
Correct data that produces a wrong answer.
Every row below is data that would pass an audit. The failure is not in the value; it is in the distance between what the value means and what the model assumed it meant. A query breaks loudly. A model answers anyway.
| Property | The data is… | …and the model produces |
|---|---|---|
| Resolved | Accurate, but the same entity appears under four identifiers. | A confident total that counts one customer four times. |
| Defined | Accurate, but "active" means something different in each source. | An answer that is right for one definition and quoted for all of them. |
| Traceable | Accurate, with no record of which logic produced it. | A decision you cannot defend, reproduce or audit later. |
| Current | Accurate as of last night; the decision is about this morning. | Yesterday's answer, delivered with today's confidence. |
| Governed | Accurate, and copied into a prototype the policy never reached. | A correct answer that should never have been computable. |
| Evaluable | Accurate, with nothing to compare the output against. | Output nobody can call wrong — which is not the same as right. |
Why unready data fails quietly
A broken join throws. Unready data answers.
This is the property that makes first-mile data dangerous in a way it never was for reporting. Every previous consumer of enterprise data was brittle, and brittleness was a feature: the pipeline failed, the dashboard went blank, somebody was paged.
A model has no such reflex. Feed it ambiguous entities, stale values, or a field whose meaning quietly changed two releases ago, and it will not decline. It will produce fluent, plausible, well-formatted output at exactly the same confidence it would have shown on perfect input. The failure is real and the alarm never rings.
Which is why readiness has to be established upstream, in the first mile, rather than detected downstream. There is no downstream signal to detect it with — the last mile fails loudly and the first mile does not.
First-mile data, answered.
What is first-mile data?
Data as it exists at the start of the pipeline: created by an operational system or a human process, for a purpose that was not analysis and certainly not inference. It is raw in a specific sense — not unprocessed, but not yet ready. Almost all enterprise data is first-mile data until someone does the work of making it otherwise.
What is the difference between first-mile data and raw data?
Raw data describes a processing state: untransformed, as landed. First-mile data describes a position and a purpose — data still standing at the start of the road, defined by the operational job it was created for rather than the model job it is about to be used for. Data can be heavily transformed, cleaned and modelled and still be first-mile data, because none of that work made it fit for the question a model is about to ask of it.
What makes data model-ready?
Six properties, none of which is accuracy: it is resolved, so one real-world thing is one thing in the data; defined, so a field means one stated thing and the definition has an owner; traceable, so its origin can be reconstructed; current, at a freshness matched to the decision it feeds; governed, so policy travels with the data rather than sitting on the table it came from; and evaluable, so there is some way to tell whether using it worked. Correct data can fail every one of these.
Why is correct data not enough for AI?
Because a model does not refuse bad input the way a query does. A broken join returns an error; ambiguous, stale or undefined data returns a fluent answer with no signal that anything was wrong. Correctness protects you from data that is false. Readiness protects you from data that is true, and still produces a wrong answer.
Who owns first-mile data?
Usually nobody, and that is structural rather than accidental. The team creating the data owns an operational outcome, not a downstream one. The team consuming it owns a model, not the source. Readiness falls between the two seats, so it is the work that gets discovered late — at the point where a model is already producing answers nobody can defend.