Guiding questions — Provenance, traceability & observability#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Provenance, traceability & observability → Guiding questions — © iSHARE Foundation, used under the EUTwinLink Consortium Agreement (see Legal notices). The template's question text is carried over unchanged so this fork stays comparable to its upstream.

Everything between the LDT answer markers is the EUTwinLink instantiation — that is what partners fill in. Decisions already taken live on the block page: Provenance, traceability & observability.

Building block T3 · owner(s) iLabs + iSHARE · due 26 Sep 2026 · block status DRAFTED · see the Building-block register.

Answer provenance. Every answer below is tagged with where it comes from, because a governance scheme that cannot be traced is not a governance scheme:

Decided — already fixed by the Grant Agreement, the Consortium Agreement or a recorded decision elsewhere in this scheme. Change it only through the change procedure.

Proposed — a defensible default, derived from the iSHARE Trust Framework, the DSSC Blueprint and the decisions this scheme has already taken. Drafted for the owner to confirm, correct or reject at TIPS. It is not an agreed position until TIPS approves it.

Needs owner — cannot be answered without the named owner: a fact about their systems, their legal position or their commercial intent. The text states what is needed and why.

Open points across the whole scheme are collected in Open questions for partners.

1. Requirements & Use Cases#

Purpose: Capture regulatory and business needs for data lineage to support compliance and value-added services.

Which legal, contractual, or sectoral requirements exist for provenance and traceability?
Are there AI Act or other regulatory triggers that mandate detailed data lineage or traceability?
Are there business cases for using provenance data to add value (e.g., sustainability claims, quality certification)?

LDT answer DRAFTED · owner: iLabs + iSHARE · due 26 Sep 2026

Decided Requirements that mandate lineage in the LDT, each traceable to something already decided:

Grant and audit — evidence retained for five years per grant rules; PD2 interoperability assessments draw on the evidence pack.
AI Act — the agent stack and observer chatbot carry transparency duties and need logging for post-hoc audit; the agent profile commits to logging agent actions like any participant's.
GDPR (via PD1) — demonstrating lawful processing of LEZ and PED citizen data requires knowing who accessed what, under which policy.
Contractual — policy enforcement is only meaningful if a decision can be evidenced afterwards.

Proposed The business case is the strongest argument and is often treated as the weakest: the Marketplace of the EU LDT Toolbox turns twin outputs into claims with financial consequences. A CO₂ saving that earns a token is a sustainability claim, and a claim without provenance cannot be audited — which, as the marketplace profile notes, is a greenwashing exposure for every participant, not only for the one making the claim. Provenance is what makes the tokenisation service defensible at all.

Proposed The scheme's rule should therefore be explicit: where a figure is used as evidence, provenance is mandatory; where data is merely consumed, control-plane logging suffices.

2. Data Modelling#

Purpose: Adopt or extend existing provenance ontologies to flexibly represent traceability information.

Will existing ontologies (e.g., W3C PROV-O, PAV) be adopted and extended for sector needs?
Should provenance be modelled as “events” (e.g., CloudEvents) for flexibility?

LDT answer DRAFTED · owner: iLabs + iSHARE · due 26 Sep 2026

Decided Candidate standards named on the block page: W3C PROV-O for lineage and CloudEvents for event-modelled provenance.

Proposed Use both, for different layers, because they answer different questions:

CloudEvents for the control plane — catalogue publication, contract negotiation, transfer process, policy decisions, credential status changes. These are events, they are high-volume, and an event envelope is the natural shape.
PROV-O for derivation — how a published indicator was computed from which inputs, by which method, at which version. This is where the sustainability claims live, and PROV-O's entity/activity/agent model is what makes "this figure came from those readings via that method" expressible rather than merely asserted.

Extension for sector needs: the emission method reference (LCMM / ISO 23795-1) attaches to the PROV activity, so the method is part of the lineage rather than a footnote in a description.

Needs owner iLabs + iSHARE — the 🧩. The split above is a drafting position; the event list and the PROV profile are the actual deliverable and do not exist.

3. Storage & Management#

Purpose: Define storage, retention, encryption, and access policies for provenance data across participants.

Will provenance/traceability data be stored locally by participants, by certified 3rd parties, or in a hybrid model?
What are the retention, encryption, and access control policies?

LDT answer DRAFTED · owner: iLabs + iSHARE · due 26 Sep 2026

Proposed Hybrid, with the split following who can be compelled to produce the record. Participants hold their own operational logs; the scheme holds the control-plane record centrally at the registry and connector layer, because an audit that depends on every participant voluntarily producing its own logs is not an audit.

Layer	Held by	Why
Control-plane events (publication, negotiation, transfer, policy decisions)	registry / connector operators (iLabs)	must survive a participant's exit or refusal
Derivation / lineage for published indicators	the publishing participant, referenced from the description	they alone know the computation
Operational telemetry	each operator	not evidence, see section 4

Proposed Retention: five years as the upper anchor, applied to control-plane and enforcement evidence. The anchor is Pilot Grant Agreement article 12.1, which runs the confidentiality obligation for five years after final payment rather than five years from the record — so the clock starts later than this page previously implied, and the practical window is longer. Shorter for operational telemetry, which has no evidentiary value after an incident is closed. Gateway transaction records are a third class and are not covered by this period: PD4 v1.0 §3 keeps them under the GDPR's own limitation, which is why they carry no personal attributes. The block page records the split.

Encryption at rest and in transit throughout; access control on the audit trail itself is the part most often left open — a participant may read entries concerning its own data and its own actions; the WP4 lead and TIPS may read across participants for a defined investigation. Unrestricted cross-participant log access would make the audit trail a surveillance surface.

Needs owner iLabs: storage location and whether retention can actually be enforced per class.

4. Observability Scope#

Purpose: Clarify which processes and telemetry data should be observable for governance and monitoring purposes.

Which Control Plane activities (catalog publication, contract negotiation, transfer process) will be observable?
Will operational telemetry (uptime, performance) also be included under the same governance?

LDT answer DRAFTED · owner: iLabs + iSHARE · due 26 Sep 2026

Decided Control-plane activities to be observable, per the block page: catalogue publication, contract negotiation and transfer processes, logged by the connectors and registry. Added by this scheme's own logic: policy decisions (every decision leaves an entry) and credential and registry status changes, because those are what make a later decision explicable.

Decided Trust signals published from this data — conformance status, policy-check outcomes, incident statistics — feed the PD2 interoperability assessments and the observer views (T4.4 DataRights Run).

Proposed Operational telemetry (uptime, latency, throughput) should be collected and reported to TIPS monthly, but under a lighter governance regime than the audit trail. Conflating them is a mistake with two directions: evidentiary records get deleted on a metrics retention schedule, or metrics get kept for five years and encrypted for no reason. Different purpose, different retention, different access.

Proposed Publication boundary: aggregate trust signals may be public (they are the scheme's credibility); per-participant policy failures are visible to that participant and to the WP4 lead, not to other participants. A public list of who failed policy checks would be a reputational penalty the scheme never agreed to impose.

Decided Two of the three layers are fixed by PD4 §3. Participant-only: each participant can export the logs about its own transactions, and nothing else at transaction level. Aggregate: verification volumes, failure reasons, status-check latency and credential reuse per consuming party feed the T4.4 trust metrics, with citizen credentials counted in aggregate only and no personal attributes recorded at the gateway in the first place. (Source: PD4 v1.0 §3 — text as in PD4 v0.96, 29 Oct 2026.)

Needs owner iLabs + iSHARE: whether the aggregate layer is published openly or stays inside the consortium. PD4 fixes what is collected and who may see their own; it does not say who may see the totals, and that is the part a prospective participant judges the scheme by.

5. Trust & Third Parties#

Purpose: Designate certified observability providers while avoiding centralization and systemic risks.

Which organisations could act as certified observability service providers?
How will centralization risks be mitigated?

LDT answer DRAFTED · owner: iLabs + iSHARE · due 26 Sep 2026

Proposed Within the consortium, iLabs is the only realistic observability service provider for the control plane — it already operates the registry, trust registries and ITB-S. That is efficient and it is precisely the centralisation risk the template asks about: the party operating the infrastructure also holds the records of how it behaved.

Mitigations, none of them yet in force:

Exportability — audit records exportable in an open format, so the evidence is not hostage to the operator. This is the single most effective control and the cheapest.
Participant-side copies — each participant retains its own entries for decisions concerning it, giving an independent record to compare.
Open-source components — the iSHARE registry and issuer components are open source, so the function is transferable rather than proprietary.
TIPS oversight of the operator, with the neutrality rule from Intermediaries & operators.

Proposed Certified third-party observability providers are not justified at pilot scale and should be left as a post-M18 option rather than designed now.

Decided Exportability is committed: PD4 §3 states that each participant can export the logs about its own transactions. (Source: PD4 v1.0 §3 — text as in PD4 v0.96, 29 Oct 2026.)

Needs owner iLabs + iSHARE: the export format. The commitment is made, so the centralisation risk is no longer unmitigated in principle, but an export nobody can parse mitigates nothing in practice — name the format and whether it carries the policy decision and reason alongside the transaction.

6. Governance Linkages#

Purpose: Integrate provenance and traceability rules into the rulebook under governance oversight.\ Governance Linkages

How will rules for provenance and traceability be reflected in the rulebook?
Which governance body will approve changes to provenance and traceability standards or processes?

LDT answer DRAFTED · owner: iLabs + iSHARE · due 26 Sep 2026

Decided Provenance and traceability rules live in this block of the scheme, and bind through the accession agreement like any other scheme rule. The audit-trail obligation is one of the standard elements of every participant agreement (Contractual framework).

Decided TIPS approves changes to provenance and traceability standards and processes, as for any scheme change, with the WP4 lead preparing and iSHARE Foundation retaining authority over the iSHARE-owned parts (credential schemas, ODRL profile).

Proposed Two linkages worth stating explicitly in PD4, because they are where this block earns its place rather than being infrastructure trivia:

To enforcement — an enforcement regime without an audit trail cannot demonstrate that it enforced anything. The graduated sanction ladder in Regulatory compliance depends on evidence this block produces.
To the marketplace — conformance evidence and policy outcomes affect listing visibility and certified badges, so provenance is a commercial mechanism as well as an audit one.

Needs owner iSHARE + iLabs: the evidence-pack format for PD2 assessments, which the 🧩 asks for and which PD2 will need before this block is finished.