Data Field Services

Home · Field to verifiable view

The path in one line

Field (measure & hop) → Cloud (normalize & store) → Verifiable edge (serve attested release) → Verifiable view component (browser HMI that can prove what it shows).

LDUX is the framework for the last two hops and the human surface: native web components, open structured data, local private storage, edge publish, and sign/verify outside ordinary page script. Field radios and plant historians stay what they are; LDUX does not replace OT control. See LDUX and SCADA, measurement, connectivity, and open standards.

1. Field

Sensors, meters, cameras, gateways, well-data, and land/GIS systems produce events and records: pressure, gas, density, flow, water, environmental, inventory, device health, oil and well log curves (depth- or time-indexed), and land management features (leases, tracts, well spots) served through GIS services. Requirements stay the same regardless of radio or file drop — who · what · where · when · how much · how measured — with store-and-forward when the link drops and CRS/version identity when the “where” is a map layer.

2. Cloud

Aggregation and durable storage live where operators already keep production, HSE, and facility data — or in a thin cloud stage that only prepares office-facing slices:

Cloud holds bulk data and integration; it is not the trust proof by itself. Proof attaches when a responsible party publishes a specific view release.

3. Verifiable edge

The edge is where an attested LDUX release is served: HTML, layout, design tokens, and graph bindings hashed and signed so visitors get a known version — not an anonymous mutable bundle.

Edge concern LDUX role
Publish Push a signed version (layout + tokens + page bytes) to edge storage (e.g. KV / D1).
Serve Deliver that exact release to the browser; optional store selector for preview vs. live.
Verify Check the signature at the edge and/or in the browser (WASM / TEE boundary) so tampering shows as untrusted.
Identity Bind publisher Person and Organization (open identity) to the claim on the release.

Proofs do not have to start on a presentation card. They can begin in local private storage (OPFS) and later harden to device-bound stubs when stronger attestation is ready.

4. Verifiable view component

The human surface is a set of native web components — headings, notes, records, markup blocks — that render the approved layout and can expose the same facts as open structured data (JSON-LD). Verification is part of the view, not a separate admin tool:

End-to-end map

Stage What happens LDUX?
Field Sense, tag, hop, queue offline Outside — integrations sit beside the feed
Cloud Normalize, store, API to consumers Adjacent — data source for views, not the control plane
Verifiable edge Serve signed release; verify version Yes — publish + edge store + verify
Verifiable view component Render attested UI; show claim; bind open data Yes — native components + signed object

What this is not

This path does not set pump speeds, trip breakers, or replace safety interlocks. It is the accountable information path from field events to an office view someone can stand behind. Control and safety stay in OT. Engagement on which requirements to wire starts with the Discovery process.