Actors
Authenticated actor · PAP/PIP/PDP/PEP · Data-domain owner · Auditor
PLATFORM MODULEREFERENCE ARCHITECTURE
Policy, Mandate & Disclosure
Separate authentication, authorization and field-level disclosure through PAP/PIP/PDP/PEP policy semantics.
P02Architecture
REFERENCE ARCHITECTUREMaturity
Domain-qualifiedAuthority
SCOPE
What the module does—and what it deliberately does not do.
A clear negative boundary is part of the product definition.
DOES
- Purpose, mandate, assurance, lawful basis, jurisdiction, data classification and composed views.
- Publishes explicit domain objects and version-aware interfaces/events.
- Links business outcomes to evidence and architecture references.
DOES NOT
- Does not replace external legal/identifier authorities.
- Does not imply universal certification or conformity.
- Does not make optional assurance mechanisms mandatory for all products.
OPERATING MODEL
Actors, inputs, outputs and authority remain explicit.
The module is not treated as a black box; its authority and evidence responsibilities are visible.
Inputs
Identity/context, versioned business data, policy inputs and external-source references as applicable.
Outputs
Versioned decision/data/evidence artifacts with correlation and provenance.
Authority boundary
Qualified by data domain; external authority is not absorbed through integration.
POLICY & DISCLOSURE
From access request to permitted data.
Users do not need prior knowledge of PIP/PDP/PEP: context is collected, policy is evaluated, the decision is enforced and only permitted fields are returned.
Access request
Identity · Request source · Purpose
Collect context
PIP · Policy Information Point
Role · Mandate · Attributes
Policy decision
PDP · Policy Decision Point
Policy · Lawful basis · Risk
Enforce decision
PEP · Policy Enforcement Point
Allow · Deny · Mask · Constrain
Permitted data view
Composed View
Return only policy-permitted fields
Product nameAllow
ManufacturerAllow
Owner namePolicy-controlled
Personal addressMask
Raw device telemetryDeny
Authentication ≠ Authorization ≠ Field-level Disclosure.
BUSINESS OBJECTS
Semantic objects connect UI, API, repository and evidence.
The semantic registry prevents architecture vocabulary from drifting between portals and integration contracts.
| ID | Object | Authority | Repository role | API | Architecture |
|---|---|---|---|---|---|
| OBJ-017 | Mandate | Mandate issuer | Mandate Store | Mandate API | P02 |
| OBJ-024 | Trust Appraisal | PDP/policy authority | Decision log | Trust API | P05 |
| OBJ-029 | Policy | Policy owner | Policy Store | Policy API | P02 |
| OBJ-030 | Disclosure View | PDP/PEP from authoritative sources | Ephemeral/read model | View API | P02 |
POLICY & EVIDENCE
Material actions are policy-versioned and evidence-linked.
Where the module changes a material state, the transition grammar applies.
Event
+Authorized actor
+Precondition
+Evidence
+Trusted time
+Policy / profile version
=Resulting state
INTERFACES & EVENTS
Reference contracts are versioned and publication-gated.
The public API package is a reference contract; actual deployment availability must be confirmed by release/environment.
POST /v1/decisions
GET /v1/views/{identifier}RELEASE GATE
SELECTINTEGRATETESTAPPROVEOPERATE
Publish support only for the exact version/profile/environment that has supporting evidence.
STANDARDS & LIMITATIONS
Mapping is not certification.
Standards are shown with status and implementation wording so reference mapping is not mistaken for assessed conformity.
| Reference | Status | OJEU | Impact | Implementation |
|---|---|---|---|---|
| EU 2024/1781 | IN FORCE | N/A | DPP regulatory profile; lifecycle; authority boundaries | TRACKED |
| EU 2026/1736 | IN FORCE | OJEU PUBLISHED | Standards status and public wording | TRACKED |
| EN 18216:2026 | HARMONISED | OJEU CITED | Integration protocol mapping | MAPPED |
| EN 18219:2026 | HARMONISED | OJEU CITED | Identifier governance / resolver | MAPPED |
| EN 18220:2026 | HARMONISED | OJEU CITED | QR/NFC/data-carrier experience | MAPPED |
RELATED MODULES
Compose capabilities without collapsing responsibilities.
Related modules are linked explicitly rather than hidden behind one monolithic platform claim.
Thing Identity & Resolver
REFERENCE IMPLEMENTATIONResolve official identifiers, correlate aliases and extend assurance without redefining the authoritative product identifier.
Explore
Identifier Governance
REFERENCE ARCHITECTUREGovern namespace uniqueness, persistence, collision detection, supersession and the rule that identifiers are never silently reused.
Explore
DPP Regulatory Engine
PILOT READYApply versioned product-group profiles, authoring controls and registry orchestration while keeping external legal authorities authoritative.
Explore
PRODUCT COMPLETENESS
From module to business outcome.
Separate authentication, authorization, mandate, purpose and field-level disclosure so a successful login never implies unrestricted data access.
ARCHITECTURE WORKSHOP
Turn the architecture into a scoped pilot.
Align product-group applicability, authority boundaries, portal journeys, integration contracts and evidence before committing to production claims.