Skip to content
Network/Access THE DEFINITIVE GUIDE

The Everything App

In one line: if a project is a document, the Everything App is the one client that reads it — a single dynamic shell that becomes whatever program it is handed, on a phone in a dead zone or a browser at a desk.

This is the client/runtime half of the platform vision. The SmartProjects Platform is how a program is authored and generated (declare six layers, get a field-grade application). This page is about the surface that runs it — and why that surface is the most important real estate we own.

Why the app is the most important real estate

A program is only as good as where people meet it: the crew on the trench, the manager in the inbox, the executive on the dashboard. We are building one shell for all of them rather than a portfolio of apps that drift apart. “One app to rule them all” is not a slogan about features — it is an architectural stance: screens, workflows, and even on-device models are loaded as data, so the same shell becomes a fiber survey, a gas-weld inspection, or an approvals inbox without a new build.

  • Build field-first. Field is where mobile uniquely wins — offline, GPS/RTK, camera + on-device ML, guided capture — and where we already have a ~70% head start.
  • North star: the whole operating system in one app. Field workflows are simply the first “apps” that run on an OS-grade shell; office, NOC, and planning surfaces are absorbed over time.

The rendering model: data-driven hybrid

Each screen descriptor declares how it renders, and the shell picks at runtime:

  • Native SDUI — a curated, growing catalog of native renderers for everything offline-capable or hardware-bound (capture, RTK, camera-ML, maps). Fast, type-safe, offline-trivial.
  • WebView — the unbounded long tail (office, NOC, fast-changing screens), hosted from the responsive web app. Crucially it runs the same SDUI schema as native, so there is no torn feature set — one contract, two render paths.

The rule that keeps it honest: anything offline-capable or hardware-bound must be native; everything else may be a WebView. The boundary is data, so a screen is promoted to native when it earns it. We do not ship a native UI-DSL today — the WebView is the truly-dynamic escape hatch; a downloadable-UI interpreter stays on the roadmap, justified only once native-catalog churn demands it.

Agentic, by construction

AI is not a chat tab bolted to the side — the agent is a first-class actor on the same surface a human drives. It reads Kernel context, proposes or pre-fills steps, advances and branches a workflow, and calls the engine’s nodes as tools (the engine’s node registry is the tool registry). Proactivity is Kernel-event-triggered workflows surfacing next-best-actions (“you are 8 m from an un-surveyed pit — capture it?”).

Two commitments make this real in the field:

  • Intelligence-location-agnostic. The shell never branches on where inference runs — cloud model when connected, on-device model when not. One agent interface, two backends.
  • Offline agency is in scope. A crew in a dead zone still gets agent help, against a local tool subset and an on-device model.

On-device intelligence is just more data

On-device ML follows the same “everything is data, delivered on demand” pipeline as screens and workflows. A small universal core ships in the binary; everything else is delivered over the air from a model registry, content-hashed and cached exactly like a workflow definition — so a workflow’s offline bundle transitively pulls the models it needs. The registry honours a declared device-class floor, serving quantized variants per device class. New model, or a tenant-specific model, is a registry entry — never an app release.

How we get there: fork, then absorb

We do not greenfield this and we do not wait for the platform to be finished:

  • Clean-fork the existing KMP app now (it is already most of the shell) and build against the current engine contract, with the BFF as a migration seam — the engine and persistence move to the converged engine and the Reality Kernel underneath, invisibly to the app.
  • iOS to parity from the start, not deferred.
  • Built to absorb. The fork is deliberate and temporary: the intent is to fulfil every requirement of the sister field products and migrate their customers onto this shell — one destination, not a third parallel app.

The proof: one real procedure, fully offline

The first slice is deliberately narrow and deep — one real field procedure, end-to-end, fully offline, with on-device OCR auto-filling a form, GPS capture, an agent-authored flow, and idempotent sync when signal returns. It proves the spine end-to-end: fork-and-de-verticalize works, hybrid rendering works, offline + on-device ML + idempotent sync hold, and the migration seam lets the heavy backend convergence land later without blocking the client. Tracked as NETW-43.

Relationship to canon

This page is the client/runtime framing. It composes — and does not restate — its neighbours:

  • SmartProjects — the works-execution component / generation side (six layers, the program bundle, the generality test). The Everything App is what runs those bundles.
  • Reality Kernel — the substrate; captured entities are Kernel objects.

The mechanisms beneath this vision are ADR-pending, deliberately not canon yet: the SMP × wfb engine convergence and the Kernel offline-idempotent ingest contract will be filed as ADRs once decided (NETW-48, NETW-49). Until then they live in scratch, not here.