Skip to content

Provenance, traceability & observability#

Part of the LDT Governance and Trust Framework — instantiates the iSHARE Data Space Template block Provenance, traceability & observability (© iSHARE Foundation, see Legal notices).

Purpose#

Track where data came from, how it was used and by whom — the evidence base for auditing, compliance and trust.

LDT instantiation — where we stand#

  • Trust signals & metrics (T4.4 DataRights Run): the LDT publishes operational trust signals — conformance status, policy-check outcomes, incident statistics — feeding the PD2 interoperability assessments and the observer views.
  • Audit logging: control-plane events (catalog publication, contract negotiation, transfer processes) are logged by the connectors/registry; retention and access rules to be fixed here.
  • DevSecOps assurance: continuous risk assessment integrated in the delivery pipeline (WP4 method), with evidence stored for reviews and audits (5-year retention per grant rules as the upper anchor).
  • Candidate standards: W3C PROV-O for lineage; CloudEvents for event-modelled provenance.

Observability (PD4 §3)#

The gateway records each transaction (time, relying-party identifier, credential type, policy decision and reason) without personal attributes. Aggregate metrics — verification volumes, failure reasons, status-check latency, credential reuse per consuming party — feed the T4.4 trust metrics. Citizen credentials are counted in aggregate only. Retention follows the GDPR, and each participant can export the logs about its own transactions.

Source: PD4 v1.0 §3 — text as in PD4 v0.96 (29 Oct 2026).

Two retention rules, two log classes. The GDPR rule above governs the gateway transaction records: they are kept no longer than the purpose requires, which is why the gateway records no personal attributes in the first place. The five-year rule in the guiding questions below is a different class — grant and audit evidence, control-plane events and enforcement proof — where the grant rules set the period and the legal basis. Neither overrides the other, and no record is held under both.

🧩 Building block requested — Owner: iLabs + iSHARE#

What we need: the observability specification: which control-plane events are logged where, retention/encryption/access rules, which trust signals are published to whom (public vs participants), and the evidence pack format for PD2 assessments.

Format: Markdown section in this page (merge request) · Due: 26 Sep 2026 (v0.5) · Status: OPEN

Guiding questions#

All 13 of the template's questions for this block, with the 6 LDT answer slots to fill, are on provenance-traceability-observability/guiding-questions.md. The digest below is the subset that most shapes this block.

  • Which legal, contractual or AI-Act triggers mandate lineage/traceability, and is there business value in provenance (e.g. sustainability claims)?
  • PROV-O/PAV reuse, or event-based modelling (CloudEvents)?
  • Local, third-party or hybrid storage; what retention, encryption and access policies apply?
  • Which body approves changes to provenance rules?

PD4 mapping#

Feeds PD4 v1.0 §3 — Operating conditions (observability) and §6 (trust-assurance capabilities).