Explore how an organisation establishes an Institution Profile, provisions bilateral Relationship Databox connections, and commits verified records with signed cryptographic receipts — simulated directly inside your browser.
Client-Side Sandbox Environment
This interactive simulator runs locally in your browser to demonstrate the Mapping Smithy workflow. In production deployments, these operations execute via the authenticated JSON control plane (/.databox/smithy) with fail-closed cryptographic verification, DPoP tokens, and WORM audit logging.
1. Define Program Profile (Institution Profile)
Before exchanging records, an organisation registers an Institution Profile defining the program's scope, allowed record classes, legal bases, purpose declarations, and retention policies.
Architectural role: The Program Profile establishes declarative constraints. The Databox enforces these rules on every subsequent deposit, rejecting any payload that falls outside the agreed civic or business purpose.
Registered Program
Purpose & Governance Basis
Primary Record Class
Status
2. Forge Bilateral Mapping
When a participant engages with the program, the Mapping Smithy creates an isolated, opaque relationship container. This generates a pair-wise identifier that never leaks internal customer IDs into public URLs.
The Relationship Databox boundary: Keeping each relationship isolated ensures that records from one service can never be correlated across other services without explicit participant consent.
Bilateral Relationship Container Provisioned
An opaque Relationship Databox has been provisioned with holder-bound credentials:
3. Commit Record & Issue Receipt
Deposit a verified institutional event. The gateway validates the payload against the profile, immutably commits exact bytes, and issues a tamper-evident cryptographic receipt.
Verifiable audit trail: The participant receives a signed receipt (ES256 JWS) proving the transaction occurred under declared ODRL terms, enabling independent verification without vendor lock-in.