Synthetic playground
Designed, not deployed
- ●Representative roles
- ●Fictional or synthetic data
- ●Simulated requests
- ●Simulated approvals
- ●Simulated receipts
- ●No live system access
KATLAS Operating Model · Roles, wallets and receipts
See how KATLAS roles, wallets, evidence sources, authority boundaries and receipts turn an AI-enabled idea into a deployable operating model.
Starting point
Lab Pathway does not begin by connecting to live systems or ingesting private data.
It begins by designing the operating model: who participates, what evidence exists, who controls it, what AI may suggest, who may approve action, which systems may be touched, and what receipt proves the outcome.
Section 01 · Wallets as roles
A KATLAS wallet can represent a person, team, organisation, device, system, AI agent or external partner.
Each wallet can carry custody, authority and receipt responsibilities.
The wallet does not require raw private data to be centralised. It governs what can be requested, shared, withheld, approved or evidenced.
The role controls the boundary. The receipt proves the action.
Section 02 · Synthetic first, live later
The playground designs the roles. KATLAS operationalises them once governance, evidence boundaries and authority gates are approved.
Synthetic playground
Live KATLAS R2R workflow
The playground designs the roles. KATLAS operationalises them.
Section 03 · Source registration
Legacy and new systems are first registered as evidence sources. This does not require data ingestion.
Evidence remains at source. KATLAS governs what can be requested, summarised, withheld or approved.
Each source is described by
Example sources
Live integrations are configured only where explicitly approved. The playground does not require API keys, credentials or production access.
Section 04 · CAR matrix
Each role's row makes its custody, authority and receipt responsibilities explicit. The matrix below shows three representative roles.
| Role | Custody | Authority | Receipts |
|---|---|---|---|
| Sponsor | Sponsor brief and budget boundary | Approve lab scope and next-stage funding route | Sponsor pathway brief · approval receipt |
| API owner | API documentation and access rules | Approve or refuse connection | Integration approval · refusal receipt |
| AI assistant | None | Advisory only | Model route · recommendation boundary |
Section 05 · Skills and capabilities
The operating model is delivered through a small mix of business, technical, governance and academic roles. Each row maps a capability to the kind of contributor who typically owns it.
Section 06 · Tools and artefacts
A small set of buyer-friendly artefacts that capture roles, sources, boundaries, routing and receipts — ready to take into a budget, security or deployment review.
Section 07 · Technical view
The operating model can be expressed through structured configuration and APIs: role definitions, source records, permissions, request states, approval events and receipt payloads.
This makes the governance model explainable to product owners, architects, API developers, DevOps teams and security reviewers.
Pseudo objects · no real secrets · illustrative only
Role object
{
"role": "API owner",
"custody": ["API documentation", "access policy"],
"authority": ["approve_connection", "refuse_connection"],
"receipts": ["integration_approval", "integration_refusal"]
}Source object
{
"source": "CRM",
"owner_role": "Customer data owner",
"sensitivity": "confidential",
"permitted_use": "summary only",
"ai_boundary": "no raw customer records",
"authority_gate": "data_owner_approval_required"
}Receipt object
{
"event": "integration_request_reviewed",
"actor_role": "API owner",
"decision": "approved_for_synthetic_pilot",
"evidence_shared": ["API schema summary"],
"evidence_withheld": ["production credentials", "customer data"],
"verification_state": "simulated"
}Illustrative pseudo-objects · API keys, credentials and live integrations are not required for the playground · Live KATLAS R2R workflows are configured only once governance, evidence boundaries and authority gates are explicitly approved.
Continue