v1.0

June 9, 2026 · View on GitHub

Statewave v1.0 is the first stable public developer release of the open-source memory runtime that gives AI agents reproducible, provenance-tagged context. The v1 API contract (/v1/*) and the v0.9 governance surfaces (HMAC-signed receipts, replay, sensitivity labels with declarative policy, opt-in detector-suggested labels, per-region residency pinning) are now considered stable for developer use under a self-hosted deployment model. Limitations are documented in why-statewave.md; see v1.0-readiness-checklist.md for the full sign-off artefact.

v1.0 — first stable public developer release. Not "GA", not "production-ready", not "production-hardened", not "battle-tested", not "enterprise-ready", not "hardened".

What is stable in v1.0

  • The /v1 API contract. Backward-compatible additions only from here; the contract is the cross-repo compatibility axis (any SDK that speaks /v1 works against any server that serves /v1).
  • The v0.9 governance surfaces — HMAC-signed state-assembly receipts (content-hash integrity, ULID-addressable, queryable per subject), receipt-driven replay (current code + original policy), per-memory sensitivity labels feeding a declarative YAML policy engine, opt-in detector-suggested labels (strictly separate from authoritative labels), and per-region data residency with hard application-layer enforcement.
  • Both SDKs at v1.0.0 — statewave (PyPI) and @statewavedev/sdk (npm), typed surfaces matching the REST contract, semver-stable from 1.0.0 forward.
  • Multi-replica API deployment — supported and verified since v0.8 (Fly multi-machine + Helm HPA). Single-Postgres only.

What v1.0 does NOT promise

Carried forward verbatim from the "Still in progress / not yet proven" list in why-statewave.md:

  • Production-scale not load-tested at >10k subjects / high throughput. Single-Postgres only; no cross-region clustering.
  • Multi-tenant isolation is app-layer query scoping; no Postgres RLS yet.
  • LLM-compiler vs heuristic-compiler comparative eval not yet published.
  • 50-session production-scale benchmark not yet run.
  • No second-region deploy verified (residency enforcement is implemented and audited per-region; cross-region failover is not tested because we run one region today).
  • No admin-action identity yet (promoted_by is null until that layer ships).
  • No federated cross-region audit.
  • Receipt replay is "current code + original policy"; byte-for-byte historical reproduction needs memory snapshots (deferred).

What landed for v1.0 (since v0.9.x)

The v0.9.0 → v0.9.4 laps (replay, HMAC signing, auto-labeling, residency; see their close-out docs) plus, since v0.9.2:

  • GET /v1/version (statewave#178) — public, unauthenticated server version discovery.
  • Python SDK governance helpers (statewave#176) — list_suggested_labels() / promote_suggested_labels() with typed result models (sync + async).
  • session_id on create_episode (statewave#174) — forwarded on the wire in both SDKs.
  • Webhook delivery stats + tenant scoping — optional tenant filter on event-status queries, per-tenant delivery statistics, dead-lettering of permanent 4xx deliveries.
  • A correctness lap across the admin / receipts / conflicts / compile-jobs / backup / embeddings / snapshots surfaces (tenant-scoping, constant-time key compare, input-order preservation, newest-first ranking, per-(tenant, subject) health-cache isolation).

Compatibility

  • /v1 contract: stable; backward-compatible additions only.
  • Both SDKs: stable; semver-compliant from v1.0.0 forward.
  • Server pyproject 1.0.0 is the reference implementation for the published contract.

Provenance