Phase-2 roadmap
Everything below is explicitly out of scope for Phase 1 per the design spec — named here as direction, not as a commitment to a timeline. None of it is implemented today; treat any docs page describing it as forward-looking.
SDK auto-emit + batching
Phase 1 is entirely manual emit — your code calls emit() explicitly. Phase 2
adds SDK middleware that calls the same emit() automatically on API calls, with
telemetry-appropriate defaults, plus client-side batching (buffer-and-flush) for
the resulting higher volume. Manual emits are expected to stay instant even after
this lands — batching is additive to the low-volume manual path, not a replacement
for it.
A real message broker
The bus adapter is direct/in-process in Phase 1 — deliberately: trust and ordering
don't depend on the bus at manual-emit volume (see
Adapters & Profiles). A real broker
(RabbitMQ, Kafka, NATS, Redis Streams, or SQS are all named as candidates) is
deferred specifically until auto-emit volume needs it, swapped in behind the same
bus.Bus interface — no core code should need to change.
More adapter implementations
Every seam ships exactly one reference implementation in Phase 1. Named Phase-2/alt-implementation candidates, per seam:
| Seam | Phase-2 candidates |
|---|---|
| Store | Timescale, BigQuery, Snowflake, plain PostgreSQL |
| Realtime | Ably, Pusher, Soketi, plain SSE, Supabase Realtime |
| Identity | Supabase/Firebase Auth, Auth0/OIDC, SAML (already supportable today via config — see Wiring a non-native IdP — but not yet a named, first-class adapter) |
| Channel | Email, WhatsApp, Teams, Slack, SMS, push |
| Secrets | envctl, HashiCorp Vault / OpenBao Transit |
Multi-tenant control plane
Self-serve tenant onboarding, billing, and per-tenant adapter configuration — see Multi-tenancy direction.
Notification preferences, policy UI, analytics UI
User-facing notification preferences (opt-out/channel choice per user, not just per-tenant policy), a dedicated policy-authoring UI beyond the admin portal's current raw JSON forms, and a proper analytics UI beyond the current process-local counters (see API Reference → Deployment profile & analytics).
Tracked Phase-1 gaps
Beyond the roadmap items above, several already-shipped Phase-1 behaviors are
documented as deliberate, flagged limitations rather than silently-accepted bugs —
each is called out with a caution box on the page where it's relevant rather than
repeated here. Notable ones: GET /v1/feed's and the Admin API's PageResult
wire-casing discrepancy (API Reference),
GET /v1/stream requiring a configured realtime adapter
(Realtime & streaming), the missing
TypeScript service-token minting helper (SDK Reference), and
group-scoped feed/stream queries returning 501
(Data plane API).