Institutional
Institutional access for enrolled authorities, public bodies and high-trust organizations operating under defined governance and authority controls.
One function. Explicit trust boundaries.
Access models separate public verification from higher-volume, professional, enterprise and institutional capabilities.
Every material state transition should remain attributable to an authenticated actor, an authority context, a timestamp and the evidence required to reconstruct what happened.
Institutional lifecycle.
Select user class
Assess volume & controls
Choose plan
Complete enrollment
Activate permitted capabilities
Minimum verification context.
The exact schema can vary by object class and policy version, but the verification layer should be able to resolve these core dimensions.
- Identifier
- Type
- Status
- Authority
- Evidence
- Timestamp
- Relations
- History
Designed for progressive activation.
Production status must always be sourced from the deployed service and published through System Status; this static package does not claim backend activation.
Plan architecture
Final fees, event allowances, SLAs and institutional conditions should be published only after commercial approval. The structure below defines product segmentation without presenting unapproved prices.
| Plan | Primary use | Scale | Access model |
|---|---|---|---|
| Free | Public discovery & basic verification | Low / fair-use | Self-service |
| Individual | Personal identity, records & verification | Personal | Account |
| Professional | Case and evidence workflows | Professional volume | Enhanced |
| Business | Teams, records, API and controls | Organization | Business controls |
| Enterprise | Scale, integration, governance, SLA | High volume | Contracted |
| Institutional | Authority & institutional workflows | Institutional | Governed enrollment |