Phase 4 — Operator Platform & Multi-Provider
Phase 4 delivers a production-ready operator platform: management APIs, hierarchical rate limiting, multi-provider resilience, a governed evidence plane, and a world-class operator dashboard.
Phase 4 — Operator Platform & Multi-Provider
What Phase 4 delivers
Phase 4 turns IBEX from a proxy and API-oriented system into a governed operator platform. It delivers authenticated tenant-scoped management, enforceable rate controls, resilient multi-provider routing, an auditable evidence plane, a world-class operator dashboard, and a release process that proves recovery, security, accessibility, performance, and rollback.
Phase 4 tracks
| Track | Theme | Status | Milestones |
|---|---|---|---|
| A | Management API Server | Foundation | 4.A.1–4.A.5 |
| B | Rate Limiting & Quota Enforcement | Foundation | 4.B.1–4.B.3 |
| C | Multi-Provider Adapters & Resilience | 4.C.5 baseline complete | 4.C.1–4.C.5 |
| P | Operator Readiness, Evidence & Control Plane | Required before dashboard UI | 4.P.0–4.P.6 |
| D | Operator Capability Slices | D0 planned/specification; D1/D2 evidence-gated | 4.D.0–4.D.6 |
| E | Release Readiness & Phase Exit | Redesigned | 4.E.1–4.E.4 |
Critical path
Canonical dependency model
Use these graph terms everywhere: P0, P1, D0, P6-bootstrap, P6-slice-certification, D1, D2, D3, D4, D5, D6, E1, E2, E3, and E4. The acyclic dependency model is:
P0 → P1
P0 + P1 → (D0 ∥ P6-bootstrap)
D0 + P0 + P1 + P6-bootstrap → D1
P2 + P6-slice-certification → D2
P3 + P6-slice-certification → D3
P3 + P6-slice-certification → D4
P1 + P2 + P4 + P6-slice-certification → D5
P4 + P6-slice-certification → D6
P6-bootstrap + D1 + D2 evidence → E1
resilience evidence → E2
E1 + E2 → E3
all P/D evidence + E1 + E2 + E3 + full F4 register disposition (including F4-035) → E4P6-bootstrap establishes the harness and manifest contract. P6-slice-certification is produced separately for each D slice after that slice's required P contract is available; it is not a claim that all assurance work is complete. D0 and P6-bootstrap may proceed in parallel only after P0 and P1 are available. E1 consumes P6-bootstrap plus D1/D2 evidence, E2 consumes resilience evidence, E3 follows E1 and E2, and E4 signs off all evidence and the full F4 register, including F4-035 surface separation.
Tracks A and B continue independently. Track C provides a resilience input, not a completion claim. P0 and P1 are first; D0 and P6-bootstrap may proceed in parallel after them. D1 requires D0, P0, P1, and P6-bootstrap. D2–D6 each require their own P contract plus P6-slice-certification. Navigation is not live domain delivery, and org switching is a deferred D1 gate until verified.
Entry conditions
- Phase 3.5 extraction, context assembly, and MCP memory tools are complete.
- The authenticated API and RLS foundations from Track A are available for extension.
- 4.C.5 streaming hardening is treated as the planning baseline.
- The phase owner has accepted the Track P / Track D redesign and its evidence-based completion model.
Phase exit conditions
- Track P gates pass for runtime, identity, evidence, privacy, platform, and assurance.
- The canonical operator application is deployed on a server-capable topology or a separately deployed SPA/API/SSE topology;
services/dashboardis compatibility-only until its retirement gate passes. - A nested multi-step agent run can be queried, explained, redacted, replayed safely, and linked to sessions, memories, tools, policies, evaluations, and incidents.
- Tenant isolation is demonstrated across synchronous and asynchronous paths.
- Usage and cost facts reconcile to immutable events and hard caps are enforced by the proxy.
- Required Playwright, axe, keyboard, contract, load, chaos, recovery, and supply-chain checks pass in the intended environment.
- Staged rollout, automatic abort, rollback, backup/restore, and residual-risk sign-off are evidenced.
- The Phase 4 gap register has zero open P0 gaps and all remaining P1/P2 items have owners and dates.
Findings carried into this phase
The redesign records the following findings as roadmap requirements rather than informal notes:
| Finding | Consequence |
|---|---|
| The current public web deployment is a static documentation site. | Runtime topology and live API/SSE origin are prerequisites. |
| Current trace persistence is an aggregate request row. | Canonical nested trace/span/event evidence must precede Trace Inspector UI. |
| Permission constants are not dashboard contracts. | Versioned API, tenancy, field policy, and step-up authorization are required. |
| ClickHouse TTL is not coordinated deletion. | Retention, tombstones, per-store watermarks, and deletion receipts are required. |
| Usage/cost tables assumed by the old 4.D.5 do not exist at the required scope. | Immutable usage ledger, rate-card versions, reconciliation, and enforcement are required. |
| Deployment, restore, and Playwright gates are described but not wired as acceptance gates. | Track P.5/P6-bootstrap, P6-slice-certification, and Track E make them executable and required. |
| F4-035 identifies public docs, the compatibility shell, and the fixture-backed prototype as distinct surfaces. | D0 owns the canonical console boundary; E4 signs off its evidence and residual risk. |
| F4-036/F4-037 capture Proxy profile-default and shared-rate-limit fail-open hazards. | PR 1 requires an explicit IBEX_ENV, shared Redis outside development, and 503/no-provider behavior on limiter failure; runtime evidence remains open. |
Related documentation
Last updated on