Operation history and application observations
Qualified private pilot, reviewed 22 September 2026. This feature covers the server scalar-offset workflow and the OAuth QGIS scalar-map connector. It does not record every action inside QGIS, ResInsight or other applications.
Inspect a calculation
Section titled “Inspect a calculation”- Open a supported scalar asset in Workspace or the QGIS connector.
- Run a server offset and wait for publication of the new revision.
- Open the project’s Activity page. Inspect the completed operation’s exact input/output revisions, parameters, lineage and operation ID.
- Use Download loaded events (JSONL) to take a readable copy. This button exports only the events loaded by the page (up to 500). Use the paginated API and export utility for complete history.
The operation’s scientific meaning stays attached to the exact snapshot. For an offset, units and missing values are preserved and coordinates do not move. This is not a CRS transformation. Older operations are not backfilled into Activity. The native project service remains authoritative; this feature does not move data into OSDU or create an additional scientific authority.
Understand connected applications
Section titled “Understand connected applications”After restarting QGIS with connector 0.4.0, sign in through Browse Workspace and add a scalar asset. Its applied revision and follow/pin/copy mode appear in Activity. These are client-reported observations. They establish what the connector reports applying, not that a person viewed or approved the result.
A recent report does not guarantee the client is still online. A detached copy reports once and does not follow revisions. Paused or disconnected clients may show “not seen recently.” Legacy connection-file clients do not automatically report. New reports separate notification waiting, download, preparation and GUI layer application. Historical inclusive durations remain labelled legacy. Neither GUI application nor server publication-to-report lag measures final screen paint.
What each application records (below) lists what each integration can observe and what it cannot. Our own scalar operator records its parameters and exact inputs. The QGIS connector records its own delivery, but not arbitrary QGIS edit recipes. ResInsight and file profiles are currently declarations without event publishers. Never treat missing evidence as an inferred operation history.
What each application records
Section titled “What each application records”Activity shows only what an application reported or the server observed. A
delivery an application reports is not proof that a person looked at it. This
table is the list in words. The exact list your deployment’s server answers,
including profiles added after this guide, is in the one Technical details at
the bottom of the Activity page (coverage); each event names only its profile
(coverage_profile), so the downloaded JSONL does not contain the list itself.
| Application | Records | Does not record |
|---|---|---|
| Ophiolite calculation (server offset) | the exact inputs and result, the method and its version, the settings and their units, how long it ran | how the original was made, why someone ran it |
| QGIS (map layer) | the exact version received, whether the layer follows, is held at one version or is a copy, how long QGIS took to apply it; newer connectors also report time waiting for the notice, download time, preparation time, time to apply it in QGIS, and the longest it could have taken to arrive | everything else done in QGIS, everything else edited in QGIS, whether a person looked at it, how it was edited in QGIS, when it appeared on screen, whether the computers’ clocks agreed |
| QGIS processing | the connected inputs, the algorithm used, how long it took, whether it worked | the steps inside the processing engine, inputs that were not connected, whether the computer’s clock was right, other operations |
| QGIS result saved to Ophiolite | the checked result, the exact source version, whether it was new or a next version, a link to the QGIS record, when there is one | proof it ran on the computer |
| Ophiolite (archive and restore) | the exact inputs and result, archiving and restoring, who did it, the versions kept | removal of copies elsewhere, permanent deletion |
| Ophiolite source observer | which source it was, the exact version seen, what was selected, who did it | who edited the source, the source’s own history, whether the science is right |
| Result from a source, saved to Ophiolite | the exact source version, checked for access, a fingerprint of the source, the checked result, the inputs the person named | proof it ran on the computer, what an outside algorithm did, changes written back to the source |
| Workspace editor | who did it, the exact source version, which draft was saved, where it was saved, how many values changed | the steps inside the source system, whether the science is right, one combined save across systems |
| Workspace updates | the version offered, deliveries the browser reported, the working version the server recorded, the saved edits | what other applications did with it, proof it was shown, changes written back to the source, updates while offline |
| LAS upload | who uploaded it, a fingerprint of the original file, the attribution the uploader declared, the distribution rights the uploader declared | a checked origin, a checked licence, scientific approval |
| Migration tool | a fingerprint of the package, where it came from, which record counts as the original, how many records moved | the history before the move, who handled each item |
A script or the command line (ophiolite get) | the exact version received, which of your access keys received it (you only; others see the application) | whether the data was used, what the application did with it next |
| ResInsight | which version was published | how the application calculated it, edits in between, step-by-step timing |
| File import | a fingerprint of the kept copy | who started it, who made the original, intermediate steps |
| Wells from files | who did it, which imports the wells came from, which wells and wellbores it covers, how many of them you can see | the well names, the person’s name at the time |
| A send tool | the exact versions delivered, which send tool and version, the name of the team’s system, whether it was sent, as reported, how many items | the address and settings of the team’s system, what the team’s system did with it next, proof of delivery beyond the report |
ResInsight and file import are described only: they do not report events yet. Delivery records older than the administrator’s retention period are removed; Activity then says so once.
Optional Jaeger diagnostics
Section titled “Optional Jaeger diagnostics”Your administrator can enable customer-controlled OpenTelemetry collection and Jaeger. On the operation’s card in Activity, Copy trace ID copies the 32-character diagnostic ID. Do not paste the longer durable operation ID into Jaeger’s trace search. Open in Jaeger appears when IT configures a reachable viewer URL. Its waterfall shows acquisition, worker calculation and publication spans. Separate delivery traces link back to the producing operation; heartbeats do not create duplicate traces. This helps diagnose delays. Trace sampling, export failures and retention may remove diagnostics; they must not remove durable operation history.
There is no automatic vendor analytics destination. Customers control diagnostic endpoints, access and retention. The diagnostic backend has its own permissions; Workspace project access does not automatically secure a separately deployed Jaeger UI or SQL database.
Recovery and export
Section titled “Recovery and export”An unconfirmed publication needs reconciliation. Retry the same command ID through its originating caller; do not assume the operation failed and repeat it as a new command. The native commit and local completion journal are separate transactions. Layer-reporting failures retry independently and do not block map updates. Check the QGIS dock’s observation status.
A customer-run export can write JSONL or PostgreSQL with resumable checkpoints. Unavailable destinations, expired credentials and revoked access stop further export without advancing the checkpoint. Previously exported customer copies remain readable. Interactive API delegates last five minutes and depend on their browser session. Unattended exports can instead use a dedicated, project-scoped OIDC workload identity with renewable credentials; see the API reference.
Administrators can set delivery-observation retention independently of scientific history and Jaeger traces. An exporter encountering pruned observations stops and requires explicit acceptance of the retained history. It cannot recover deleted observations. Scientific operation records are not pruned by this setting.
Portable history is baseline functionality. Managed collection, fleet dashboards, alerts and extended retention may become commercial services. No licence gate on history export is implemented in this pilot.