Availability and release checks

The documentation site is live. The public API remains proposed. Local automated tests and a published contract are not proof of AWS provisioning, Auth0 configuration, customer onboarding, or Linux runtime containment.

Surface	Verified evidence	Public availability
Documentation and read-only API explorer	HTTPS, deep links, mobile layout, no external requests, immutable spec hashes	Live documentation
Server SDK and customer ticket-tool example	Private package build; synthetic HTTP, signature, authorization and deduplication tests	Private source; not npm-published
Identity, keys, resources and run admission	Local PostgreSQL/SQLite tests; fail-closed composition ports	Proposed; cloud identity and cell acceptance checks required
Tools, files and webhook modules	Local signed operation, quarantine/scan and durable delivery tests	Proposed; real endpoint/storage/scanner and host checks required
Cancellation, deletion and restore	Coordinator and recovery contracts; missing adapters must fail closed	Proposed; complete invalidation and restore-drill evidence required
Provider execution and isolation	Bounded runtime design and local fixtures	Proposed; actual Linux containment and supplier metering verification required
Managed OAuth, schedules and persistent agent memory	Future contract inventory	Deferred

Operator readiness checks

A readiness check must verify configured services, not merely the presence of environment variables. Before an environment can be marked ready, collect evidence for identity-provider login/MFA, authoritative database and cell binding, encrypted storage, approved outbound broker, model/provider access, and applicable quotas. Refresh the current serving generation on requests and dispatches.

Before a public pilot, verify rate limiting, actor revocation during a stream and a pending approval, control-plane-first admission/cancellation, lost-response reconciliation, malware quarantine, webhook replay and secret rotation, deletion journal replay after restore, backup expiry, and measured-versus-reserved cost attribution. A missing dependency must return an unavailability failure; it must not produce a success-shaped stub.

Individual proposed operations may still require composition work, including deletion-job adapters, usage-ledger records, quota administration, retention settings, audit retrieval, and public tenant/service-actor management. Operators must test those operations on the actual release candidate. The downloadable openapi-available.json deliberately contains no live operations until required cloud and runtime checks pass.

Changing a capability to available requires fresh production evidence and an explicit release update. Publishing these docs does not change that state.