Garbage In, Hallucination Out: Why AI Trained on Modelled Data Inherits Its Blind Spots

Transport teams already know the difference between primary data (measured on the vehicle) and modelled data (estimated from averages) — it decides whether a CO2 report survives an audit. AI raises the stakes on the same distinction: a model trained on modelled inputs doesn't just inherit their errors, it learns them as truth, optimises against them, and presents the results with unearned confidence. This post explains how estimate-based inputs quietly corrupt fuel analytics, emissions optimisation, and cost models; why "primary data share" is becoming an AI quality metric, not just an audit one; and how to keep measured and modelled data working together honestly.

A distinction you already know — with new consequences

In emissions reporting the hierarchy is familiar: primary data — fuel actually burned, kilometres actually driven, measured on the asset — beats modelled data, which estimates from default consumption factors and assumed routes. Standards like the GLEC Framework and ISO 14083 accept both but require honesty about which is which, because the gap between fleet reality and default averages is routinely 10–30% in either direction.

AI inherits the same hierarchy with sharper teeth. A report based on modelled data is an estimate a human reads with judgement. A machine-learning model trained on modelled data is an engine that learns the estimates as ground truth — and then makes recommendations, predictions, and optimisations on top of them, at scale, automatically. The human reader applies scepticism; the downstream model applies none.

How modelled inputs corrupt models: three quiet failure modes

1. Learning the default instead of the fleet

Suppose your consumption data is largely modelled: distance multiplied by a default litres-per-100km factor per vehicle class. Now train a fuel-optimisation model on it. The model will discover — with impressive statistical confidence — that consumption depends almost entirely on distance and vehicle class. Driver behaviour, route profile, load weight, weather? Invisible, because the input data never contained them. The model isn't wrong about the data; the data was wrong about the fleet. The result: "insights" that restate your assumptions in a more expensive font.

2. Optimising against phantoms

It gets worse when the model acts. An emissions-optimisation engine fed modelled factors will recommend reallocating loads to the vehicle classes with the better default — not the trucks that actually burn less. The measurable savings on paper may not exist on the road. You can spend a year "improving" a number that never reflected reality, while real improvement opportunities (the depot with the idling problem, the driver cohort that never got coaching) stay invisible — they were averaged out of the training data from the start.

3. Confidence without provenance

The most dangerous property of trained models is that their outputs don't carry the uncertainty of their inputs. A prediction built on 95% primary data and one built on 20% primary data look identical on a dashboard: same decimal places, same confident tone. Without provenance — knowing which inputs were measured and which estimated — there is no way for a user, a customer, or an auditor to know how much weight an AI output deserves. "Hallucination" is usually discussed as a language-model problem; in analytics, training on estimates produces the numerical equivalent.

Modelled data isn't the villain — unlabelled data is

None of this means modelled data is worthless. Subcontractor legs without telematics access, historical periods before integration, modes you don't operate — estimates legitimately fill real gaps, and the standards explicitly provide for them. A fleet that refuses to report anything until everything is measured will report nothing for years.

The discipline that makes the mix safe is labelling. Every data point carries its method — measured, hybrid, or modelled — and that label travels with it into every downstream use: reports, analytics, and training sets. Then you can train on measured data where it is dense, use modelled data as context where it is honest, weight accordingly, and tell every consumer of every output what it stands on.

This is the same principle auditors are converging on for emissions, extended to AI: primary data share is becoming a model-quality metric. When a vendor demos an optimisation engine, the question "what share of its training data is measured rather than estimated?" tells you more about the ceiling of the product than any accuracy claim.

How CO3 does this today

Method labelling is built into CO3's data model rather than bolted on. Every emissions leg is calculated through a three-tier hierarchy — PRIMARY (measured fuel/energy), HYBRID (real distance with default coefficients), MODELLED (estimated distance and defaults) — and every leg carries its calculationMethod plus an aggregate primaryDataShare metric, mapped to GLEC Transport Chain Elements and aligned with the GLEC Framework and ISO 14083. The same pipe carries measured CAN-bus fuel consumption from 500+ telematics integrations across the mixed fleet. In AI terms: a training set with provenance attached — and a primary data share you can actively grow by integrating more of the fleet.

Getting started: provenance before models

1. Measure your primary data share — for analytics, not just audits. What proportion of the fuel, distance, and emissions data you would train on is actually measured? That number is your AI ceiling; most operators have never computed it.
2. Grow it the boring way. Every additional integrated vehicle and subcontractor converts modelled legs to measured ones. The same work that improves your audit position improves every future model — one investment, two returns.
3. Demand labels everywhere. From your own pipeline and from every vendor: method per data point, primary share per report, provenance on every AI output. If a tool cannot say what its numbers stand on, treat its confidence as decoration.

Self-assessment: would your data survive a model?

1. Do you know your current primary data share for fuel and emissions data?
2. Is every data point in your pipeline labelled by method (measured / hybrid / modelled)?
3. Can you filter your historical data to measured-only when building or evaluating analytics?
4. Are subcontractor legs labelled honestly rather than silently defaulted?
5. Has any analytics or AI vendor told you what share of your data their models actually learn from?
6. Would two identical-looking numbers from your dashboards — one measured, one modelled — be distinguishable by their consumers?
7. Is your primary data share trending up, with an owner responsible for it?
8. Do customer-facing reports disclose method shares the way auditors expect?

Three or more "no" answers means your data has a provenance problem — which every model you train or buy will quietly inherit.

What to watch over the next 12–18 months

• Auditors meet AI outputs. As CSRD-driven assurance matures, expect auditors to ask not just "what is the number?" but "what data produced it — and what model?" Provenance chains become evidence.
• Primary data share enters procurement. Shipper questionnaires already ask for method transparency in emissions; expect the same question aimed at AI-based analytics next.
• Regulated calculation tools. EU work on standardised emissions calculation (CountEmissions EU) keeps raising the bar for method transparency — labelled pipelines will adapt easily, unlabelled ones painfully.
• Provenance tooling matures. Data lineage and labelling are becoming standard features of serious data platforms; "we can't tell which inputs were measured" is shifting from common to disqualifying.

Closing thought

The industry spent a decade learning that an emissions number without a method label is a guess in a suit. AI compresses that lesson: models trained on guesses industrialise them. The fix is the same discipline, applied earlier — measure where you can, model where you must, label everything, and grow the measured share deliberately. Do that, and every model you ever train or buy gets better for free. CO3 builds the labelled, measured foundation; what you put on top of it is then genuinely yours to trust.

Glossary

• Primary data: Values measured on the actual asset — fuel burned, kilometres driven — rather than estimated.
• Modelled data: Values estimated from defaults and assumptions (average consumption factors, shortest feasible distance).
• Hybrid method: A calculation mixing measured and default inputs (e.g., real distance × default coefficient).
• Primary data share: The proportion of a dataset or report based on measured inputs; an audit metric becoming an AI-quality metric.
• Provenance / lineage: The traceable origin and method of each data point, carried through to every downstream use.
• Training data: The historical examples a machine-learning model learns from; its quality bounds the model's quality.
• Ground truth: What a model treats as reality during training — whether or not it actually is.
• Default factor: A standardised average value (e.g., litres per 100 km per vehicle class) used when measurement is unavailable.
• GLEC Framework / ISO 14083: The methodology and international standard for logistics emissions calculation, both requiring method transparency.
• CountEmissions EU: EU initiative toward standardised transport emissions calculation and disclosure.