Offline-authoritative clients
Search, routing and inference all run locally.
Technology · Architecture · Whitepaper
The device is the source of truth.
NavTrax inverts the usual arrangement. The handset holds authoritative state; the server is a convergence point and a distribution mechanism. Every architectural decision below follows from that one, and this page is the index to the rest.
01 / Problem statement
What this has to solve.
The architecture answers one question: what is authoritative when there is no network?
In a conventional client-server design the answer is "the server", and the client degrades to a cache with a spinner. Every capability that matters in the backcountry — search, routing, the assistant, the map, the group picture — is therefore unavailable in the conditions the product exists for.
NavTrax answers "the device". That makes synchronization a merge problem rather than a fetch problem, which is harder to build and the reason the rest of these pages exist.
02 / Mechanism
The design, component by component.
- Clients
- A React and TypeScript web application, Flutter applications for iOS and Android, a Flutter administration client, and template surfaces on Android Auto and CarPlay. All read the same API and hold the same local state model.
- Services
- Independent services for routing, resupply, alerts ingestion, retrieval-augmented knowledge, audio classification and solar analysis, each with its own container and its own scaling profile.
- Data layer
- PostgreSQL as the store of record, tenant-partitioned, with Redis for cache and queue. Tile data is proxied and cached rather than stored.
- Local state
- SQLite on mobile, IndexedDB on web. The operation log, offline regions, the search index, the knowledge base and the model files all live here.
- Transports
- Cellular, Wi-Fi, mesh radio, LoRa store-and-forward, satellite and signed removable media, all converging on one ingest path.
- Inference
- TensorFlow Lite on the handset for classification, a model router for escalation, and retrieval over a curated corpus when a link exists.
- Observability
- Prometheus, Grafana and Alertmanager, with an in-app error log surfaced to administrators rather than only to us.
03 / Properties
What this guarantees.
Service isolation
A routing outage does not affect resupply or emergency escalation.
Multi-tenant by construction
Tenant partitioning in the schema, not in application filters.
One ingest path
Every transport converges on the same resolver and audit logger.
Deployable air-gapped
The same build, with no egress.
Observable in the field
Errors are visible to the operator, not only to the vendor.
04 / Reference
| Component | Technology | Role |
|---|---|---|
| Web client | React, TypeScript, Vite | Full application surface |
| Mobile clients | Flutter | iOS and Android |
| Admin client | Flutter | Organization administration |
| Car surfaces | CarPlay and Android Auto templates | Six driving-safe entries |
| API | TypeScript service layer | Auth, billing, layers, sync ingest |
| Routing | FastAPI over OSRM, Valhalla, Overpass | Nine endpoints |
| Resupply | FastAPI with vendor adapters | Multi-vendor logistics |
| Alerts | Python ingestion service | Hazard and weather feeds |
| Knowledge | Retrieval service | Grounded answers when online |
| Audio | Classification pipeline | Waveform to class |
| Solar | Inference service | Site-level analysis |
| Store | PostgreSQL, Redis | Record, cache, queue |
| Local store | SQLite, IndexedDB | Op log, regions, models |
| Observability | Prometheus, Grafana, Alertmanager | Plus in-app error log |
05 / Process
Traced, node by node.
Start with the sync fabric.
It is the page that explains why everything else is shaped the way it is.