0 · Guided tour — the whole round trip, in plain language
No technical background needed. Five short steps, about five minutes. Each step: what to do, what you'll see, and why that part of the journey exists — or is deliberately missing.
The cast
The round trip in one sentence: a computer asks for company information; Sluice checks its badge, checks the job against the contract, releases only the contracted fields, writes a signed delivery note, notes the price, files everything, and answers. The five steps below walk you through it — including the two ways the trip legitimately ends early or empty.
Your demo badges (tokens)
Think of each as a staff badge. Click copy, then paste it into the "Demo bearer token" box in section 1 — or just press a step's Prepare button, which does both for you.
| Badge | Who it belongs to | Passcode |
|---|
Running the local version (npm run dev) instead of the live demo? These badges
only work on the live demo — locally, print your own with npm run print-secret.
The five steps
Step 1 — An allowed lookup: the full round trip
Do this: press Prepare, then press Run trace in section 1.
You'll see: one company's details (name, number, status, registered date) — with no ownership line — plus a receipt and a $2.50 price line. The diagram below lights up box by box, in journey order.
Why each part: the badge proves who is asking (the checkpoint never trusts "please"); the job ("company check") is the only use the contract covers; the missing ownership line is the contract at work — the basic contract simply doesn't include it; the receipt is the proof of exactly what changed hands; the price is per search.
Necessary? The receipt is the heart of the whole idea — without it, neither the bank nor the supplier can ever prove what was delivered, and a dispute becomes everyone's word against everyone's. The $2.50 is a mock note: no real money moves anywhere in this demo.
Step 2 — Same question, better contract
Do this: press Prepare (it switches to the premium badge), then Run trace.
You'll see: the very same company, the very same question — and now an ownership summary appears, listed in the receipt too.
Why: this proves the contract decides, not the question. Nothing about the request changed; only the badge (and the contract behind it) did. The restricted column isn't hidden after the fact — it is never even requested from the database, so it cannot leak.
Necessary? Yes — this is the core commercial idea. Buyers pay for exactly the fields and jobs they need; suppliers sell finer-grained access without risking their premium data.
Step 3 — The wrong job: stopped at the gate
Do this: press Prepare, then Run trace. The job is pre-set to "marketing".
You'll see: refused (red on the diagram). The journey stops at the licence box — the data is never searched, nothing is billed, no receipt is written.
Why: the contract covers company checks, not marketing. Checking this before the search is both cheaper and safer: there is nothing to leak, because nothing was looked up.
Necessary? Yes — "used only for the stated purpose" is the rule privacy laws actually require; this is that rule as software. (Honest limit: the declared job is taken at its word — enforcing what people do later with data they received is a contract and audit matter, not something a checkpoint can see.)
Step 4 — Nobody home: nothing found, still billed
Do this: press Prepare (registration number is pre-set to one that doesn't exist), then Run trace.
You'll see: allowed, zero rows — and still the $2.50, with a receipt proving "nothing was found" was the honest answer at that moment.
Why: the searching is the work — like a search fee. And "we found nothing" is itself a valuable answer worth proving: for a compliance check, a verified no-result still settles the question.
Necessary? Deliberately yes. "Free when empty" sounds friendly but invites unlimited free fishing. The receipt covering empty results is what makes the no-result provable.
Step 5 — The identical repeat: no double charge
Do this: press Prepare (this step runs twice for you), then Run trace.
You'll see: a normal run, then the exact same question sent again — the second answer comes back marked replay, from the filed original, billed once. (Optional extra: after a run, press new next to the request id, keep the same wording but change one letter of the company number, and run again — a reused reference number with a different question is rejected as a conflict.)
Why: computers retry automatically when networks hiccup — thousands of times a day. Without this protection, every hiccup would be a double charge and a second receipt for one job.
Necessary? Essential for anything machine-driven, invisible for humans — you don't accidentally ask the same question twice with the same reference number; software does.
Why every checkpoint exists (and what would go wrong without it)
| Checkpoint (diagram box) | In plain words | Without it |
|---|---|---|
| Identity | Show your badge before anything else | Anyone could claim to be the bank's assistant |
| Licence decision | "Is this job covered by the contract?" | Data bought for checks could quietly be used for anything |
| Projected query | Only the contracted columns are even searched | The database itself would have to be trusted to keep the secrets — and databases don't read contracts |
| Signed receipt | Tamper-proof delivery note | Every later dispute is memory against memory |
| Mock meter | Counts the price of the search | No per-use billing possible (here it's a mock — a note, not a charge) |
| Persistence | The note is filed before the answer leaves | A crash between answer and filing = an answer that officially never happened |
What this demo deliberately does NOT include
- Real money. The $2.50 is a line in a demo tally. No payment, no balance, no billing.
- Real companies. Every record is invented for the demo.
- Real security badges. A real bank's assistants carry bank-issued digital identities; here, three random demo passcodes.
- Proof of good behaviour. The receipt proves what was delivered — not what the bank's assistant did with it afterwards.
- A compliance guarantee. This demonstrates a control working, not that anyone is compliant. No regulator has blessed anything here.
- The rest of the planned machinery — the agent protocol (MCP), the real database (Postgres), payment rails. The dashed box at the bottom of the diagram lists them.
Jargon decoder
| agent | a computer program doing a job on someone's behalf — this page plays one |
| token / badge | a long random passcode that proves who is asking |
| tier | contract level: basic or premium |
| purpose | the declared job — "kyb" (company check) is covered; "marketing" is not |
| receipt | the signed delivery note |
| meter | the price counter |
| replay | an identical automatic retry — same answer, no second charge |
1 · Scenario & credential
Held in memory only — never stored, never sent anywhere but this Worker. Badges are listed in the §0 table.
Not run yet — the diagram below explains the flow without a request.
2 · Data flow
Click or tab to a node for its actual inputs/outputs and trust boundary. Teal marks steps that ran; red is the deny branch; dimmed teal after a replay marks the stored original trace — nothing re-executed.
Planned adapters — not in this POC: MCP transport · EMA gateway · Postgres + RLS · payment rails
3 · Node detail
4 · Response & receipt verification
No request yet. Every result shown here comes from the real API — nothing is fabricated.