Operations / Admin Portal
Operate tenants, policies, connectors, evidence, certificates, lifecycle settings and operational controls with privileged audit.
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.
The surface exists to complete governed business work.
Tasks are tied to purpose, authority and evidence rather than generic dashboard features.
Platform operators and authorised tenant administrators
Operate tenants, policies, connectors, evidence, certificates, lifecycle settings and operational controls with privileged audit.
- Tenant operations
- Policy administration
- Connector operations
- Evidence & audit
- Certificate / trust settings
- SLA / resilience
From job to state and evidence.
Select a phase to continue to the actual product-reference screens below.
Approved product-reference UI
Every privileged action carries context.
The portal passes request/context into policy and domain services; it does not write directly to authoritative stores.
Access is not a single role check.
Persona, purpose, mandate, assurance, lawful basis, jurisdiction and data classification may all influence the decision.
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. |
Portal action → service → evidence → external boundary.
The page cross-links the portal to modules, APIs, evidence and canonical architecture.
Architecture mapping
P02/P06
Policy services
PIP · PDP · PEP · field disclosure
Evidence outputs
Decision log · provenance · correlation · lifecycle evidence
External systems
Only through governed connectors / external wallets
Review Operations / Admin Portal against your workflow.
Use a workshop to map your actors, mandates, business objects, external systems and evidence requirements to the portal baseline.
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.
Operations / Admin Portal
Screen → Action → Business Object → Authority → Policy → State Transition → Evidence → API/Event/Connector → Architecture.