PRODUCT EXPERIENCEREFERENCE UI

Economic Operator Portal

Author, validate, approve, publish, register and maintain product-group-specific DPP records with evidence and separation of duties.

Manufacturers, importers, authorised representatives and distributorsPrimary 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.

IDENTITYVerified representative
ORGANISATIONEconomic Operator identity
ASSURANCEEnterprise authentication with step-up where policy requires
MANDATERepresentative mandate / responsibility
THINGProduct / DPP under operator responsibility
ACTIONAuthor · validate · approve · register · publish · maintain
AUTHORITYExternal DPP Registry remains authoritative for registry-domain status
EVIDENCEValidation, approval, publication and registry evidence
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

Manufacturers, importers, authorised representatives and distributors

Author, validate, approve, publish, register and maintain product-group-specific DPP records with evidence and separation of duties.

CORE JOBS
  • Organisation onboarding assistance
  • Product / DPP workspace
  • Profile applicability
  • Author / validate / approve
  • Publish / register
  • Lifecycle correction / supersession
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.

Portal-related trust claims
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 Economic Operator Portal 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.

PERSONAManufacturers, importers, authorised representatives and distributors
BUSINESS OUTCOME / FLOWOnboard → register product → author → validate → approve → submit/register → reconcile → publish → maintain
BUSINESS OBJECTProduct master, DPP, regulatory profile, evidence, lifecycle state
POLICY / DISCLOSUREOrganisation role, mandate, product-group profile, publication policy
EVIDENCEValidation/approval/submission/publication/reconciliation evidence
API / EVENTDPP / Lifecycle / Evidence / Connector APIs
ARCHITECTUREP02 · P03 · P04 · P06
MATURITYPILOT READY
AUTHORITY BOUNDARYFacts remain authoritative only in their source domain. The Experience may display or orchestrate them without becoming the system of record.
ACTUAL UI*_final.png is embedded only when the approved source binary and provenance are available. The build must not fabricate a screenshot to fill a missing source.

Economic Operator Portal

Screen → Action → Business Object → Authority → Policy → State Transition → Evidence → API/Event/Connector → Architecture.

REFERENCE PRODUCT UIPILOT READYPROVENANCE-GOVERNED