Plans & Pricing
Choose an access model aligned with individual, professional, enterprise or institutional use. Commercial terms can scale by verified events, users, integration scope and assurance level.
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.
Pricing functions.
The domain is separated into explicit functions so status, authority, evidence and lifecycle transitions can be inspected independently.
Plans
Access models separate public verification from higher-volume, professional, enterprise and institutional capabilities.
Explore →02Free
Public and entry-level access for discovery and basic verification, subject to fair-use and service policy.
Explore →03Individual
Capabilities for individuals managing their own identity, records, evidence and verification activity.
Explore →04Professional
Professional workflows for qualified users who require higher-volume case, evidence and verification capabilities.
Explore →05Business
Operational capabilities for organizations managing teams, records, integrations and verification workflows.
Explore →06Enterprise
Higher-scale integration, governance, SLA and control requirements for complex organizations.
Explore →07Institutional
Institutional access for enrolled authorities, public bodies and high-trust organizations operating under defined governance and authority controls.
Explore →Pricing 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 |