Define the post-Beta AI gateway parity and hybrid control-plane roadmap

[tiammomo]

Summary

ModelPort already implements much of the small-team gateway baseline while its accepted long-term direction adds models, Runtime Adapters, Compute/GPU inventory, and Deployments. Without an explicit evidence-backed post-Beta roadmap, industry gateway features can become an unbounded checklist that dilutes the product contract or incorrectly merges Clients/Harnesses, Providers, and runtime resources.

Actual behavior

The current roadmap protects the v0.1.x Beta freeze and names the hybrid control-plane sequence, but it does not map established AI gateway capability families to what ModelPort already ships, what must mature next, what belongs after design-partner evidence, and what remains a deliberate non-goal. It also does not state how relay-style channel management should evolve into typed Provider, credential, model, route, and Compute resources.

Expected behavior

Documentation positions ModelPort as a governed, self-hosted hybrid AI gateway and model/GPU control plane. It records a staged parity strategy informed by official LiteLLM, Portkey, Kong AI Gateway, Envoy AI Gateway, OpenRouter, Cloudflare AI Gateway, and New API documentation, while preserving the current Beta contract and making ModelPort differentiation, dependencies, evidence gates, and non-goals explicit.

Steps to reproduce

Review docs/ROADMAP.md and docs/ARCHITECTURE.md when deciding whether to add caching, guardrails, more protocols, public multi-tenancy, channel billing, CLI profiles, distributed routing, or GPU placement. The documents do not currently provide one ordered decision framework across those requests.

Environment

ModelPort after the Runtime Adapter contract/client/registry work, with persistence PR #26 and Issues #29-#31 forming the current Compute delivery chain.

Acceptance criteria

• Add an evidence-backed product strategy or ADR using only primary official sources for the compared gateways and standards.
• Map industry baseline capabilities into unified protocol ingress, typed Provider/credential/model management, routing and resilience, identity/quota/budget governance, content-minimized observability, and operator UX; mark each as shipped, hardening, evidence-gated, or deferred.
• Keep Client/Harness profiles such as Claude Code, Codex CLI, Qwen Code, and SDK snippets separate from upstream Provider identity; DeepSeek remains a Provider/model family unless a distinct caller harness contract is introduced.
• Define control-plane and data-plane ownership. Preserve a single-process Rust data path for the current product, while making a future split an ADR-gated deployment choice rather than a premature rewrite.
• Order the immediate hybrid chain as snapshot persistence (Persist Runtime Adapter Compute snapshots with server-owned freshness #25/feat(runtime): persist compute inventory snapshots #26), bounded collection (Run bounded background collection for Runtime Adapter Compute inventory #29), read-only admin API (Expose latest Runtime Adapter Compute inventory through a read-only admin API #30), and Compute/GPU dashboard (Add a Runtime Adapter Compute and GPU inventory dashboard #31), followed by desired/observed Deployment lifecycle and only then policy-bounded placement.
• Prioritize activation, Provider onboarding and capability evidence, explainable routing/resilience, content-free OpenTelemetry-compatible signals, and exact cost provenance before semantic routing, semantic cache, broad protocol expansion, or online learning.
• Define cache and guardrail extension boundaries as opt-in policy components with tenant isolation, privacy, retention, deterministic bypass, and fail-mode contracts; do not claim they ship.
• State deliberate non-goals: public relay/reseller billing, recharge codes, opaque group/model multipliers, payment processing, hosted multi-tenancy, Provider-count races, silent protocol downgrade, prompt-content telemetry, and automatic GPU mutation before reconciliation evidence.
• Include measurable milestone gates and a concise dependency map, update existing roadmap/architecture links, and avoid claiming unimplemented APIs or enterprise/HA readiness.
• Make no runtime, API, schema, CI, dependency, or dashboard code changes in this documentation slice.