The Environments Where Aircraft Actually Get Maintained
The mental image of aircraft maintenance — a well-lit hangar, organized workstations, reliable infrastructure — describes a fraction of where maintenance actually happens. The rest looks different.
It looks like a remote stand 800 meters from the terminal at 2 AM, where the airport Wi-Fi doesn't reach and the cell signal is marginal because three other carriers are also doing AOG recovery on adjacent aircraft. It looks like a maintenance tunnel under a bridge on a railway viaduct, no signal, one flashlight, a tech trying to find a specific torque value before the possession window closes. It looks like a hangar at a regional airport where IT staffed the network during business hours and it's now Saturday night.
These are not edge cases. They are the majority of where field maintenance happens. Any AI tool that requires connectivity to function is a tool that will fail in the moments when it is most needed — when the work is hardest, the environment is worst, and the time pressure is highest.
What "Works Offline" Usually Means — and What It Doesn't
When an AI vendor tells you their tool works offline, the first question to ask is: works offline how? The answer reveals whether offline capability was designed-in from the beginning or bolted on as a feature.
The app stores previously viewed pages and documents locally. You can read what you've already opened. Search may work against a local index of document titles. AI queries are queued and will process when connectivity is restored — meaning no AI capability during the outage.
The AI model runs on the device. The documentation corpus is stored locally. Search, retrieval, and citation work identically whether or not the device has internet access. The technician cannot tell the difference between online and offline operation — because there is no functional difference.
The distinction matters because the two implementations differ by a design decision made at the architecture level. Retrofitting genuine offline-first capability onto a cloud-dependent system is not a feature update — it requires a different architecture. Vendors who offer cached content and call it offline mode have not built an offline-first system.
The Connectivity Dependency Chain
Cloud-dependent AI creates a dependency chain that is only as strong as its weakest link. For a technician on a remote stand querying an AI system, the chain looks like this:
In aviation maintenance, the constraint is time. An AOG situation at 3 AM. An aircraft on a remote stand. A possession window on a railway track that closes in forty minutes. A tool that requires every link in this chain to function is a tool that can fail at the worst possible moment — not because of a software bug, but because of an infrastructure dependency that was never eliminated.
The question is not whether connectivity can fail. It will fail. The question is whether your AI tool fails with it.
What Offline-First Architecture Actually Requires
Genuine offline-first capability is not a feature. It is a set of architectural decisions made before a line of application code is written.
The AI model must run on the device — not call a cloud API. This means a model small enough to run efficiently on the target hardware (tablet, ruggedized device), optimized for on-device inference, with acceptable response latency without GPU acceleration. This is a different engineering problem from deploying a cloud model.
The organization's approved documentation corpus must be stored and indexed locally. The full corpus — not a subset, not a recently-viewed cache. Search and retrieval must operate against the local index. A document that hasn't been recently viewed must be just as accessible as one that has.
When connectivity is available, the device syncs: new document revisions download, interaction logs upload, configuration changes propagate. When connectivity drops, the device continues operating with its local state. Sync is background, non-blocking, and transparent to the technician.
Every query and response must be logged locally during offline operation. When connectivity is restored, logs sync to the central system with accurate timestamps. The audit trail must be complete regardless of whether the device was online during the interaction — this is a EASA NPA 2025-07 requirement.
Questions to Ask Before You Deploy
- Does the AI model run locally or does it require cloud API calls? Ask for a demonstration with the device disconnected from all networks. Test AI query response time in fully offline mode. If the demo requires connectivity, the system is not offline-first.
- What happens to search and citation when connectivity drops? The answer must be: nothing changes. If the vendor describes a degraded mode, a fallback mode, or a "read-only" mode — the system is not offline-first. Full capability should be indistinguishable from connected operation.
- How are document updates pushed to offline devices? When a document revision is uploaded by the administrator, how and when does it propagate to devices that are periodically offline? What is the maximum acceptable staleness? How does the system handle a device that has been offline for an extended period?
- Are interaction logs preserved and synced when connectivity is restored? Confirm that queries and responses logged during offline operation are uploaded with accurate timestamps when the device reconnects — and that the central audit log is complete, with no gaps for offline periods.
- What is the maximum time a device can operate offline before requiring sync? Understand the practical constraints: how long can a device be offline before document revisions make the local corpus materially out of date? What is the governance process for extended offline operation?
DokPath and the Offline Requirement
Offline-first is a DokPath design requirement, not a feature tier. The AI model runs on-device. The approved documentation corpus is synchronized locally during connected periods and available in full during offline operation. Queries, answers, and exact source citations — document name, revision, section, page — work identically whether the device has internet access or not.
Interaction logs are stored locally during offline periods and sync automatically when connectivity is restored. The audit trail is complete. There are no gaps, no offline exclusions, no periods where the system was operating outside the audit scope.
For line maintenance supervisors deploying to environments where connectivity is unreliable, the practical test is simple: take a device to the most connectivity-challenged location in your operation and use it. The experience should be identical to using it at a desk with reliable Wi-Fi. If it isn't, the system is not genuinely offline-first.
DokPath passes that test. We'd be glad to demonstrate it in your environment.
Request a field demonstration