Tracks
Phase 4 tracks for the management API, rate limiting, multi-provider resilience, operator readiness, capability slices, and release gates.
Phase 4 — Tracks
Track A — Management API Server
Authenticated tenant-isolated management CRUD for organizations, users, agents, tokens, provider credentials, and model policies.
Sequencing: 4.A.1 → 4.A.2 → 4.A.3 → 4.A.4 → 4.A.5
Milestones:
- 4.A.1 — API Server Skeleton
- 4.A.2 — Org & User Management API
- 4.A.3 — Agent Management API
- 4.A.4 — Token Management API
- 4.A.5 — Provider Credential Management
Track B — Rate Limiting & Quota Enforcement
Atomic Redis rate limiting remains the hot-path control. Durable usage and monthly cost governance are explicitly moved to Track P and D6.
Sequencing: 4.B.1 → 4.B.2 → 4.B.3
Milestones:
- 4.B.1 — Lua Hierarchical Rate Limiter
- 4.B.2 — Rate Limit Config API
- 4.B.3 — Rate Limit Load Benchmark
Track C — Multi-Provider Adapters & Resilience
Provider parity, routing, circuit breaking, opt-in fallback, and streaming behavior.
Sequencing: 4.C.1 → 4.C.2 → 4.C.3 → 4.C.4 → 4.C.5
Milestones:
- 4.C.1 — Anthropic Adapter Hardening
- 4.C.2 — Per-Org Model Routing
- 4.C.3 — Circuit Breaker per Provider
- 4.C.4 — Fallback Routing
- 4.C.5 — Streaming Hardening
Track P — Operator Readiness, Evidence & Control Plane
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.
Purpose: establish the runtime, identity, evidence, privacy, data, deployment, and assurance contracts required before any dashboard UI can be called production-ready.
Sequencing: P0 → P1 → (D0 ∥ P6-bootstrap); P2–P5 are consumed by their named D slices and release gates, and P6-slice-certification is per slice.
Milestones:
- 4.P.0 — Runtime Topology & Environment Contract
- 4.P.1 — Identity, Tenancy & Authorization Assurance
- 4.P.2 — Canonical Evidence Plane & Durable Publication
- 4.P.3 — Privacy, Retention, Deletion & Audit Governance
- 4.P.4 — Query, Usage & Cost Data Platform
- 4.P.5 — Production Platform, Recovery & Supply Chain
- 4.P.6 — Contract & Assurance Harness
Track D — Operator Capability Slices
Purpose: deliver the world-class operator product as independently verifiable, end-to-end capability slices.
Sequencing: P0 + P1 → (D0 ∥ P6-bootstrap) → D1; then each of D2–D6 requires its own P contract plus P6-slice-certification.
D0 establishes services/console as the canonical application boundary. services/dashboard remains compatibility-only during migration and is retired only after its cutover gate passes. D1 must use real context, Overview, platform-health, and SSE contracts; navigation is not live domain delivery, and org switching is a deferred gate until verified. D2 is metadata-first and remains evidence-gated by P2 plus P6-slice-certification. D3–D6 each consume their named P contract plus P6-slice-certification.
Milestones:
- 4.D.0 — Canonical IBEX Console Foundation & Shell Migration
- 4.D.1 — Authenticated Shell & Operational Overview
- 4.D.2 — Explore & Provenance Trace Inspector
- 4.D.3 — Sessions, Memory, Context & Safe Replay Evidence
- 4.D.4 — Failures, Incidents & Evidence Bundles
- 4.D.5 — Directives, Routing, Experiments & Controlled Actions
- 4.D.6 — Usage, Cost Governance & Capacity
Track E — Release Readiness & Phase Exit
Purpose: convert implementation into a promotable, recoverable, auditable release.
Sequencing: P6-bootstrap + D1 + D2 evidence → E1; resilience evidence → E2; E1 + E2 → E3; all P/D evidence plus full F4 register disposition (including F4-035) → E4.
Milestones:
Last updated on