Publication, live updates and recovery

Target reliability contract. Existing pilots and bounded OSDU tests prove subsets. This page does not claim the whole design has shipped.

From source change to consumer update

1. Detect. Our applications can explicitly publish. External adapters may use callbacks, polling or export checks; unsaved edits may be invisible.
2. Capture. Select a consistent snapshot, stable identity and source fingerprint. Record conversion losses, durable publication intent and an idempotency key so retries can identify the same operation.
3. Publish. Write domain payload and metadata. Keep their exact version references distinct. Expose READY only when both are verified readable; do not assume an atomic transaction across OSDU services.
4. Observe. Authenticate supported OSDU change notifications and persist a durable inbox. Check readiness and reconcile stored state after missed events. External OSDU writers require this path too.
5. Deliver. Deduplicate and authorize events by tenant/subscription. Emit ready/deleted references through a qualified consumer gateway. Notifications carry references rather than whole scientific volumes; payload reads still check current access.
6. Apply. Follow advances to a verified revision; pin retains an exact revision. Fetch authorized data and update host state through the application’s supported thread/API boundary. Resume with a durable cursor and reconcile after retention gaps.

Recovery is part of the contract

Handle duplicate, delayed and out-of-order delivery. Stored authoritative state resolves notification uncertainty. Recover partial publication with pending/failed states and durable intent. Search indexing may lag a committed revision.

Compare expected base revisions before writing and expose conflicts. Propagate deletion and access removal to caches/workers. Permission revocation blocks future authorized reads/publication but cannot recall downloaded copies or undo prior model training.

Operators and AI jobs are consumers and producers: authorize pinned inputs, run a versioned algorithm, save output plus lineage, recheck publication access and only then publish READY. Avoid feedback loops through origin/causation identifiers, explicit direction and content deduplication.

Keep transport claims precise

A new database does not remove source polling delay or automatically implement two-way native edits. Do not promise subsecond updates without measured evidence.

The current scalar-map pilot uses a commit-driven gRPC revision stream from the ArrayBridge project service to a shared consumer bridge. QGIS retains bounded HTTP long-poll notices and separately reads exact payloads. ResInsight source capture still polls; access checks and reconnection also remain. Broad multiplexing and representative large-workspace load gates remain open.

This is existing ArrayBridge-backend evidence, not OSDU raster integration. SSE and WebSockets remain possible additional client transports, not implemented by this pilot. See current API and recovery semantics.

The qualification path covers fidelity, history, actual-client follow/pin, duplicate delivery, interruptions, operators, revocation and measured latency. Bounded native Excel tests cannot substitute for the shipped Office.js integration gate.

Try the illustrative follow/pin example · Explore customer diagnostics.