PRODUCT EXPERIENCEREFERENCE UI
Repair / Maintainer App
Inspect product context, access authorised fields, record repair evidence and submit lifecycle events without becoming the legal DPP authority.
Repairers, maintainers, refurbishers and recyclersPrimary
persona
P02/P04Architecture
Reference UIService readiness
ACTOR TRUST CONTEXT
Who is acting, under whose authority, on which thing and with what evidence?
The portal is an experience surface on top of the shared trust service.
Access rule: Public/low-risk reads do not require identity by
default; privileged, restricted or state-changing operations require policy-qualified actor context.
PERSONA & JOBS TO BE DONE
The surface exists to complete governed business work.
Tasks are tied to purpose, authority and evidence rather than generic dashboard features.
PRIMARY PERSONA
Repairers, maintainers, refurbishers and recyclers
Inspect product context, access authorised fields, record repair evidence and submit lifecycle events without becoming the legal DPP authority.
CORE JOBS
- Identify thing
- Repair scope
- Parts / materials
- Evidence capture
- Lifecycle event
- Restricted field access
PORTAL WORKFLOW
From job to state and evidence.
Select a phase to continue to the actual product-reference screens below.
ACTUAL PRODUCT UI
Approved product-reference UI
CORE WORKFLOW
Every privileged action carries context.
The portal passes request/context into policy and domain services; it does not write directly to authoritative stores.
01Request / context
02Authentication
03Mandate / purpose
04Policy decision
05Field-level view
06Business action
07Evidence / audit
ROLE, MANDATE & DISCLOSURE
Access is not a single role check.
Persona, purpose, mandate, assurance, lawful basis, jurisdiction and data classification may all influence the decision.
01REQUESTIdentity · Resource ·
Purpose
02PIP CONTEXTRole · Mandate ·
Attributes
03PDP DECISIONPolicy · Lawful basis ·
Risk
04PEP ENFORCEMENTAllow · Deny · Mask
· Constrain
05COMPOSED VIEWPermitted fields
only
CLAIMS & EVIDENCE
The screen can display a fact without becoming its authority.
User actions map to evidence, claims and state transitions with source/owner/limitation context.
| Claim | Statement | Status | Evidence | Limitation |
|---|---|---|---|---|
| CLM-004 | Regulatory DPP responsibility is not equivalent to legal ownership. | REFERENCE ARCHITECTURE | EVD-ARCH-P03;EVD-ARCH-P04 | Applicable product-group law governs regulatory responsibility. |
| CLM-005 | Ownership is represented as an evidence-backed claim with provenance and dispute handling. | UI/UX BASELINE | EVD-ARCH-P03;EVD-UX-CONSUMER | Does not itself determine legal title in every jurisdiction. |
| CLM-006 | Custody/possession may differ from ownership and are maintained as separate relationships. | REFERENCE ARCHITECTURE | EVD-ARCH-P03 | Legal meaning remains jurisdiction/application dependent. |
| CLM-007 | Delegation/mandate has issue, activation, verification, revocation/expiry and evidence semantics. | REFERENCE ARCHITECTURE | EVD-ARCH-P02 | External mandate/credential sources may remain authoritative. |
| CLM-008 | Authentication, authorization and field disclosure are separate policy decisions. | REFERENCE ARCHITECTURE | EVD-ARCH-P02 | Exact IAM protocols depend on deployment. |
| CLM-009 | Persona, purpose, mandate, assurance, lawful basis, jurisdiction and data classification may influence disclosure decisions. | REFERENCE ARCHITECTURE | EVD-ARCH-P02 | Policy inputs vary by deployment and lawful basis. |
INTEGRATIONS & TRACEABILITY
Portal action → service → evidence → external boundary.
The page cross-links the portal to modules, APIs, evidence and canonical architecture.
Architecture mapping
P02/P04
Policy services
PIP · PDP · PEP · field disclosure
Evidence outputs
Decision log · provenance · correlation · lifecycle evidence
External systems
Only through governed connectors / external wallets
ARCHITECTURE WORKSHOP
Review Repair / Maintainer App against your workflow.
Use a workshop to map your actors, mandates, business objects, external systems and evidence requirements to the portal baseline.
PRODUCT EXPERIENCE CONTRACT
From screen to state, policy and evidence
This Experience is a governed business surface, not an isolated dashboard. Every privileged action crosses service, policy and evidence boundaries; the UI does not access repositories directly.
Field Operations App
Screen → Action → Business Object → Authority → Policy → State Transition → Evidence → API/Event/Connector → Architecture.
REFERENCE PRODUCT UIUI/UX
BASELINEPROVENANCE-GOVERNED