The private-runtime target
The intended assistant runtime is software you operate on your own machines, with connected-message records kept there. That design goal does not describe this public site: Cloudflare Pages serves it, a Cloudflare Worker handles analytics and signup traffic, and successful signups are stored in Cloudflare KV.
Private-runtime design boundary
- Is designed to read only the channels you connect — connecting email must not authorize another channel.
- Is designed to keep connected-message records on hardware you operate, in inspectable records rather than a public-site inbox.
- May route an explicitly approved, task-scoped request to an AI service; the target boundary is the job, not the archive.
Target contract — not live proof
- Connected messages must not be sent to public-site infrastructure or sold; approved task-scoped processing by an outside service must be explicit and receipted.
- A final effect must not spend money, send words, or commit time without an independently verified approval; this sample does not prove that gate.
- Closure must require evidence and a human gate, rather than trusting a self-reported status; the sample receipt below is not closure evidence.
What leaves the machine, exactly
The intended outside-processing boundary, stated plainly. Under the target contract, an explicitly approved task that needs an outside AI service would send only the request and the details needed for that task. In the illustrative flight example, that would mean travel dates, airports, fare preference, and a passenger name — not meeting notes, other threads, contacts, or an archive. No such booking request is sent by this page. A real send would need its own evidence-backed receipt.
One promise per stage
Every stage of the pipeline carries its own promise. Click through them — the same five stages, each annotated with what it owes you.
Illustrative sample of the target contract — not live execution evidence: no fare hold, booking, calendar update, or receipt shown here was executed.
- Listen (target contract) — only connected channels are read; public-site infrastructure is not a message store.
- Sort — you're interrupted only when something genuinely needs a human.
- Desk (target contract) — consequential final effects require independently verified approval.
- Do (target contract) — an approved task may use a selected AI service without making that vendor the system of record.
- Prove (target contract) — evidence and the human gate must support closure; the public receipt is illustrative.
What a receipt looks like
Policies are words; closure needs evidence you can check. This is an illustrative target-contract receipt from the in-browser sample. No fare was held, no booking or calendar update occurred, and no confirmation was filed; it is not live execution or closure evidence.
The target contract requires evidence before closure and independently verified approval before a final effect. This illustrative card is not evidence, no airline card was saved, and no job was returned to a live Desk.
Private-runtime receipts are not exposed on this public site. The demo shows an illustrative target contract only; it does not prove a production receipt shape. See receipts being made in the sample demo →
It will misjudge things. Here's what that costs.
Target recovery requirement: filed items must remain recoverable. Filing must not delete the source record, and restoration must be evidenced before this claim can become live.
Target safety requirement: preparation must remain reversible. Drafting, comparison, and any option hold must stop before a final effect unless an independent approval is proved.
Target audit requirement: failed signed work must retain evidence. A reviewed receipt must identify the request, effect, time, and available recovery path.
The public sample exercises none of these recovery paths and does not prove that mistakes are cheap, visible, or reversible.
What this is, and isn't
This is one engineer's build under development, not a supported product. The public workflow examples and demo use isolated sample data and perform no live message processing or outside action; disclosed signup and analytics paths still process real visitor data.
The public demo does not expose or prove a private Desk or runtime. What it can show is the sample interaction and the reviewed public-data disclosures on these pages.