Lineage, audit, telemetry and analytics
Scalar-operation and OAuth QGIS delivery diagnostics are qualified in a private pilot. Broader instrumentation and product controls remain proposed. Scientific history and diagnostics have different purposes and retention requirements.
| Stream | Purpose | Contract |
|---|---|---|
| Scientific lineage | Explain exact inputs, operations and results | Durable, unsampled customer project records; authorized reading and export |
| Security audit | Record access, changes, exports and authorization | Restricted stream with governed access and retention |
| Operational telemetry | Diagnose slow jobs, failed connections and stale data | Customer-controlled diagnostic destination; bounded retention and sampling |
| Product analytics | Understand workflow completion, failure and reuse | Customer dashboards first; separate opt-in for minimized vendor sharing |
Customer-controlled diagnostics
Section titled “Customer-controlled diagnostics”Implemented optional traces cover scalar acquisition, worker calculation, publication and linked QGIS delivery-report recording. OSDU requests, general metrics/logs and arbitrary host actions are not covered. Broader instrumentation remains proposed. A customer-controlled collector exports to a chosen OpenTelemetry Protocol (OTLP) endpoint. This diagnostic destination is independent of scientific data destinations.
Useful measurements include publication latency, stale-asset age, queue delay, operator duration, reconciliation recovery, failure classes and resource cost. Bound metric labels: do not use unlimited asset or user identifiers as metric dimensions. Redact sensitive content and limit retention.
Trace identifiers can connect diagnostics to a run, but sampled traces cannot be the authority for scientific lineage.
Proposed visible controls
Section titled “Proposed visible controls”History / Derived from explains inputs, operations and outputs. Data and diagnostics shows the purpose, fields, destination, retention and sharing state of each stream. Local inspection/download, optional diagnostic controls and a customer endpoint make those decisions visible.
Optional sharing with us requires explicit administrator opt-in. Turning it off must produce no vendor-bound analytics traffic, proven by executed tests. Essential provenance remains part of saving scientific work even when analytics is disabled.
Default vendor events exclude payloads, well names, coordinates, paths, free text, prompts, secrets and raw identifiers. Use allowlisted, versioned event schemas and bounded aggregation windows. Hashing an identifier alone does not make it anonymous.
Customers inspect and redact a support bundle before choosing to send it. Training permission is separate from diagnostic or analytics permission. Covert session capture and employee productivity ranking are outside this direction.
Delivery and commercial boundaries
Section titled “Delivery and commercial boundaries”M1 defines durable lineage and independent reproduction. M3 adds History/Derived from and manual-edit provenance. M4 qualifies diagnostics, redaction, customer destinations, access-controlled audit and sharing-off behavior. Impact analysis and advanced customer workflow dashboards follow later evidence and demand.
Useful paid tools may include impact graphs, approved workflows, audit integrations, cost analysis and managed operation. Underlying customer history stays readable and exportable; baseline security and essential lineage remain baseline requirements. Packaging and pricing are not decided.