Economic Operator
Role is scoped by purpose, mandate and data domain.
SOLUTIONREFERENCE SOLUTION
EU DPP Readiness
Turn product-group obligations into scoped profiles, data carriers, access rules, lifecycle controls and external-registry integration.
P04Architecture
Scoped pilotEntry point
BUSINESS PROBLEM
Frame the obligation before choosing implementation technology.
The solution is scoped around business outcomes and authoritative sources, not around a generic DPP database.
- Product-group or market obligations must be translated into implementable data, access and lifecycle rules.
- Multiple actors and external authorities create ambiguity about who can assert, update or restrict each fact.
- Integration failure and incomplete evidence can undermine the business outcome even when the happy path works.
TARGET OUTCOME
- Explicit authority and source mapping
- Versioned policy/profile and portal journey
- Evidence-backed acceptance criteria
ACTORS & AUTHORITY
The same actor may be authoritative for one fact and only a consumer for another.
Authority is assigned by data domain and applicable context.
DPP/Product Owner
Role is scoped by purpose, mandate and data domain.
Registry/Authority
Role is scoped by purpose, mandate and data domain.
Integrator
Role is scoped by purpose, mandate and data domain.
JOURNEY
Trace the request to an auditable result.
The journey preserves policy and evidence context from request through external authority interaction.
Thing / Product
Official Identifier
Trusted ThingIDResolver · Alias · Assurance
DPP
Claims · Policy · Evidence
External ecosystem
Event
+Authorized actor
+Precondition
+Evidence
+Trusted time
+Policy / profile version
=Resulting state
TRUSTED THINGID APPROACH
Compose only the capabilities needed for this outcome.
Optional device, ledger or credential mechanisms are not inserted unless the use case justifies them.
Thing Identity & Resolver
REFERENCE IMPLEMENTATIONResolve official identifiers, correlate aliases and extend assurance without redefining the authoritative product identifier.
Explore
DPP Regulatory Engine
PILOT READYApply versioned product-group profiles, authoring controls and registry orchestration while keeping external legal authorities authoritative.
Explore
Policy, Mandate & Disclosure
REFERENCE ARCHITECTURESeparate authentication, authorization and field-level disclosure through PAP/PIP/PDP/PEP policy semantics.
Explore
Evidence & Provenance
PILOT READYBind business events and claims to source evidence, provenance, trusted time, immutable audit and retention policy.
Explore
Connector & Integration Platform
PILOT READYUse domain-specific adapters over shared API, event, workflow, semantic mapping, retry and reconciliation capabilities.
Explore
PILOT SCOPE
A pilot must define what success means.
Suggested acceptance criteria are evidence-oriented and should be adapted to the exact product group and external interfaces.
| Area | Pilot scope | Acceptance evidence |
|---|---|---|
| Applicability | One product group / regulatory profile | Approved applicability record + source references |
| Identity | Official identifier + resolver mapping | Resolution/collision/supersession tests |
| Portal journey | Primary actor flow + restricted view | Task completion + disclosure audit |
| Integration | One authoritative/external connector | Happy-path + timeout/retry/reconciliation evidence |
| Evidence | Material transition and retention | Evidence manifest + provenance + timestamp/version |
ARCHITECTURE WORKSHOP
Define a project-specific pilot boundary.
The architecture is reusable; applicability, interfaces, evidence and acceptance criteria must be confirmed for the target deployment.