How it works
A closed loop that earns control one measured action at a time.
Cirra never asks for trust up front. It starts read-only, proves every policy in simulation against your own history, and executes only what you approve — measuring every single outcome.
Observe
A cluster agent installs via signed Helm chart into a dedicated namespace and watches Kubernetes objects, Slurm queue and node state, Prometheus metrics, and NVIDIA DCGM telemetry. No mutation verbs. No workload content. Raw telemetry never has to leave your environment.
Kubernetes API · Slurm · Prometheus · DCGM · optional SLO & billing signals
Model
Cirra builds the canonical graph of your fleet — every service, pod, GPU, node, rack, and power domain, with point-in-time history. Workloads are profiled with rolling distributions, and flexibility is inferred conservatively; explicit operator policy always wins.
98%+ GPU allocation attribution · versioned workload profiles
Forecast
Demand, queue pressure, job completion, and required node count are predicted at 15, 30, 60, and 120-minute horizons. Every forecast carries a distribution and prediction interval — the optimizer never sees a bare point estimate.
seasonal quantiles · conformal intervals · drift monitoring
Simulate
Candidate rightsizing, admission, placement, consolidation, and node-state plans are replayed against your real history in a discrete-event simulator using only decision-time information. Uncertainty makes plans less aggressive, never more.
no look-ahead bias · reproducible under fixed seeds
Approve
Every plan arrives with expected impact, SLO risk, confidence, transition costs, reserve requirements, rollback conditions, and the precise cluster objects affected. You approve the exact scope, window, and abort conditions — or reject it with one click.
hard constraints evaluated before expected value, always
Execute
A separate, disabled-by-default execution controller applies one reversible scheduler action class — Kubernetes or Slurm — repeatedly, typically 10–20 runs over the final 7–14 days. Deterministic guardrails monitor SLOs continuously and roll back without asking a model for permission.
least-privilege service account · idempotent · time-bounded
Verify
Every run is compared against its prediction and a frozen baseline: completed work, queue behavior, capacity, powered-node-hours, energy. The campaign-level error distribution becomes the evidence that unlocks production automation.
immutable ActionRun ledger · predicted vs. measured, always reported
The unit of trust
Every action is a contract, not a suggestion.
An ActionPlan names the exact cluster objects affected, the expected impact on completed work and energy, the probability of SLO regression, and the deterministic rollback trigger. You approve precisely this — scope, window, and abort conditions — and nothing else can run.
- ✓Plans expire when cluster state or policy drifts beyond tolerance
- ✓Guardrail breach forces rollback — no model in the loop
- ✓Every mutation is recorded in an immutable audit ledger
Architecture
Runs in your cluster. Built to fail closed.
Collector and executor are separate identities. Failure of any Cirra component can never affect Kubernetes or Slurm scheduling or your workloads.
Cluster Agent
Your clusterWatches resources and telemetry with read-only RBAC. Enforces egress policy — deny by default.
Intelligence Engine
Local by defaultProfiles workloads, forecasts demand, generates candidates, simulates, and ranks every plan.
Policy & Safety Engine
Your clusterDeterministic hard constraints: reserve floors, exclusions, isolation, allowlists, abort rules. Evaluated before expected value.
Execution Controller
Disabled by defaultSeparate least-privilege identity. Applies only operator-approved canary actions and rolls back on guardrail breach.
Web UI / API
Local serviceFleet views, counterfactual timelines, approvals, execution status, verified outcomes, and exports.
Outcome Ledger
Append-onlyImmutable ActionRuns, mutations, guardrail events, and prediction variance — your compounding control dataset.
The autonomy ladder
Autonomy is earned with evidence — never assumed.
Each level of authority unlocks only after the previous one produces a verified, campaign-level action history.
Observe
Read telemetry and model the cluster
Shadow
Continuous plans and frozen counterfactuals
Approved canary
Repeated bounded actions from one reversible class
Policy automation
Automatic low-risk allowlisted Kubernetes actions
Hardware coordination
GPU power profiles, server standby, predictive wake
Facility coordination
Safe cooling and energy targets from predicted demand
The pilot
30–45 days from install to a production control decision.
Qualify
Environment questionnaire, controllable-workload check (≥70%), and one lead value route selected: throughput or energy. Success criteria and production pricing agreed before install.
Observe & shadow
Read-only baseline over at least one representative workload cycle. Frozen shadow policies and counterfactual replays accumulate evidence — weekly operator reviews included.
Canary campaign
One approved reversible action class executes 10–20 times in a bounded scope. Every run is measured against its prediction; guardrails and rollback are always armed.
Decide
A route-specific executive report with campaign-level distributions — and a pre-priced production control policy, ready to enable.
100–2,000 NVIDIA GPUs on Kubernetes or Slurm · one lead value route · agreed success criteria before install
Want the deeper safety story?
Safety & trust →