3  Enterprise Use Cases

EventChain is the substrate for lifecycle evidence that spans organisational boundaries. The three use cases below show how signed, hash-linked entries replace fragmented document trails, slow attestation workflows, and platform-bound passports. Helios is the application layer that operationalises these capabilities; it is named where the boundary matters and otherwise stays out of the way.

3.1 Lifecycle Evidence for Engineered Assets

Compressor packages, separator skids, and subsea manifolds take years and tens of millions to build and operate for two to four decades. No single organisation touches a piece of equipment from raw material to decommissioning, and no single system of record covers that span.

The evidence burden across that lifetime is structural. API 510 (pressure vessel inspection), API 570 (piping inspection), API 580 (risk-based inspection), ASME B31 (pressure piping), the EU Pressure Equipment Directive, and NORSOK standards for the Norwegian shelf each require documented, traceable records across the full operating life. When a regulator, operator, insurer, or acquirer asks for the history of a compressor package twenty years after fabrication, the answer must be auditable, not assembled from memory.

Four artefact types carry most of that burden: material certificates, NDE clearances, MRB decisions, and custody transfers. EventChain gives each a signed, hash-linked entry when it is created. Any authorised holder verifies sequence and integrity offline, decades later, even after the original fabricator, platform, or supplier relationship has disappeared.

sequenceDiagram
    participant O as Owner
    participant S as Supplier
    participant I as Inspector
    participant L as Logistics

    rect rgb(240, 248, 255)
    Note right of O: Documents
    O->>S: Requirement issued (a3f2…)
    S->>O: Supplier response (7b1c…)
    S->>I: Material certificate (e9d4…)
    end

    rect rgb(255, 248, 240)
    Note right of I: Comments & Decisions
    I->>S: Inspection objection (41ae…)
    S->>I: Correction submitted (c0f7…)
    I->>I: MRB disposition approved (82b3…)
    end

    rect rgb(240, 255, 240)
    Note right of S: Handoffs
    S->>L: Dispatch confirmed (d5e1…)
    L->>O: Delivery receipt (f6a9…)
    end

    Note over O,L: All event types share one hash-linked sequence
Figure 3.1: Engineered-asset lifecycle — one hash-linked sequence verified offline by any authorised holder

Those are the steady-state conditions. The test is when something goes wrong.

When a defect, pressure exceedance, contamination event, or safety incident occurs, investigators need the record and its evolution: what happened, what changed, who commented, who approved, who objected, and who held responsibility at each point.

Without a shared proof trail, investigations begin with competing narratives. Healthcare safety research shows that punitive responses suppress reporting and make systems less safe (Eng and Schweikart 2017). Industrial supply chains face the same pattern: if every incident produces blame before facts, participants gain incentives to obscure involvement.

Multi-signature handoffs preserve custody boundaries. When responsibility moves from fabricator to logistics provider, or from logistics provider to operator, both parties sign the transfer event. The handoff becomes a sealed moment instead of a later argument about condition, timing, or possession.

sequenceDiagram
    participant Fab as Fabricator
    participant NDE as NDE Lab
    participant L as Logistics
    participant Op as Operator
    participant Inv as Investigator

    Note over Fab,Op: Normal flow: signed and hash-linked events
    Fab->>NDE: Weld complete -> NDE request
    NDE->>Fab: NDE clearance
    Fab->>L: Dual-signed custody transfer
    L->>Op: Dual-signed custody transfer
    Op->>Op: Installation sign-off

    Note over Op,Inv: 18 months later: failure detected
    Inv->>Op: Request event record
    Op-->>Inv: Role-authorised event file
    Inv->>Inv: Verify chain offline
    Inv->>Inv: Identify relevant clearance and signer
Figure 3.2: Adverse event investigation — the hash chain enables walkback through custody transfers to identify the point of failure

A tamper-evident record attributed to registered identities makes cover-up harder and honest reporting easier. The record cannot create a just culture by itself, but it gives such a culture the factual base it needs.

3.2 Headless Signers: Renewable Energy Credits

A photovoltaic asset produces electricity at the speed of physics. A revenue-grade meter registers each megawatt-hour continuously, in real time. One MWh of generation equals one renewable energy certificate — the quantum is fixed, the measurement is unambiguous, and the event is over in seconds.

Getting credit for it takes weeks. The dominant attestation schemes — I-REC, M-RETS, GATS, and Green-e — each depend on periodic reporting, third-party audit, and platform-mediated issuance. Issuance, transfer, and retirement happen in separate systems. Double-counting risk persists because no single record connects generation to certificate to retirement.

Production is measurable instantly, but the proof that justifies a certificate is slow, platform-bound, and expensive to audit.

EventChain narrows the gap by giving the meter its own identity in the chain. A hardware-bound signing key — a TPM, PUF, or secure element — signs each MWh reading directly into the append-only file. The resulting entry is cryptographically identical to a human-signed entry: same hash chain, same signature format, same offline verification.1

Three consequences follow. Auditors verify rather than reconstruct — the signed generation record is the audit trail, not an input to one. Issuance latency collapses from weeks toward near real-time because the proof of generation exists the moment the meter signs it. Double-counting risk drops because issuance, transfer, and retirement share the same chain as generation, closing the gap between physical event and certificate lifecycle.2

Headless signers do not make physical measurement self-validating. They make the origin of the measurement attributable and continuous with the rest of the lifecycle record. Calibration, tamper evidence, attachment checks, and contract rules remain part of the operating model.

sequenceDiagram
    participant M as Meter (TPM)
    participant AOF as Append-Only File
    participant R as Registry
    participant OT as Off-taker
    participant RC as Retirement

    M->>AOF: 1 MWh reading (signed, a1b2…)
    M->>AOF: 1 MWh reading (signed, c3d4…)
    R->>AOF: REC issued (e5f6…)
    OT->>AOF: Transfer accepted (g7h8…)
    RC->>AOF: Retirement confirmed (i9j0…)

    Note over M,RC: Generation, issuance, transfer, and retirement — one chain
Figure 3.3: REC lifecycle — meter, registry, off-taker, and retirement share one hash-linked chain

3.3 Digital Product Passports at Substrate Cost

Long-lived high-value assets already carry decades of required documentation. Keeping that record verifiable across acquisitions, divestments, and the manufacturer–operator boundary is expensive. The evidence must survive the original platform; the verification must not depend on the original custodian.

Current approaches expose a structural tension. Distributed-ledger designs strengthen integrity but introduce per-product costs and operational requirements that strain low-value goods and smaller businesses (Illán García et al. 2024). Centralised platforms reduce cost but keep verification dependent on the platform operator (Voulgaridis et al. 2024). EventChain separates proof from presentation: the integrity layer is substrate-cheap — storage is per-holder, verification is offline — without surrendering auditability.

A signed, hash-linked record sits beneath any presentation layer. Role-based access control determines what each stakeholder sees — full lifecycle evidence for regulators, material composition for recyclers, repair history for consumers, incident history for insurers — while the underlying chain remains verifiable regardless of which view is exposed.

The same substrate that satisfies today’s API and PED documentation requirements will satisfy tomorrow’s obligations without architectural change. The European Union’s Ecodesign for Sustainable Products Regulation requires lifecycle data for different stakeholders under different access rights (European Parliament and Council 2024). The table below maps its requirements to EventChain’s architecture.

Table 3.1: ESPR Digital Product Passport requirements mapped to EventChain
Req Requirement EventChain Approach
R-01 Product identifiers Uses existing product, batch, or serial identifiers as the index into event history
R-02 Granularity Supports product, model, batch, or item-level records according to the delegated act
R-03 Lifecycle storage Distributes verifiable copies to authorised holders across the lifecycle
R-04 Availability beyond manufacturer existence Keeps proof with authorised holders instead of a single manufacturer-controlled system
R-05 Controlled update Requires authorised, identity-bound signatures for lifecycle events
R-06 Role-based access Separates visibility policy from cryptographic integrity
R-07 Data integrity Combines hash chaining, passkey signatures, and public time anchoring
R-08 Fraud avoidance Makes fabricated passports detectable through broken hashes, missing signatures, or invalid anchors
R-09 Low verification burden Uses existing storage and lightweight verification rather than per-product ledger operations
flowchart TD
    A[Product Event] --> B[Signed + hash-linked entry]
    B --> C[Distributed proof artifact]
    C --> D{Role-Based Access}
    D -->|Regulator| E[Full lifecycle data + verification]
    D -->|Recycler| F[Material composition + disassembly]
    D -->|Consumer| G[Origin, claims, repair history]
    D -->|Insurer| H[Maintenance + incident history]
    B --> I[OTS daily anchor]
    I --> J[Public temporal proof]
Figure 3.4: One signed record, role-based views — regulator, recycler, consumer, insurer each see the slice they need

Proof and presentation are separated. Any authorised party keeps, shares, and verifies the record independently — without depending on the platform that issued it, the manufacturer that created it, or the operator that holds it today.


  1. The binding model uses three layers: a TPM, PUF, or secure element proves the sensor; a physical identifier proves the asset; a commissioning CBC (Section 6.6) binds sensor to asset. Periodic cryptographic challenges can provide continued-attachment evidence.↩︎

  2. The full failure-mode taxonomy appears in Table 4.2.↩︎