AFIE is an autonomous FinOps intelligence engine that right-sizes your Kubernetes workloads with reinforcement learning, guards every action behind a policy engine, and explains itself in plain English.
Most Kubernetes clusters run on requests set by engineers who guessed once, six months ago. The gap between what pods request and what they actually use is where cloud bills quietly grow — a problem too tedious for humans to solve continuously and too high-stakes to leave to naive autoscalers.
AFIE closes that loop. A PPO agent trained on the Azure Public Dataset proposes CPU and memory adjustments every 15 seconds. A Policy Constraint Language engine validates every proposal against safety rules. Approved changes ship as GitHub pull requests with SHAP explanations attached — humans stay in the loop for critical decisions, but the paperwork disappears.
PPO from Stable-Baselines3, pre-trained on 2.66M VM traces from the Azure Public Dataset, then fine-tuned online with a 70/30 live-to-offline replay buffer.
Every recommendation flows through a Policy Constraint Language engine. Four rules cover magnitude, headroom, deploy conflicts, and cooldown. The RL model never touches production directly.
SHAP KernelExplainer surfaces the top features driving each action. A template layer turns the vector into a sentence a human can read at 2 a.m. during an incident.
Approved actions ship as Helm patches via GitHub PRs, synced by Argo CD or Flux. A health checker watches P99 and error rate — SLO regressions revert the commit automatically.
Every 15 seconds telemetry lands, features rebuild, the RL agent proposes an action, the PCL engine checks the rules, and the operator opens a pull request. The stack never stops moving.
AFIE is built from mature, open-source pieces. Nothing exotic — each choice is one an SRE team could operate on day one.
The C# services that scrape, transform, and reconcile.
The reinforcement-learning brain and its explanations.
The cluster, observability, and GitOps controllers.
The dashboard for cost, actions, SLO, and human overrides.
Provisioned only in Phase 8.
Phases 1–7 run entirely on a laptop with KIND. Nothing is committed to Azure until every service works locally. Phases 8–9 provision cloud infrastructure and run the formal evaluation.
Everything runs locally on KIND. Prometheus, Grafana, the operator, and every service behave exactly as they will on Azure — you just don't pay for it yet.
Install every tool, create every account, scaffold the monorepo. Nothing else can start until this is done.
KIND cluster on the laptop, Prometheus and Grafana via Helm, Argo CD or Flux as the pluggable GitOps controller.
The data backbone. Scrapes Prometheus every 15 seconds and publishes enriched metric events every other component depends on.
Transform raw metrics into the 47-dimensional state the RL agent needs. The most mathematically careful phase in the project.
The brain. PPO from Stable-Baselines3 trained on the Azure Public Dataset, with a Gymnasium environment and SHAP explanations.
The most novel engineering piece. A C# operator validates every RL recommendation against Policy Constraint Language rules, then opens a GitHub PR.
The face of the system. Real-time savings, action history with SHAP, SLO heatmaps, and one-click human override.
Every service flips from local mode to cloud mode via one config switch. Terraform provisions Event Hub, Cosmos DB, Key Vault, and Static Web Apps. Formal experiments start here.
Provision Event Hub, Cosmos DB, Key Vault, and Static Web Apps. Flip services from local mode to cloud mode via a single config switch.
72-hour experiments across four baselines, Mann–Whitney significance testing, XAI human study, and submission to arXiv + IEEE TCC.
Every claim in the paper is backed by 12 experiment runs — three seeds across four configurations, each 72 hours long, with Mann–Whitney U tests and Cohen's d effect sizes.
Follow the build in the open — every commit, every experiment run, every figure that ends up in the paper.