Insights23 January 2026Updated 25 October 20264 min read

Data Science for Offline-First Enterprise Apps

Data Science graphic showing a digital brain connected to servers and devices, highlighting automation, optimisation, and robust data architecture.

A prediction can keep arriving after its input data has broken. Google's Data Validation for Machine Learning paper describes an example based on a production outage where a software change replaces some input values with an error value. The model still produces predictions, but accuracy falls for the affected records.

For an offline field app, we would make that failure a starting point for design. Before promising better maintenance schedules or resource allocation, specify what the device knows, what it is missing and when it should stop recommending an action. We would judge the work by the decisions it improves, with the disconnected workflow included in the test.

Start with a decision a worker can take

Choose a narrow question for the first trial. For example, should a technician add a machine to the inspection list before leaving a site? Treat this as a proposed workflow, not a claim that a model can already predict a failure.

Write down the available action, who owns it and how the result will be checked. We would count unnecessary inspections alongside missed problems. We would also record time spent collecting the extra information the model requests. Agree those measures with the operations team before training starts.

Keep a simple comparison. The ML Test Score recommends testing whether a simpler model performs better. For our inspection example, we would compare the proposed model against the existing inspection rule under the same conditions. Do not replace a rule because the alternative uses machine learning.

Separate local prediction from local training

Running a trained model on a phone is an established deployment approach. Google's TensorFlow Lite announcement described on-device inference for mobile and embedded devices. That is evidence for where a prediction can run, not evidence that a particular field application will save money.

For a first deployment, we would train centrally and distribute a tested model to the app. Keep the model release separate from the records captured during a shift. Do not make local retraining a requirement unless there is a specific reason to learn on the device.

For each proposed input, ask whether the phone will actually hold it when the worker needs an answer. In our example, the latest local machine reading might be present while another team's repair report is not. We would either exclude that report from the offline decision or make the missing information explicit. Do not silently substitute an old value and label the recommendation current.

Define the data before choosing the algorithm

Give each input a meaning and an owner. For a temperature reading, our proposed input contract would specify the unit, the capture time, the machine identifier and the response to a missing reading. Include the app version that performed the conversion if that conversion changes between releases.

This is more than a database-format check. The data-validation paper explains how a value can be valid for its data type while representing an upstream error. In the inspection workflow, we would therefore test allowed values against the operational meaning of the field. A missing sensor reading should remain distinguishable from a measured value.

Keep the preparation code under review with the model. Google's Hidden Technical Debt paper identifies unstable data dependencies and discusses versioning input signals. We would release a model with its input definitions and conversion rules, then retain that combination for investigation. Record which combination produced each recommendation.

Test what the disconnected device will see

Do not assess the proposed workflow only against a complete central dataset. Build a test set representing the information available on the device at the moment of the decision. In our example, withhold the repair report until the point at which the technician's phone would receive it.

We would include a delayed download, an absent reading and an interrupted model update as separate scenarios. Specify the expected result for each one. An interrupted update should leave the app with a complete accepted model or a visible inability to predict, rather than an untested mixture of files.

Compare input preparation during training with the code used in the app. The ML Test Score calls for checks on training and serving differences. Here, that means checking the same example through both implementations, including unit conversions and missing-value handling.

We would also inspect results separately for the machine types in the trial and for records with delayed information. Report the number of evaluated examples with each result. Do not let an overall score substitute for examining the cases the field team will encounter.

Give uncertainty an operational response

Agree what the worker should do when required information is absent or too old. For this trial, our recommendation would be to preserve manual inspection and show why automated advice is unavailable. Do not interpret an unavailable prediction as permission to skip the inspection.

Set an owner for model updates and a way to withdraw a faulty release. The ML Test Score includes model-age checks and rollback capability. We would test those controls on the trial devices, including a device that reconnects after missing an update.

Start with recommendations that a technician reviews. Keep the recommendation, the action taken and the later outcome as separate records. Expand automation only after reviewing those outcomes against the agreed comparison. Any claim of reduced downtime or lower cost should come from that evaluation, not from the presence of a prediction screen.

Update, October 2026

When agents help implement these workflows, we recommend giving them the same input definitions and missing-data rules used in review. Our engineering article on grounding packs describes attaching dated evidence and explicit gaps to an agent's brief. For this workflow, put the offline acceptance scenarios in that brief before asking an agent to change the app.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →