Status — Production, Beta, Implemented, and Design

This page is the product map, and the source of truth for each mechanism's maturity. Witbitz uses four literal states — nothing else:

• Production — running in production today. (Whether every Space has it structurally, or an app enables it per room, both are in production.)
• Beta — usable by invited integrators; the contract may change.
• Implemented — built and tested, the code exists, but not enabled in production.
• Design — the architecture is specified, but the mechanism is not built.

Maturity is separate from two other facts, and this page never collapses them into the maturity word:

• Scope — whose property it is: the platform, the first-party app, the client, or the server.
• Configuration — whether every Space gets a mechanism (structural) or an app switches it on per room. That is a config fact, documented per app (for the Spaces app: privacy in the Spaces app) — never a maturity qualifier. (The attested tier is Production, full stop; the per-room enable is a builder choice, not an "opt-in" that makes it less-than-production.)

Where a mechanism is Production in one place and Design in another, it is split into separate facets so no single label ever describes two states. For the privacy configuration spine — the canonical maximum, the mechanism axes, the named modes, and the feature × mode matrix — see Privacy tiers.

Summary

Production

Async Spaces

The production Spaces app runs the async model: a member posts a turn, the render opens the sealed ledger, the agent answers, state is re-sealed, and the Space goes cold again. Idle Spaces do not require a running server process. Read: How a turn runs

Identity and admission

Spaces support key-possession membership and deployed signed identity for gated rooms. For an email-gated Space, reads and writes both require an allow-listed identity; a link holder without that identity receives 403. Read: Identity and admission and Verify it yourself

Usernames and discovery

An account may claim a @username: a public address over its stable handle, never a key, so a rename costs no room any access. It works as an invite target, on an allow-list, and as the server-attested author mark on verified entries. Each account also decides whether it can be found by email; closed reads exactly like unknown. Read: Usernames, discovery, and who is in the room

Connections

A member attaches a credential once; it lives sealed in the standing Sentinel, a measured always-on enclave. Each Space is granted the connections its assistant may spend, and every spend is a proposal a member approves. The model sees the reply, never the secret. Read: Connections

Approvals

Effectful agent actions go through propose, approve or deny, then execute. Execution is refused unless the proposal is approved and has not already run. The audit trail is sealed with the room. Read: Approvals

Verifiable privacy checks

The current production checks cover the admission gate, the app's egress footprint, content-blind storage, the signed build certificate, and a reproducible build of the published render source. Read: Verify it yourself

Attested server tier

A Space runs its turns inside an AWS Nitro enclave in production. The room key is sealed to a key generated inside the measured image and bound into a hardware-signed attestation that the deployed web app verifies and pins before it seals anything. Runtime secrets reach the enclave only through a PCR8-gated KMS grant — the measured image is the only thing that can decrypt them. The tier runs always on, so the first turn never waits for a launch. The app builder enables the enclave per room — the platform can run any room in it — and the model call leaves the measured image only through an attested no-log gateway into confidential-compute inference on an open-weights model — the frontier-vendor residual applies only to rooms that choose the frontier trade (the attested tier). Read: The attested tier

The Siri inbox

Dictated text posted to an endpoint whose TLS terminates inside the standing Sentinel, sealed to the Space and collected by your device. Live and attested. Read: The Siri inbox in the SDK

Beta

Cloud computers

The coding agent's own computer in the cloud, from Code → ☰ → Computers → New cloud computer. Each runs in an AWS Nitro Enclave whose image is pinned and attested; its workspace is saved encrypted after every turn and opens only for the account that made it; it sleeps after 30 minutes unused. Part of the Plus plan; during early access, open to invited accounts — the rest are told so when they create one. Read: Code and the Spaces guide's "Cloud computers"

Platform API

The /v1 API is tenant-keyed and documented with a public OpenAPI contract. Access is invite-only during private beta; the contract may change with invited integrators before general availability. Read: HTTP API

Application SDK

A small ES-module surface (Witbitz/Space) so a static page becomes a private, agent-backed, link-shared app; it wraps the exact reference client production runs. Usable today; the surface may still change. Released as fixed, versioned files with integrity hashes; an npm package (with the @witbitz/test harness) is not released yet. Read: The SDK

Implemented (built, not enabled in production)

App owner rule

Not a room's owners and admins (those are live). The app owner rule lets an app owner mandate signed admission policy and tiered capabilities for every governed room. The implementation is built and tested but inert: unset keys leave existing rooms unchanged, so it is not enabled in production. Read: The owner rule

Verified client (web)

The web verifier extension + CSP-loader pins the platform-signed release and forces the egress-lock in the running browser. It is built and proven headless on staging, gated behind ?vc / the extension — not the default production boot. Read: The verified client

Membership re-key (Bridge) · Bridge protocol

In the Bridge, adding or removing a member forks the room to a new epoch key the removed member cannot derive. The Bridge itself is an early cross-organization protocol surface. Read: Identity and admission

Design

Attested client (native shells)

The native attested-client apps are not shipped. On the server, the parts are built: the admission check, and the real verifiers behind it — Apple App Attest (attestation and assertions, against Apple's root) and Android key attestation (the certificate chain, the key description, the app's signing certificate). They are tested with synthetic keys only: no real device's evidence exists until a native app does. Android's app binding is a best-effort check of the signing certificate, and a Windows client stays refused. The rule for the native apps: the reproducible web bundle is shipped inside the attested binary and loaded locally. Read: The attested client

Social recovery · traffic shaping

k-of-n social recovery and traffic-shaping are each specified but not built. (Single-Space membership re-key is in production — in place, with a new key for the members who stay; see the matrix above; the confidential model and OHTTP shipped too — Privacy tiers.)

Machine-readable source: status.md · Generated 2026-10-27T07:05:42Z · build f301388c · every doc in one fetch: llms-full.txt (HTML)