The app runs the workflow.
KATLAS attests the governed action.
This page is separate from the customer walkthrough. It is for technical and governance reviewers who need to see clearly what the application is doing, what AI is doing, and what KATLAS is doing — and what changes the moment a live node is connected.
“AI suggests. Wallets prove. KATLAS governs. Officers approve. The platform keeps the receipt.”
Why this matters. Do not read this POC as a scripted workflow with a decorative hash.
ClubCierge is connected to the live KATLAS node/API. When an authorised action is approved, KATLAS signs a receipt showing who approved what, when, what evidence was shared, and what was withheld.
The visible workflow remains a demonstration environment, but the governance pattern is live: custody is represented through controlled profiles, authority is enforced through role and policy gates, and receipts are signed through the KATLAS node.
What the ClubCierge app does
ClubCierge shows how an existing club website can be enhanced with AI-assisted workflows, member-controlled profiles, bounded permissions, human approvals and evidence-backed receipts.
- Marcus Reid driver profile — performance, media, funding, sponsor readiness
- Pole Position sponsor profile — verified credentials, aims, terms
- Introduction Review Inbox — proposed matches with AI alignment
- Eligible support & kit — bounded shop/supplier offers with parent + officer gates
- Receipts — what was checked, shared, withheld, approved
What AI does and does not do
AI helps structure information, suggest alignment and flag missing evidence. It does not approve introductions, override permissions, access private wallet contents or make safeguarding-sensitive decisions.
- Suggest alignment between a driver and a sponsor
- Structure messy evidence into a comparable view
- Flag missing or weak items
- Explain why an offer might fit a driver's profile
- Approve introductions or claims
- Override parent / officer gates
- Access private wallet contents
- Make safeguarding-sensitive decisions
What KATLAS does
KATLAS governs the operational step. It checks the role and permission context, records what was approved, what was shared, what was withheld, and creates or receives a receipt / attestation for the action.
- Action type — sponsor introduction approved, offer claim approved, mitigation accepted
- Approving role — Club Secretary, Parent / Guardian, Safeguarding Lead, Maintenance Lead
- Policy gate result — passed, blocked, approval required
- Permission state — what was shared, what was withheld
- Evidence references — which records were relied on (not the records themselves)
- Timestamp and receipt reference
- Node signature / attestation id where available
- · Full date of birth · Family notes · Safeguarding records · Private contact details
- · Withheld media assets · Unapproved documents · Payment details · Unrestricted AI prompt context
Simulation today, live node in production
This demo currently shows the KATLAS governance step as a live node attestation so the use case is self-contained. KATLAS can also be connected as a live node / API. In live mode, the ClubCierge backend sends a minimal governance payload to the KATLAS node, the node attests the action, and the receipt shows a node attestation id.
- KATLAS governance simulation
- Local policy gate
- Local receipt hash
- Visible operating model
- KATLAS node active
- Node receives minimal governance payload
- Node returns attestation id / hash / timestamp
- Receipt shows node attestation
- Raw private data and withheld assets are not sent
KATLAS_MODE=live, KATLAS_NODE_URL=…). The header chip on every page reflects the current state in real time (node active). The KATLAS node/API integration pattern has been wired against a separate node-api-setup reference deployment; when a real attestation endpoint is provisioned on that node, ClubCierge receipts automatically carry a live attestation id with no further code changes.Why this is not just orchestration
A normal workflow app routes tasks. KATLAS-connected workflows attest them.
- Routes tasks
- Stores data centrally
- Relies on users to trust records
- May let AI see too much context
- Weak evidence of who authorised what
- Shows AI-assisted workflow
- Simulates KATLAS governance for demo clarity
- Shows shared / withheld data
- Produces local receipts
- Demonstrates the user experience
- Role / wallet-backed authority
- Live node attestation
- Minimal governance payload
- No raw private data or withheld assets sent to node
- Receipt proves who approved what, under what role, and what was shared or withheld
Evidence visibility matrix
Who controls each piece of evidence, who can see it, what reaches the KATLAS node, and what appears on the public share view. KATLAS records the governed action — not a copy of everyone's private data.
| Evidence / fact | Controlled by | Visible to sponsor | Visible to Club Secretary | Sent to KATLAS node | Public share |
|---|---|---|---|---|---|
| Driver profile ref | Marcus wallet / club role | Yes | Yes | Ref only | Yes |
| Lap-time summary | Marcus wallet | If approved | Yes | Hash / ref only | If selected |
| Coach endorsement | Club / coach role | If approved | Yes | Hash / ref only | If selected |
| Full date of birth | Parent / member wallet | No | Restricted only | No | No |
| Family details | Parent wallet | No | No | No | No |
| Safeguarding notes | Safeguarding role | No | Restricted only | No | No |
| Withheld media | Marcus wallet | No | Count / ref only | Count / ref only, no body | Count only |