Accumulating Linked Data

info

Please note that this specification is suitable for pre-production pilot implementations.

Overview

A passport, a facility record, or a company profile is a logical view of an identified thing, not necessarily one monolithic document. The same transparency graph can be assembled in either of two ways:

• At issue time, a publisher collects data and evidence and issues one larger credential, such as a Digital Product Passport or a Digital Facility Record.
• At verification time, a consumer starts with an identifier, uses an Identity Resolver to discover separate credentials and data objects, and assembles the logical view dynamically.

These approaches are complementary. They can coexist for the same identifier, and they do not change the meaning of the resulting graph.

This pattern is not specific to products. A product, a facility, and a business are each identified, and each accumulates statements from many parties over time.

The problem with treating a record as one document

Useful data is created by different actors, in different systems, at different times.

For a product:

• A brand or manufacturer holds master data.
• A factory records production and traceability events.
• A conformity assessment body issues an independent assessment.
• A service centre records a repair years after manufacture.
• A recycler records end-of-life processing.

For a facility:

• An operator publishes the site's location, activities, and capacity.
• An auditor issues a social or environmental audit against that site.
• A regulator records a permit, a licence condition, or an inspection outcome.
• The operator reports emissions or water use each year.

For a business:

• A business register holds the legal identity.
• A scheme owner records membership or accreditation.
• Counterparties accumulate their own assessments over years of trading.

Requiring one party to copy all of these statements into one credential creates unnecessary coordination. The publisher must retrieve every source, decide what to copy, and re-issue the record whenever anything changes. Copying a third party's assessment can also blur who made the original statement.

However, requiring every consumer to assemble a graph dynamically is not always appropriate either. A buyer may need a portable snapshot for a transaction, or a regulation may require one document containing a defined data set.

The choice is therefore when to aggregate, not whether aggregation is allowed.

One graph, two aggregation strategies

Suppose a product is described by:

• a product node;
• a claim about organic content;
• an assessment supporting that claim;
• the regulation or standard used for the assessment; and
• a repair event added after sale.

Each uniquely identified node can be the subject of a credential whose subject type is the corresponding UNTP data type. Alternatively, several of those nodes can be placed in one larger credential. Once the data is loaded, both representations produce the same linked-data graph.

Both routes end at the same logical graph, with the same semantics.

Issue-time aggregation

Issue-time aggregation is useful when:

• a transaction needs a portable, stable snapshot;
• one issuer is authoritative for the included statements;
• a regulation defines a single required document; or
• the receiver cannot resolve a graph at runtime.

The credential remains a point-in-time attestation by its issuer. Linked evidence can still be independently retrieved and verified.

Verification-time aggregation

Verification-time aggregation is useful when:

• data is maintained by multiple independent actors;
• information changes at different rates;
• lifecycle events continue after the original credential is issued;
• the consumer needs the latest discoverable view; or
• copying third-party statements would weaken provenance.

The consumer resolves the identifier, follows the typed links, verifies each credential, and assembles a transparency graph. A "passport" or "facility record" in the user experience can therefore be a runtime view over that graph rather than one credential.

Hybrid aggregation

Most implementations will be hybrid. An original DPP might aggregate product master data and manufacturing claims at issue time, while later repairs, assessments, and ownership changes remain separate credentials discovered at verification time. A Digital Facility Record works the same way: the operator publishes the site once, and each subsequent audit and annual emissions report is discovered against the same facility identifier.

The original credential does not need to be modified. New data becomes another graph node and another resolver link.

Credentials can be granular

UNTP credential types should not be read as requiring one credential to contain every possible node. Where a node is uniquely identified, it can be issued independently:

• a Product in a DPP;
• a Facility in a DFR;
• a Claim as the subject of a credential;
• a ConformityAssessment in a DCC;
• a LifecycleEvent in a DTE; or
• another defined node such as a regulation or a criterion.

The issuer chooses the credential boundary that matches its authority and business process. A verifier reconstructs relationships using identifiers, regardless of whether related nodes arrived in one credential or many.

Identity Resolver as the discovery layer

The Identity Resolver does not have to store or verify the graph. Its role is to make the graph discoverable:

1. A data carrier or register lookup yields an identifier.
2. The resolver returns typed links about that identifier.
3. The client retrieves and verifies the linked objects.
4. The client loads them into a graph and applies its own assessment rules.

An authorised actor can add a link without asking the original issuer to re-issue its credential. Access to create links must still be governed using the Decentralised Access Control patterns or equivalent resolver policy.

Example: post-manufacture lifecycle data

A battery manufacturer issues a DPP in 2026. A service centre repairs the battery in 2034.

The service centre does not modify or re-issue the manufacturer's DPP. It issues a repair event as a DTE and, when authorised, registers that event against the battery identifier. A later verifier discovers both the original DPP and the repair event and assembles the current logical view.

The same applies at end of life. A recycler that takes the battery apart issues its own events against the same identifier: an ObjectEvent ending the battery's identity with a recycled disposition, and a TransformationEvent producing the recovered materials. See battery_recycled and materials_recovered, and Modify for why end of life is two events rather than one.

Nothing in the manufacturer's 2026 passport changes. A reader resolving the battery identifier in 2034 finds the passport, the repair and the recycling, and assembles whichever view it needs.

Example: a facility assessed by many parties

A textile dyeing facility publishes a Digital Facility Record describing its location, processes, and effluent treatment. That record is the operator's own statement, and it changes rarely.

Everything else about the site is published by someone else. A social compliance auditor issues a DCC each year. An environmental regulator records a discharge permit. A chemical management scheme records certification. None of these parties can edit the operator's facility record, and the operator should not restate their findings as if they were its own.

Each party registers its credential against the facility identifier. A brand assessing that site resolves the identifier once and receives the operator's description alongside every independent assessment, each still carrying its original issuer. When next year's audit is issued, the brand sees it without anyone re-publishing the facility record.

This matters for products too. A Digital Product Passport that names the facility where a batch was made does not need to copy that site's audit history. It links to the facility identifier, and the verifier follows that link into the facility graph if they care.

Example: model and batch data at manufacture

The Textile Model and Batch Composition use case applies the same architecture at the point of manufacture, where a textile brand holds model data and its tier 1 supplier holds batch traceability and conformity data. Neither party can honestly issue a complete passport alone, so each publishes against the same identifier instead.

Implementation guidance

• Preserve issuer provenance: link to another actor's credential rather than copying its statement without attribution.
• Use stable, globally unique identifiers so nodes from separate credentials join correctly.
• Keep credentials immutable; publish a new credential when a point-in-time attestation changes.
• Use resolver version metadata where multiple credential versions remain discoverable.
• Do not assume that discovery establishes trust. Verify every credential before relying on it.
• Choose issue-time, verification-time, or hybrid aggregation according to the business need; all three are valid UNTP patterns.

Roadmap

• Document how archival of Identity Resolver operators can be handled. Informative patterns are now sketched in Durable Storage; a normative preservation profile is still outstanding.