How it works

Five target stages, one contract to prove.

This page describes the five-stage target contract being built: listen, sort, Desk, do, and prove. The clickable walkthrough uses sample data and is not evidence that travel, calendar, or receipt execution is live.

The pipeline

Follow the note through

Illustrative sample of the target contract — not live execution evidence: no fare hold, booking, calendar update, or receipt shown here was executed.

  1. Listen — your channels are read quietly, on your own computer.
  2. Sort — loose noise becomes tidy cards; the rest is filed without reaching you.
  3. Desk — the few real decisions arrive as prepared papers; you sign, send back with a note, or bin.
  4. Do (target contract) — approved work may be routed to a selected AI service; this sample does not execute an outside action.
  5. Prove (target contract) — closure requires evidence that names what happened; this sample is not a live receipt.
The life of a piece of information

A passing detail can become the fact a decision turns on

A passing detail can stay a passing detail. It can also become the fact a decision turns on. Moneypenny preserves it, weighs it, asks when judgment is needed, and keeps the receipt for what happened next. Follow one item through — and notice this is a loop, not a conveyor belt.

YOUR MAC · capture edge
1 It arrives

A message, note, receipt, or signal appears on a channel you already use. The Eavesdropper on your Mac notices it and records where it came from.

2 It is preserved before it moves

The Mac writes a small durable copy before advancing the source cursor. If the studio machine is offline, the item waits safely and retries with the same identity.

acknowledged only after the studio machine commits — retries keep the same identity
STUDIO MACHINE · durable control plane
3 It enters shared state

The studio machine admits the item once, assigns its first priority, and records the obligation to process it. Only then does it send a durable receipt back to the Mac.

4 It is weighed and refined

The Switchboard relates the item to deadlines, people, dependencies, previous work, and new evidence. Priority is a recorded decision, not a number silently overwritten.

Can it continue without you? yes · allowed and reversible → the work runs ambiguous or consequential → one paper on your Desk
5 Judgment enters at the Desk

Clear, reversible work can continue. Ambiguous, consequential, or irreversible work becomes one short decision on your Desk: approve, refine, ask, snooze, ignore, split, merge, star, or cancel.

6 The work runs, and can come back

A swappable execution runner performs the approved step. Failure, missing context, or a result that needs judgment loops back to the Switchboard or Desk instead of dying in a session log.

7 The receipt becomes future context

The operational record says what must happen next. Append-only history explains what happened and why. Small human-readable artifacts preserve the useful summary and point back to the evidence. Any of those receipts can refine the next decision.

The return paths are the product, not decorative plumbing
  • Target contract: missing context must come back. A run that lacks context must return for one bounded clarification before reprioritization.
  • Target contract: new evidence must be able to reprioritize old items. A reviewed receipt may move a filed item back to attention.
  • Target contract: failed work must not disappear. It must return for refinement, retry, or a reviewed alternate route.
  • Target contract: Desk decisions must be durably recorded. Snooze, ignore, and cancel must not become silent deletion.
operational

What must happen next

The durable queue, priorities, decisions, leases, and wakeups that keep work moving after a restart.

history

What happened, and why

Append-only evidence for receipts, evaluation, provenance, timing, and later analysis.

artifacts

What a person should be able to read

Small summaries, manifests, hashes, and pointers back to the underlying records.

This section describes the contract being built; the public sample does not prove these return paths. The honest page separates the personal build from this site's sample-data demo.

Minor stays light. Foundational stays traceable. Neither disappears in a runner.

One door

Every channel comes in the same way

The intended architecture normalizes explicitly connected channels into one intake contract. Adding a channel should not require rebuilding downstream stages. The public sample reads no channels.

The target privacy boundary is local processing of connected-message records; this public sample does not prove that boundary.

The one human gate

The final-effect gate being built

The target contract requires an independent approval gate before any final effect. These are design requirements, not a claim that the public sample or current runtime has already proved enforcement:

rule 01

Reversible work first

Before interrupting you, it does only work that can be undone: comparing, drafting, holding an option without spending. Interruption is the expensive thing; it's spent last.

rule 02

Stop before authority

Anything that spends money, sends words in your name, or commits you to a time must stop at the Desk and wait for an independently verified approval. The public sample does not exercise this gate.

rule 03

Precise papers only

A paper may not reach the Desk until it states the exact decision needed. If deciding takes more than a moment, the preparation failed — and it goes back.

Continuity

Your record outlives any AI vendor

Target architecture: durable jobs, history, and evidence must remain outside the selected AI runner so a reviewed runner can be replaced without becoming the system of record. The public sample invokes no runner.

A reviewed runtime must prove restart and runner-switch continuity against durable state. This public sample proves neither mid-task recovery nor vendor switching.

See the "do" stage above for the picture, or read why that's the trust argument →