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 in the Spaces app defaults — 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

Capability	Maturity	Scope	What to say
Async Spaces	Production	platform	Persistent shared rooms with AI turns, sealed ledger, documents, widgets, and artifacts.
Private lanes	Production	platform	Each participant can have their own lane — a separate Space, linked on the device; its agent observes the shared room and cannot post to it.
Progressive replies	Production	platform	The answer is sealed and published as it is written, so a reader starts reading before the turn finishes.
Away notification	Production	platform	Content-free Web Push wakes an installed PWA; the notification carries no message text.
Offline export	Production	client	A Space exports to a file you keep, with a standalone decryptor and sealed per-Space metadata.
Admission gate	Production	platform	Gated Spaces refuse reads and writes without an allow-listed identity.
Content-blind storage	Production	platform	The store holds ciphertext sealed to the room key; no operator recovery recipient.
Delegated authority	Production	platform	High-stakes actions require human approval before execution.
Egress lock	Production	platform	The browser-visible app can reach only a published allowlist.
Signed build certificate	Production	platform	`/cert.json` binds the deployed render build and egress footprint.
Reproducible render build	Production	platform	Published source rebuilds to the deployed Lambda hash.
Attested server tier	Production	platform	A Space runs its turns inside a measured Nitro enclave in production; the key is sealed to the attested image; launch-on-demand + scale-to-zero. The app builder enables the enclave per room.
Recovery — vault	Production	client	One vault opened by either a passkey or a backup code, stored as opaque blobs at derived ids. No operator recovery key; losing every enrolled method is unrecoverable by design.
On-prem VPC tier	Production	platform	The runtime runs in a customer's boundary with customer model, storage, and IdP seams.
Platform API	Beta	platform	Tenant-keyed `/v1` API; invite-only, public OpenAPI, contract may change.
Application SDK	Beta	client	A small ES-module surface so a static page becomes a private, agent-backed, link-shared app; wraps the reference client.
Owner rule	Implemented	platform	Owner-governed rooms and tiered admission are built and tested, but not enabled in production (inert unless configured).
Membership re-key — Bridge	Implemented	platform	Adding or removing a member forks the room to a new epoch key; live in the Bridge, which is itself an early preview.
Verified client (web)	Implemented	client	The verifier extension + CSP-loader that pins the release; built and proven on staging, gated behind `?vc` — not the default production boot.
Bridge protocol	Implemented	platform	Cross-organization governed collaboration exists as an early protocol surface.
Membership re-key — single-Space	Implemented	platform	A membership change forks the Space to a new epoch key sealed only to the remaining keepers (removed member structurally excluded); built + wired to the Members UI + tested (`agent/spaceFork.test.mjs`). Fork-based; triggered by a membership change (no scheduled rotation). The server read-gate is a complementary, reversible revocation.
Social recovery (k-of-n)	Design	client	k-of-n social recovery is designed, not built.
Attested client (native shells)	Design	client	Native hardware-attested shells are not shipped; the server-side `requireAttestation` seam is Implemented (mock verifier), the native verifiers stubbed.
Companion	Design	client	A native helper may improve notifications and key storage; the platform does not depend on it.
Confidential model (attested inference)	Production	platform	The confidential tier routes its model call through an attested no-log gateway into confidential-compute inference on an open-weights model (The attested tier).
OHTTP (network-metadata)	Production	platform	Oblivious transport (RFC 9458), behind the "Hide my IP" toggle: a pinned L1.5 client + a client-verified relay (GCP Confidential Space, relay.witbitz.chat) — no party sees both your IP and your rooms. Covers all app→AWS traffic incl. the enclave attest/wake path (fail-closed); relay verification is offline (Google's Confidential-Space keys baked into L1.5, so checking the relay never reveals your IP to Google) (Privacy tiers).
Client shaping	Design	platform	Traffic-shaping (sizes/timing) is specified, not built.

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: Async Spaces

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

Delegated authority

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: Delegated authority

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. It is made affordable by scale-to-zero: the enclave launches on demand, wakes on your first message, shows the Space's history while it sleeps, and terminates itself about twenty minutes after the last interaction. 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

Beta

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: Platform 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. Read: The SDK

Implemented (built, not enabled in production)

Owner rule

The 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 server-side admission seam exists and is tested with a mock verifier, but the native attested-client shells are not shipped and the real hardware verifiers are stubbed. The rule for the future client is that the reproducible web bundle must be bundled inside the attested binary and loaded locally. Read: The attested client

k-of-n social recovery and traffic-shaping are each specified but not built. (Single-Space membership re-key shipped — see the matrix above; the confidential model and OHTTP shipped too — Privacy tiers.)

Machine-readable source: status.md · Generated 2026-08-29T18:46:30Z · build f3ff88cc · every doc in one fetch: llms-full.txt (HTML) · ← deployment-options