An edge agent misses its accuracy target. The instinct is to reach for a bigger model — swap the architecture, add parameters, or try a different framework backend. On an edge-constrained inference target, that instinct is often the wrong lever. The memory ceiling and tail-latency budget you inherited when you picked the deployment target mean a bigger model is not an option. The model is effectively frozen, and the data becomes the only tunable surface you have left.

A data-centric approach accepts that constraint and works inside it. You hold the model and the framework fixed, and you iterate on the training and calibration data instead: curating representative on-device inputs, fixing label noise, and building calibration sets that reflect the actual deployment distribution rather than the data-centre benchmark you validated against. Everything below is about how that shift changes what “improvement” means once the compute budget stops moving.

Why the model-centric instinct breaks down on edge

The model-centric reflex is intuitive because it usually works in the data centre. If accuracy is short, you scale — more parameters, a stronger base model, a heavier decoder — and the gap closes. That reflex is portable right up until the point where the deployment target has a hard memory ceiling.

On a device with a fixed HBM or SRAM budget, a cold-start footprint you have to hit, and a tail-latency envelope the orchestration layer has to respect, “make the model bigger” is not a knob. A larger model does not fit, or it fits but blows the latency budget, or it fits and runs but the binary size and cold-start cost push past what the agent runtime tolerates. The moment you accept that the edge constraint is binding is the divergence point. After that, the model-centric and data-centric paths stop being interchangeable, and only one of them is still open.

Teams that ignore the divergence point tend to rediscover it the hard way. They keep reaching for a larger model, hit the ceiling again, and eventually end up rewriting the production boundary — re-partitioning what runs on-device versus off-device, or re-scoping the whole agent — because the compression and framework decisions were never treated as fixed. That production-boundary rewrite is expensive precisely because it is a decision that should have been settled before the data work began. A feasibility check that confirms the deployment data distribution is captured before a framework is committed is the cheaper place to catch it.

What data-centric actually means when the model is frozen

Held fixed, a model is a function whose accuracy is bounded by two things: the capacity it has, and the quality of the data that shaped its weights and its calibration. You cannot touch capacity on a frozen edge model. So the data-centric approach concentrates every degree of freedom on the second term.

In practice that decomposes into three distinct kinds of work, and it helps to keep them separate because they fail differently:

• Input curation — assembling a training and fine-tuning set of on-device inputs, not proxies. The data an agent actually sees at the edge (noisy sensor frames, truncated user turns, degraded audio, partial context windows) rarely matches the clean corpus a model was pre-trained on.
• Label-noise cleanup — finding and fixing mislabeled examples. On a frozen small model, label noise costs proportionally more than it does on a large one, because the small model has no spare capacity to average over contradictory supervision.
• Calibration-set construction — building the representative sample used to set quantisation scales, confidence thresholds, and any post-training calibration step. This is the piece most teams get wrong, and it is where the edge constraint bites hardest.

None of these adds a parameter. All three change what the fixed model does with the compute it already has. This is the same discipline we describe in fixing GenAI data-quality failures on production data — the edge case just removes the escape hatch of scaling the model when the data work gets hard.

Why the calibration set has to match the on-device distribution

Here is the failure that quietly wrecks edge accuracy: a model is quantised or threshold-calibrated using a calibration set drawn from the data-centre benchmark, then deployed against an input distribution that looks nothing like it.

Calibration is the step where a model’s activation ranges are measured on a representative sample so that low-precision arithmetic — INT8, INT4, or a mixed scheme — preserves accuracy. If that representative sample is unrepresentative, the quantisation scales are set for the wrong distribution. The model will look fine on the benchmark and lose accuracy the moment it meets real on-device inputs, and the loss is silent because your validation set is the thing that lied to you.

We treat the gap between the benchmark distribution and the on-device distribution as a first-class quantity worth measuring — call it calibration-set drift. In configurations we have worked with, closing that drift recovers more accuracy at a fixed inference budget than any amount of hyperparameter search on the frozen model, because it corrects a systematic error rather than a random one (observed across TechnoLynx edge engagements; not a published benchmark). The calibration set is not a formality you fill with whatever data is handy. It is the single most leveraged data artifact on an edge deployment, and it directly shapes which compression path holds accuracy — a link we develop further in the distillation-vs-quantisation compression decision for edge inference.

How do you measure accuracy recovered per fixed inference budget?

The whole point of going data-centric is that the budget stops being a variable. So the metric has to change with it. In a model-centric world you report accuracy per added parameter, or accuracy per added FLOP. On a frozen edge model those denominators are constant, which makes them useless as a scorecard.

The right frame is accuracy regained at a fixed binary-size and cold-start footprint — points of task accuracy recovered while the model size, the latency envelope, and the orchestration overhead all stay pinned. Two things share the scorecard:

• Task accuracy on the on-device validation set (not the benchmark) — the number you are actually trying to move.
• Calibration-set drift — how far the calibration distribution sits from the observed on-device distribution. Falling drift is the leading indicator; rising task accuracy is the lagging one.

A worked decision surface

Assume an agent with a fixed 40 MB binary budget and a 120 ms p99 latency envelope on-device, sitting at 78% task accuracy against a 90% target. The illustrative comparison below shows why the model-centric row is a dead end and how the data-centric rows are scored — the numbers are illustrative, not measured.

Lever	Fits memory ceiling?	Fits latency envelope?	Accuracy effect	Correct scorecard
Swap to larger base model	No	No	+8 pts (if it fit)	Blocked — violates fixed budget
Add parameters / heavier decoder	Marginal	No	+4 pts	Blocked — violates latency envelope
Re-curate on-device training inputs	Yes	Yes	+3 to +5 pts	Accuracy per fixed footprint
Fix label noise on frozen model	Yes	Yes	+1 to +3 pts	Accuracy per fixed footprint
Rebuild calibration set to on-device distribution	Yes	Yes	+2 to +6 pts	Drift closed → accuracy per fixed footprint

The top two rows are the reflex, and both are blocked by the constraint you already accepted. The bottom three are the tunable surface, and each is scored the same way: points gained without moving the footprint.

Where the data-centric readiness check meets framework selection

A data-centric readiness check is not only a fix applied after an agent underperforms. It belongs earlier, on the feasibility side, where the agent-framework decision is still open.

The question the readiness check answers is narrow and blunt: is the deployment data distribution captured before a framework is committed? If the on-device input distribution has not been sampled and characterised, then any framework choice is being made against an assumed distribution — usually the data-centre one — and the calibration failure above is already baked in. Confirming the distribution is captured feeds directly into the agent-architecture side of a feasibility assessment, because it tells you whether the framework and compression path you are about to commit to will actually hold accuracy on real inputs. This is the readiness step we run as part of a GenAI feasibility assessment: the data check is upstream of the framework commitment, not downstream of the failure.

The same fixed-compute constraint that makes the data the only lever also drives the compression decision. When memory and latency are pinned, whether you reach for distillation or quantisation depends on which path your calibration data can hold accuracy through — which is why we treat GPU-level compression and runtime fit and calibration-data quality as two views of the same problem rather than separate workstreams.

FAQ

What matters most about a data-centric approach in practice?

You hold the model and framework fixed and improve the data that shaped them: curating representative on-device inputs, fixing label noise, and building calibration sets that reflect the real deployment distribution. In practice it means treating data quality per fixed compute as the improvement lever instead of model scale. On edge targets this is not a preference — it is the only surface left once the memory ceiling freezes the model.

Why does the model-centric instinct (swap or scale the model) break down on edge-constrained inference targets?

Scaling works in the data centre because you can spend more memory and compute to close an accuracy gap. On an edge target with a fixed memory ceiling and tail-latency budget, a bigger model does not fit, or fits but blows the latency envelope, or pushes past the cold-start and binary-size limits the agent runtime tolerates. Once you accept the edge constraint as binding — the divergence point — the scaling path is simply closed.

What does data curation, label-noise cleanup, and calibration-set construction look like when the model is frozen by the memory ceiling?

Curation means assembling training inputs from the noisy, degraded, truncated data the agent actually sees on-device, not clean proxies. Label-noise cleanup matters more on a small frozen model because it has no spare capacity to average over contradictory supervision. Calibration-set construction is building the representative sample that sets quantisation scales and thresholds — the most leveraged data artifact on an edge deployment, and the one most teams get wrong.

How do you measure accuracy recovered per fixed inference budget rather than per added parameter?

You pin the model size, latency envelope, and orchestration overhead, then report points of task accuracy regained at that fixed binary-size and cold-start footprint. Accuracy per added parameter is meaningless when the denominator is constant. Track task accuracy on the on-device validation set as the lagging indicator and calibration-set drift as the leading one.

Why must the calibration set reflect the on-device input distribution rather than the data-centre benchmark?

Calibration sets the activation ranges that let low-precision arithmetic preserve accuracy. If the calibration sample comes from the data-centre benchmark, the quantisation scales are tuned for the wrong distribution, and the model loses accuracy silently on real on-device inputs while still looking fine on the benchmark. Closing this calibration-set drift corrects a systematic error, which is why it typically recovers more accuracy than hyperparameter search on the frozen model.

How does a data-centric readiness check feed the agent-framework selection decision before commitment?

The readiness check answers whether the deployment data distribution has been captured before a framework is chosen. If it has not, the framework decision is made against an assumed distribution and the calibration failure is baked in from the start. Confirming the distribution is captured feeds the agent-architecture side of a feasibility assessment, telling you whether the chosen framework and compression path will hold accuracy on real inputs.

When does data-centric iteration stop paying off, and what edge constraint signals that limit?

It stops paying off when calibration-set drift is closed and further curation or label cleanup no longer moves the on-device validation accuracy. At that point you have exhausted the data term, and the remaining gap is a capacity limit of the frozen model. The signal is a plateau in accuracy-per-fixed-footprint while drift is already near zero — which is when the compression or production-boundary decision, not more data work, is the honest next lever.

The harder question is not whether to go data-centric — on a truly edge-constrained target you have little choice — but when the data has given all it can. If task accuracy has plateaued while calibration-set drift is already near zero, more curation will not save you, and the real decision has moved back to the compression path and the production boundary you fixed at the start. Naming that plateau early, rather than iterating on data past the point it pays, is what separates a disciplined edge deployment from a slow rediscovery of the memory ceiling.