PLATFORM MODULEREFERENCE ARCHITECTURE

Policy, Mandate & Disclosure

Separate authentication, authorization and field-level disclosure through PAP/PIP/PDP/PEP policy semantics.

Review module scope Related architecture

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.

Actors

Authenticated actor · PAP/PIP/PDP/PEP · Data-domain owner · Auditor

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.

Policy, Mandate & Disclosure object mapping
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.

Relevant standards
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 IMPLEMENTATION

Resolve official identifiers, correlate aliases and extend assurance without redefining the authoritative product identifier.

Explore

Identifier Governance

REFERENCE ARCHITECTURE

Govern namespace uniqueness, persistence, collision detection, supersession and the rule that identifiers are never silently reused.

Explore

DPP Regulatory Engine

PILOT READY

Apply 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.

INPUTIdentifier / policy / evidence / source status

OUTPUTSource-aware, policy-qualified result with evidence context

AUTHORITYQualified by data domain; external authority remains external

API / EVENTAuthentication · claims context

EVIDENCEPolicy decision · mandate context · composed-view record

MATURITYReference architecture

Open Product Ecosystem View Readiness

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.

Request a workshop Explore architecture