What “discovery” means here
In oil & gas and data-center work, valuable signals already exist: meters, plant historians, work tickets, inventory, change logs, photos, and crew notes. The problem is rarely “no data.” It is that nobody can say — with confidence — what was found, where it came from, who attested it, and what view the office is allowed to trust.
The Discovery process is that accountable path: locate sources, name them with a shared vocabulary, bind them into operator-facing views, and publish only what a responsible party has signed.
The bridge LDUX provides
LDUX builds on the open web: pages made of standard browser components, described with open structured-data conventions, themed with portable design tokens, and released as a signed object anyone can inspect. Discovery uses that stack as the field-to-office bridge:
- Find — inventory field systems and files (telemetry exports, reports, site inventories) without replacing the control plane.
- Describe — map each source to open, shared terms so “well,” “facility,” “reading,” and “change record” mean the same thing in the screen and in the record.
- Present — show discovery results in standard web components operators and office staff can use — not a black-box export locked to one vendor.
- Attest — sign the published view so the office knows who stood behind it and what exact release was approved.
- Verify — check that signature when the page loads (in the browser or at the edge) so a tampered view shows as untrusted, not silently accepted.
Accountability with open standards
| Need | Open approach | Role in Discovery |
|---|---|---|
| Shared meaning | Open structured data & vocabularies | Name people, organizations, pages, and field entities so systems can interoperate. |
| UI without lock-in | Native web platform components | Operator views that run in the browser; no single framework required. |
| Look & brand | Portable design tokens | Consistent theming tied to the publishing organization. |
| Who published | Open identity for person & organization | A named agent on the claim. Proofs do not have to originate from a card — they can start in OPFS and later move to hardware stubs. |
| What was approved | Signed objects / content credentials | A verifiable fingerprint of the approved release; inspectable by the reader. |
| Trust boundary | Isolated sign & verify (local or edge) | Crypto and checks stay outside ordinary page script so attestation stays bounded. |
| Portable source of truth | Local private storage (OPFS) & exportable site database | Discovery versions and early proofs live on-device first, then sync or harden when you choose. |
Field → office, without claiming plant control
Discovery sits beside SCADA and facility systems. It does not set pump speeds or trip breakers. It answers: what sources did we find, how are they labeled, which slice is in this office view, and who attested that slice. For how LDUX relates to HMI, config, and audit ideas, see LDUX and SCADA.
Discovery process = find field sources → describe with open standards → present in the browser → sign the release → verify before the office trusts it.
Why this matters for consulting
A discovery engagement that ends in a signed LDUX view leaves the operator with something auditable: not only “we looked around,” but a durable, standards-backed record of what was surfaced and who stood behind publishing it. That is the accountable bridge from field data to office decision-making — without locking you to a proprietary stack.