How the product architecture fits
The seven architecture diagrams define an accepted direction. Current pilot evidence and release gates determine what can be claimed as implemented. This guide collects the commitments behind those diagrams.
01 — Interchange preserves supported meaning
Section titled “01 — Interchange preserves supported meaning”External application connectors map selected content into shared scientific contracts. Capture original files where allowed and publish a capability/loss report per application, version, type and direction. Native documents can remain external.
There are four distinct levels: bytes that can be independently read; meaning such as identity, units, nulls, axes and coordinate/datum claims; behavior such as native loading, editing and write-back; and workflow such as history, links and conflicts. Passing one level does not establish the next.
Host SDK restrictions, licensing, proprietary solver state, unexposed edit history, missing destination equivalents and application UI constraints limit reconstruction. Our own applications can share a richer contract. Third-party write-back remains dependent on their APIs.
Connector scope · Product overview.
02 — OSDU foundation, ArrayBridge experience
Section titled “02 — OSDU foundation, ArrayBridge experience”Three groups use the intended scientific interfaces: external applications; our own Mac/web scientific applications; and customer or partner code such as Python, notebooks and AI tools. Our first-party clients should use the same public scientific contracts as independent consumers. A customer’s own environment need not be our SaaS account.
| Boundary | Responsibility |
|---|---|
| Connectors | Host access, semantic mapping, extraction and declared read/write/event support; host credentials remain at their execution boundary |
| ArrayBridge contracts and product API | Asset identity, exact revisions, scientific metadata, conversion reports, provenance and publish/read/follow/pin/derive operations |
| Application state and execution | Workspaces, bindings, reviews, jobs, checkpoints, durable publication intent and scoped workers using pinned inputs |
| Reactivity and backend adapter | OSDU mapping, capability discovery, durable event handling, reconciliation and consumer replay |
| OSDU services in OSDU mode | Records, schemas, search, entitlements, legal tags, suitable domain data services and qualified notification topics |
| Customer stores and compute | Governed originals, domain payloads, versioned outputs and approved datasets; optional rebuildable caches and previews |
OSDU authorization remains authoritative; product project permissions can restrict it further but cannot grant denied access. Never write raw databases to bypass governance. Metadata and bulk payload revisions remain distinct exact references. Each published asset has one authoritative backend, with explicit validated migration. The existing ArrayBridge backend remains usable while OSDU is qualified.
Logical boundaries do not require a fleet of microservices. Start with a few modules/processes and split when operating evidence warrants it. Reuse supported upstream APIs without a platform fork. Any component patch needs a demonstrated blocker, tests, an owner and an upstream/exit plan; a broad fork requires a superseding decision.
OSDU qualification · Developer direction.
03 — Live updates include recovery
Section titled “03 — Live updates include recovery”A source change must become a captured snapshot, then a verified published revision, before consumers advance. Source events, storage notifications and desktop update transport are separate mechanisms. OSDU notifications do not automatically provide desktop streaming or solve scientific conflicts.
Read the complete live-update contract.
04 — Ownership extends through AI
Section titled “04 — Ownership extends through AI”Ownership combines rights, scientific fidelity, operational control and independent usability. Customer identity, keys, storage and compute choices support that control. Documented source/sink contracts must check both asset access and permission to transfer to the chosen destination.
Keep originals, metadata, lineage and rights; derive versioned task-specific views; freeze exact inputs, labels and split assignments for reproducible training/evaluation. Preserve an independent exit for permitted data and artifacts. A storage bucket alone does not provide search, entitlements or application transactions.
Data ownership · Lineage and AI.
05 — Delivery follows evidence gates
Section titled “05 — Delivery follows evidence gates”M0 consolidates the baseline. M1 establishes scientific contracts, lineage and independent exit. M2 qualifies reliable OSDU publication and consumption. M3 delivers source/destination choices and a focused well-data workbench. M4 proves the complete MVP in actual supported clients with recovery, authorization, numerical validation, backup/restore and customer acceptance.
The complete journey is: choose authorized source/destination → publish exact revisions → inspect/follow/pin → derive → send to an approved destination → read independently. A prototype or native-host harness alone does not pass the shipped-client gate.
M5 expands qualified domain coverage and customer-sponsored connectors. M6 adds reproducible AI datasets and customer-controlled execution. Full seismic interpretation and broad physics suites are later scope decisions, not existing equivalence claims. Dates follow scoped estimates; milestones are evidence gates, not promised delivery dates.
Current roadmap · Availability.
06 — Customers own the science and its history
Section titled “06 — Customers own the science and its history”Our owned applications can capture scientific intent: exact inputs, operation/parameters/code version and outputs, including review and manual edits. External application history may be partial. Lineage is durable customer data, distinct from audit, sampled operational diagnostics and optional product analytics.
Customers should inspect each stream’s purpose, destination, fields and retention. Vendor sharing and AI training have separate permissions. Paid analysis tools can add value while underlying history and baseline access remain portable.
Lineage and AI · Telemetry and controls.
07 — Prove the boundaries in real applications
Section titled “07 — Prove the boundaries in real applications”The current visual pilot moves an authored synthetic PORO scalar map from ResInsight through ArrayBridge to Mac QGIS follow/pin layers and locally derived contours. It uses the existing project service; OSDU raster qualification is separate.
The sequence is fixture/source evidence → conversion and independent reading → actual QGIS consumption → updates/recovery/access checks → equivalent OSDU raster support. Sample values, masks, axes, half-cell positioning, coordinate claims, lineage and latency need explicit checks.
Values are not always elevation: pressure contours show equal pressure; PORO is unitless porosity. Record aggregation, timestep, units and resolution. Horizons also need depth sign and vertical datum. Rasterization may lose faults or overhangs. Do not guess a geographic coordinate reference system or silently interpolate. Text exports may round values; retain source text and quantify loss.
The pilot’s source/export checks poll. Commit-driven gRPC notifications now reach a shared bridge; QGIS receives bounded HTTP long-poll notices, fetches the exact revision in a worker and applies prepared layers on the UI thread. Large-map and many-client scalability remain unqualified. Local styling and extent are preserved, and bindings can be saved. GIS edits cannot reconstruct a reservoir.
A separate public USGS fixture now qualifies bounded horizontal CRS conversion and differing QGIS display coordinates. Datum/vertical changes, large maps, production installers, broader GIS publication and OSDU rasters remain separate gates. Do not relabel the synthetic map as NLOG field observations. Read the CRS guide.