REFERENCE SCENARIOREFERENCE

RS-04 — repair-evidence

Repairer ghi lifecycle evidence

END-TO-END PATH

Actor → Channel → AuthN → AuthZ → Disclosure → Core/DPP → Evidence → Connector → External Authority.

Not every scenario traverses every optional capability; the path shows the governance checkpoints that must remain explainable.

Thing / Product

Official Identifier

Trusted ThingIDResolver · Alias · Assurance

DPP

Claims · Policy · Evidence

External ecosystem

MATERIAL TRANSITION

State changes require more than an event name.

Event

Authorized actor

Precondition

Evidence

Trusted time

Policy / profile version

Resulting state

ACCEPTANCE EVIDENCE

Define what makes this journey auditable.


Evidence area	Expected record
Identity / mandate	Actor/context and mandate evidence where applicable
Policy	Decision + policy/profile version
Business object	Subject identifier + authority context
Transition	Previous/resulting state + preconditions
Evidence	Source/provenance + trusted time
Integration	Correlation + delivery/reconciliation outcome

ACTUAL PRODUCT UI

Reference UI for this scenario

Field Operations App · Scan and Resolve Resolve Success

04_FIELD_OPERATIONS_APP.zip · TTID--M02-L01-002-Scan_and_Resolve_Resolve_Success_final.png

REFERENCE SCENARIO · IMPLEMENTATION-GRADE

RS-04 — Repair / maintenance event with governed evidence

This scenario connects a user action to state, authority, policy, evidence and integration boundaries. It is a reference model; legal or regulatory decisions remain with the authoritative party for each data domain.

Actors / systemsRepairer / maintainer; Field Operations App; owner/custodian where relevant; DPP lifecycle and evidence services.

PreconditionsThing is resolved; technician/organisation identity and authorisation are valid; repair policy determines writable fields/events.

TriggerA technician scans/resolves a thing and starts an inspection or repair work order.

End-to-end flowResolve → inspect → authorise technician/purpose → capture diagnosis and parts/material change → perform work → capture supporting evidence → issue repair/maintenance event → update composed lifecycle view.

State modelWork order Open → In Progress → Completed/Failed; lifecycle event recorded. Ownership/custody is not automatically changed by repair.

Authority boundaryRepairer is authoritative only for the repair facts it is authorised to attest; other product/regulatory domains retain their authorities.

Policy / disclosureTechnician credential, organisation role, purpose, mandate, product safety restrictions, write scope and evidence requirements.

EvidenceInspection evidence, replaced part references, technician credential reference, work completion record, timestamp and audit.

API / event / connectorResolver; lifecycle event API; evidence API; claims/credential verification; repair/circularity connector if present.

Failure / retry / reconciliation

Safety restriction → block work; missing technician entitlement → deny write; offline capture → queue signed evidence and reconcile without inventing external status.

Architecture

P02 · P03 · P04 · P05

Actor → Experience → Action → Business Object → Authority → Policy → State → Evidence → API/Connector → Architecture → Standard.

Standards / profiles

Applicable lifecycle/repair DPP profiles; evidence/time and credential standards as deployed.

REFERENCE ARCHITECTURE

Product UI statusUI/UX BASELINE — *_final.png is embedded only when the approved source binary and provenance are available; no screenshot is fabricated to fill a missing source.