Concept

AI Runtime Control Plane

Quantlix is split into two surfaces: a runtime layer that lives in the request path and a control plane where you configure and inspect what the runtime does. Together they let teams deploy, control, observe, and evaluate production AI systems without stitching four tools together.

Why a control plane

AI is moving into production but most teams lack runtime control. Policies are scattered across services, observability is bolted on after the fact, evals run on someone's laptop, and provider routing is hard-coded. The result is fragmented: nobody can answer, in one place, what the AI is allowed to do, what it actually did, and whether it's still good enough to keep doing.

A control plane fixes that by giving every AI request one consistent runtime layer to flow through — and one consistent surface to configure and inspect that runtime.

The runtime layer

The runtime layer is the data path. Every request from your application to a model, tool, or knowledge source flows through it. Inside that single path, Quantlix runs:

Policy enforcement

Allow, block, redact, or budget-gate every request before it reaches a model.

Guardrails

PII detection, safety checks, schema validation, and feature contracts in the request path.

Budget control

Cap cost and usage at request time; refuse requests that would breach the limit.

Provider routing

Route, fall back, and A/B test across model providers without rewriting your application.

Workflow execution

Run multi-step pipelines: retrieval → generation → tool calls → approvals → response.

Eval hooks

Wire evals into the runtime so deployments can fail gracefully when quality regresses.

Trace capture

Emit a single timeline per request: every model call, tool call, policy decision, and eval result.

See runtime guarantees for the contract Quantlix offers at the request path.

The control plane

The control plane is where you configure and inspect what the runtime does. It is the management surface — dashboard, CLI, and API — for the runtime layer below it.

Deployments

Configure the AI systems that run through your runtime: which workflows, which models, which policies.

Policies

Author and version the rules the runtime enforces. Roll out, dry-run, and roll back.

Providers

Connect model providers, manage credentials, and define how AI traffic is routed.

Evals

Define quality gates, datasets, and suites; review results across versions.

Observability

Inspect traces, runs, citations, and policy outcomes from one console.

Audit logs

Export signed, audit-ready evidence of what the runtime did and why.

The four pillars

Every capability across both surfaces sits under one of four pillars. Reading the docs from this angle keeps the surface area small:

  • Deploy — turn workflows, models, retrieval, and tools into production-grade deployments.
  • Control — enforce policies, budgets, and guardrails at runtime in the request path.
  • Observe — capture traces, citations, and policy outcomes in one timeline per request.
  • Evaluate — gate changes with evals before they reach production, and catch regressions over time.

Where to go next

  • Architecture — request lifecycle, managed vs self-hosted, data flow, what Quantlix stores.
  • Quickstart — get a real request flowing through the runtime in a few minutes.
  • Runtime policies — how rules become enforced behavior at the request path.
  • Observability — what each trace contains and how to read it.
  • Evals — quality gates before changes reach production.