Published copy, to share: https://claude.ai/artifact/WJZ4DjSAroxgqKjZLatuiP
situs, updated 23 Sep 2026 · compared with Situs Strategy and Architecture v4.1 (21 Sep 2026)The strategy doc describes a split-plane trust network: a Situs control plane, data planes inside certified venues, a registry, and relying parties who verify receipts. Pilot 1 is its first slice, enforcement mode on one venue. This page maps every component the doc names to what the build does today, including the operator console added since the first cut: the demo in the browser, a policy editor that publishes signed profile versions, client mailboxes feeding one queue, a live dashboard, and approval from the page, email, a Mac dialog or an iPhone.
Layout follows the doc's system view (§15–16): request boundary on the left, the Situs control plane and the venue data plane in the middle, relying parties on the right. The line at the bottom is the enforcement-mode path every payment takes.
X-Situs-Contract header + tool calls, each tied to its source messageCustomer supplies the agent harness in enforcement mode.
L1-simven_local_dev, uncertified/devsitus-verify, 9 offline checks, + web /verifymake demo-bypass: raw bank key, no SitusDoc §18, "Assurance by degree". Every receipt carries the required and the achieved level.
Certified venue, known jurisdiction, signed request and response hashes. Usage claimed.
L1-simDoc: build, model, config and policy measured, plus the customer KMS key-release record. The build measures only the gateway's source hash and has no key-release record, so it sits below true L1 and says so in unproven.
TDX or SEV-SNP plus GPU confidential computing, CPU and GPU quotes. Fields present in every receipt, empty and marked.
From §26, "enforcement mode on one venue, five things and no more", plus its six production requirements and the Pilot 1 surfaces in §13.
| Doc requirement | Status | In the build |
|---|---|---|
| SDK capture of the request boundary + structured intent | different | An OpenAI-compatible gateway instead of an SDK. Same hashes and principal, no code change for the agent. |
| treasury.v1 with three façades | built | bank.readBalance, market.fetch, bank.executeTransfer(grant). |
| Authority Engine, single-use Action Grants, approval bound to the action hash | built | Deterministic, no model import (tested). Approver signs the recomputed hash, wherever they approve from. |
| One enforcement point, broker-injected credentials, minimal egress allowlist | built | The agent never holds a bank credential; a grep and a runtime probe both prove it. |
| Signed evidence chain, portable receipt, offline verifier | built | Five signatures on an executed transfer; nine checks; tampering fails at the owning party's check. |
| Bypass test, idempotency key on every grant, "valid as of" verifier, canonical encoding frozen at v0.2 | built | Retry storm: three retries, one transfer. The key is derived from the payment, and a second grant for the same invoice is refused (duplicate_action), so several agents on the same mailboxes pay each invoice once. RFC 8785 JCS everywhere. |
| Risk officer authors treasury.v1 limits and signs the certification in the console | partial | Limits, vendors, approvers and lifetimes are edited on the Policy tab and published as a new version signed by the treasurer. The authority and pep verify it before use and refuse everything if it does not verify; mandates signed under an older version stop. Missing: a risk-officer key of its own and a certification statement. |
| Authority, pep and broker in confidential CPU VMs from day one | gap | Excluded by the build's own scope lock ("no confidential-VM plumbing"). Written up in docs/DEPLOY.md only. |
| HSM-held signing keys, admin separation | gap | Service keys are PEM files in ./keys. People can sign with Touch ID or a passkey. Plan in docs/DEPLOY.md. |
| Maximum stale-trust window per profile, fail closed past it | partial | Window declared (60 s, now editable per profile version) and reported; the verifier warns past it. The pep reads contract status live, so it never runs stale. |
| Real receiving-system acknowledgment (pacs.002-class) | simulated | Mock bank signs its own ack with ed25519. |
The console at :8080 runs the whole storyline in the browser. It holds no bank secret and mints nothing; its only writes are signatures made with the people's own keys.
msg_…) that follows it through the queue (q_…) to its instructions (ins_…) and receipts.These close the gap between this demo and the pilot the doc promises a bank.
CLAUDE.md lifted, then the steps in docs/DEPLOY.md. Until then receipts stay honest at L1-sim.The terminal recording plays on the published copy of this page, or here with asciinema play demo/demo.cast. Run it yourself on the Demo tab.