Capacity and Performance
Capacity work asks whether a resource can meet measured demand without wasting cost or exhausting a dependency. FDAI combines current utilization, forecast evidence, minimum floors, dependency checks, and promotion state before it can propose a scaling action.
Capacity evidence
Section titled “Capacity evidence”- Current utilization and saturation by resource and window.
- Demand trend, forecast horizon, uncertainty, and expected breach time.
- Minimum and maximum capacity plus warm-capacity floors.
- Quota, regional availability, and dependent-resource constraints.
- Workload SLO and error-budget impact.
- Cost estimate and rollback or scale-back path.
Missing or stale telemetry produces unavailable or held for review evidence. It does not produce a zero-demand assumption.
Decide without conflicting specialists
Section titled “Decide without conflicting specialists”Freyr evaluates capacity while Njord evaluates cost. Their advice can conflict, such as scale up for reliability versus scale down for efficiency. Specialists remain advisory; Forseti and the safety check apply the configured precedence and autonomy ceiling.
Forseti emits a cross-vertical arbitration request when advice conflicts. Odin applies the versioned priority policy from the rule catalog and returns one reproducible arbitration result before Forseti makes the decision. The default policy prefers SLO protection over cost and architecture advice, but a deployment can supply a reviewed policy without changing agent code. The arbitration result is evidence; it cannot relax a safety check ceiling.
Example: low utilization suggests scale-down while an SLO forecast shows an imminent capacity breach -> the configured priority policy preserves the SLO floor -> what-if still checks quota and dependencies -> the safety check decides observation mode, approval, or promoted execution.
Scaling proposal flow
Section titled “Scaling proposal flow”- A detector or scheduled evaluation emits a capacity detected issue.
- The detected issue correlates with workload SLO, current changes, and incidents.
- What-if verifies quota, dependencies, floors, and expected effect.
- A typed scale proposal carries scope, batch, rate, stop condition, and rollback.
- Observation mode evidence and promotion state determine whether the proposal can reach approval or promoted auto behavior.
Guardrails
Section titled “Guardrails”Never scale below a declared safety floor, strand a dependency, exceed quota, or treat a forecast as execution authority. Per-resource locks and bounded batch changes prevent competing scale actions from racing.
| Runtime check | If it passes | If it fails or is unknown |
|---|---|---|
| Demand and SLO evidence is fresh | Continue to what-if | Hold with unavailable evidence |
| Quota and dependency checks pass | Build a typed proposal | No proposal |
| Floor, batch, and rate limits hold | Continue to the safety check | Deny or reduce scope |
| Lock and idempotency claim succeed | Apply at most once | Retry safely or no-op |
| Stop condition remains healthy | Continue the bounded batch | Stop and follow rollback policy |
Next steps
Section titled “Next steps”| To learn about | Read |
|---|---|
| How forecasts are formed | Observability, detection, and forecasting |
| How workload impact is measured | SLOs and error budgets |
| How cost and capacity interact | Cost Governance |
| How actions are promoted | Observe, then enable changes |