Update README.md

README.md

@@ -1,67 +1,582 @@
----
-base_model: unsloth/Llama-3.2-3B-Instruct
-library_name: peft
-pipeline_tag: text-generation
-tags:
-- lora
-- unsloth
-- grpo
-- reinforcement-learning
-- devops
-- incident-response
----
-
-# ARIA — DevOps Incident Response Agent
-### Llama-3.2-3B fine-tuned with GRPO
-
-Fine-tuned on the [ARIA DevOps Incident Response](https://huggingface.co/spaces/Arijit-07/devops-incident-response) 
-RL environment using Group Relative Policy Optimization (GRPO).
-
-## Training Details
-
-- **Algorithm:** GRPO (Group Relative Policy Optimization)
-- **Base model:** Llama-3.2-3B-Instruct
-- **Fine-tuning:** Unsloth LoRA (rank=16, alpha=32, 4-bit quantized)
-- **Episodes:** 140 across easy + medium tasks
-- **Training time:** ~10 hours on Kaggle T4 x2
-- **Environment:** Live DevOps incident response simulation
-
-## What the Agent Learns
-
-The agent is trained to respond to production software incidents by:
-1. Gathering information (read_logs, read_metrics, search_logs)
-2. Diagnosing the root cause before acting
-3. Applying the correct fix (restart, rollback, scale_up, block_ip etc.)
-4. Avoiding collateral damage to healthy services
-
-## Environment
-
-7 task types of escalating difficulty:
-- **Easy:** Single service OOM crash-loop
-- **Medium:** Cascading connection pool failure
-- **Hard:** Silent data corruption (all services green)
-- **Bonus:** Two simultaneous independent failures
-- **Security:** DDoS botnet credential stuffing
-- **Database:** Missing index causing full table scans
-- **Failover:** Multi-region network partition
-
-14 action types · Dense reward shaping · Partial log observability · SLA degradation per step
-
-## Links
-- **Live environment:** https://huggingface.co/spaces/Arijit-07/devops-incident-response
-- **Interactive API:** https://arijit-07-devops-incident-response.hf.space/docs
-- **GitHub:** https://github.com/Twilight-13/devops-incident-response
-
-## Usage
-
-```python
-from peft import PeftModel
-from transformers import AutoModelForCausalLM, AutoTokenizer
-
-base = AutoModelForCausalLM.from_pretrained(
-    "unsloth/Llama-3.2-3B-Instruct",
-    load_in_4bit=True
-)
-model = PeftModel.from_pretrained(base, "Arijit-07/aria-devops-llama3b")
-tokenizer = AutoTokenizer.from_pretrained("Arijit-07/aria-devops-llama3b")
-```
+---
+title: ARIA DevOps Incident Response
+emoji: 🚨
+colorFrom: blue
+colorTo: red
+sdk: docker
+pinned: true
+license: apache-2.0
+tags:
+  - openenv
+  - reinforcement-learning
+  - devops
+  - incident-response
+  - rl-environment
+  - multi-agent
+  - llm-agent
+  - grpo
+  - curriculum-learning
+  - huggingface
+  - pytorch
+  - meta
+short_description: RL environment for DevOps incident response agents
+---
+
+
+# ARIA — DevOps Incident Response
+### *The first OpenEnv RL environment for production incident response*
+
+[![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/Twilight-13/devops-incident-response/blob/main/train_grpo.ipynb)
+[![HF Space](https://img.shields.io/badge/🤗-Live%20Environment-orange)](https://huggingface.co/spaces/Arijit-07/devops-incident-response)
+[![Trained Model](https://img.shields.io/badge/🤗-Trained%20Model-blue)](https://huggingface.co/Arijit-07/aria-devops-llama3b)
+[![License](https://img.shields.io/badge/License-Apache_2.0-green.svg)](LICENSE)
+
+> **ARIA** — Adaptive Reward & Incident Architecture  
+> Built for the Meta × PyTorch × HuggingFace OpenEnv Hackathon Finals | Bangalore, April 2026
+
+---
+
+## 🔗 Quick Links for Judges
+
+| Resource | Link |
+|---|---|
+| **Live Environment** | https://arijit-07-devops-incident-response.hf.space |
+| **Interactive API (Swagger)** | https://arijit-07-devops-incident-response.hf.space/docs |
+| **Trained Model (Llama-3B LoRA)** | https://huggingface.co/Arijit-07/aria-devops-llama3b |
+| **Training Curve** | https://huggingface.co/Arijit-07/aria-devops-llama3b/resolve/main/training_curve.png |
+| **HuggingFace Blog** | https://huggingface.co/blog/Arijit-07/aria-devops-incident-response |
+| **GitHub** | https://github.com/Twilight-13/devops-incident-response |
+| **Validate (self-test)** | https://arijit-07-devops-incident-response.hf.space/validate |
+
+---
+
+## ⚡ Run a Complete Episode Right Now
+
+```bash
+# 1. Start an easy incident
+curl -X POST https://arijit-07-devops-incident-response.hf.space/reset \
+  -H "Content-Type: application/json" \
+  -d '{"task_id": "easy", "seed": 42}'
+
+# 2. Read logs on the failing service (reward: +0.15)
+curl -X POST https://arijit-07-devops-incident-response.hf.space/step \
+  -H "Content-Type: application/json" \
+  -d '{"action_type": "read_logs", "service": "payment-service"}'
+
+# 3. Diagnose the root cause (reward: +0.30)
+curl -X POST https://arijit-07-devops-incident-response.hf.space/step \
+  -H "Content-Type: application/json" \
+  -d '{"action_type": "diagnose", "root_cause": "memory leak in payment-service"}'
+
+# 4. Fix it (reward: +0.40)
+curl -X POST https://arijit-07-devops-incident-response.hf.space/step \
+  -H "Content-Type: application/json" \
+  -d '{"action_type": "restart_service", "service": "payment-service"}'
+
+# 5. See the final score
+curl https://arijit-07-devops-incident-response.hf.space/state
+
+# 6. Validate all 7 tasks pass
+curl https://arijit-07-devops-incident-response.hf.space/validate
+```
+
+```python
+# Or install and use the Python client
+pip install git+https://github.com/Twilight-13/devops-incident-response.git
+
+from devops_incident_response import DevOpsIncidentEnv, Action, ActionType
+
+env = DevOpsIncidentEnv(task_id="easy", seed=42)
+obs = env.reset()
+result = env.step(Action(action_type=ActionType.READ_LOGS, service="payment-service"))
+print(f"Reward: {result.reward}")  # 0.15
+```
+
+---
+
+## 🎯 The Problem This Solves
+
+Every software company running microservices faces the same brutal reality: **production incidents are expensive, unpredictable, and happen at 3am.**
+
+A single SEV-1 incident — a payment service crashing, a data corruption silently corrupting prices, a DDoS botnet overwhelming your login endpoint — can cost millions and require hours of expert engineer time to diagnose and fix. On-call rotations are stressful. Tier-2 incidents that follow recognizable patterns are handled by engineers when they could, in principle, be handled by an AI agent.
+
+**Yet no RL benchmark exists for this domain.**
+
+SWE-bench tests code generation. WebArena tests web navigation. AgentBench tests general tool use. None of them model **operational intelligence** — the ability to reason under uncertainty about live production systems, gather information strategically, and take precise actions where wrong choices cause additional damage.
+
+ARIA fills that gap.
+
+---
+
+## 🏗️ Environment Architecture
+
+ARIA simulates a production microservices e-commerce platform. Agents interact with the environment through a standard OpenEnv API: `reset()`, `step()`, `state()`.
+
+### What the Agent Observes
+
+Each step returns a structured `Observation` object:
+
+```
+Observation
+├── step, max_steps, task_id, task_description
+├── services: List[ServiceStatus]
+│   ├── name, status (healthy/degraded/down/unknown)
+│   ├── cpu_percent, memory_percent
+│   ├── error_rate, latency_p99_ms
+│   ├── replicas_running, replicas_desired
+│   ├── current_version, last_deployed
+│   └── sla_breach, minutes_degraded        ← SLA tracking per step
+├── active_alerts: List[Alert]              ← may include red herrings
+├── recent_logs: Dict[str, List[str]]       ← PARTIAL: only 2 lines shown
+├── service_dependencies: List[ServiceDependency]  ← call topology
+├── evidence_log: List[EvidenceEntry]       ← accumulates across steps
+├── sla_status: Dict[str, str]              ← ok/warning/breached
+└── available_runbooks: List[str]
+```
+
+**Key design: Partial Log Observability**
+
+The agent only sees 2 log lines per service upfront. Full history requires calling `read_logs` explicitly. This models real observability tools (Datadog, Kibana) where engineers run queries — agents must develop a search strategy, not just read everything.
+
+### The Services
+
+| Service | Stack | Role |
+|---|---|---|
+| `api-gateway` | Go | Routes external requests |
+| `payment-service` | Java (Spring) | Processes payments |
+| `order-service` | Python | Creates and tracks orders |
+| `inventory-service` | Java | Manages product stock |
+| `user-service` | Node.js | Auth and profiles |
+| `notification-service` | Python | Email and push alerts |
+| `data-pipeline-service` | Python | Writes catalog data |
+| `product-catalog-service` | Go | Stores and serves product data |
+| `price-validation-service` | Python | Validates prices |
+| `analytics-service` | Python | Aggregates business metrics |
+| `ml-inference-service` | Python | Serves recommendation models |
+| `log-aggregator` | Go | Collects and stores logs |
+
+### Service Dependency Map
+
+Every observation includes the call topology — agents can trace cascades:
+
+```
+api-gateway → order-service → inventory-service
+api-gateway → payment-service
+order-service → notification-service
+data-pipeline-service → product-catalog-service → price-validation-service
+```
+
+---
+
+## 🎬 The 7 Tasks
+
+### Task 1 — Single Service OOM (`easy`)
+**Max steps: 15 | Expected strong LLM: 0.85–1.00 | Random agent: 0.05**
+
+One service crash-loops with an OutOfMemoryError. The affected service rotates by seed across payment-service, order-service, and user-service — with different log formats (Java heap errors, Python memory errors, Node.js heap dumps). A secondary circuit-breaker alert fires on api-gateway as a visible symptom.
+
+**What makes it interesting:** The agent must identify the ROOT cause service (the one running out of memory) not the SYMPTOM services (everything downstream that's erroring because the root is down).
+
+**Optimal sequence:** `read_logs` → `read_metrics` → `diagnose` → `restart_service`  
+**Reward breakdown:** +0.10 read_logs, +0.10 read_metrics, +0.30 diagnose, +0.40 restart = **0.99 with efficiency bonus**
+
+---
+
+### Task 2 — Cascading Failure (`medium`)
+**Max steps: 20 | Expected strong LLM: 0.55–0.75 | Random agent: 0.03**
+
+A bad deployment of `inventory-service` causes connection pool exhaustion, cascading timeouts to `order-service` and elevated error rates on `api-gateway`. **Red herring:** a `notification-service` HIGH CPU alert fires (scheduled batch job — completely unrelated).
+
+**What makes it interesting:** The agent must follow the dependency chain backwards. Three services are visibly failing, but only one is the root cause. Touching the wrong service gives -0.15 collateral damage penalty.
+
+**Optimal sequence:** Investigate `api-gateway` → trace to `order-service` → trace to `inventory-service` → `rollback`  
+**Reward breakdown:** +0.20 trace cascade, +0.05 runbook, +0.25 diagnose, +0.35 rollback = **0.92**
+
+---
+
+### Task 3 — Silent Data Corruption (`hard`)
+**Max steps: 25 | Expected strong LLM: 0.30–0.50 | Random agent: 0.01**
+
+**All services show green.** Zero error rates. Normal latency. No standard alerts. The signal is buried in:
+- `price-validation-service` WARN logs: 15% price mismatch rate (baseline: 0.2%)
+- `analytics-service` anomaly: avg order value $847 vs $89 historical baseline
+
+Three noise alerts distract: TLS renewal, analytics backlog, replica lag.
+
+**What makes it interesting:** This requires qualitatively different reasoning — ignoring green health checks, correlating subtle business metric anomalies, and understanding that a data pipeline deployment 2 minutes ago is the causal explanation.
+
+**Full credit requires BOTH:** `rollback(data-pipeline-service)` AND `alert_oncall` (data audit needed)  
+**Reward breakdown:** +0.15 subtle signals, +0.10 pipeline metrics, +0.05 runbook, +0.20 diagnose, +0.25 rollback, +0.15 alert_oncall = **0.87**
+
+---
+
+### Task 4 — Dual Simultaneous Failure (`bonus`)
+**Max steps: 25 | Expected strong LLM: 0.35–0.55 | Random agent: 0.01**
+
+Two completely independent failures at once:
+1. `log-aggregator` disk 100% full — dropping 48k log messages/min
+2. `ml-inference-service` stuck in model checksum reload loop — CPU 99%+
+
+**What makes it interesting:** Neither failure is related to the other. Solving one doesn't help the other. The agent must decompose and fix independently. This tests whether agents can maintain multiple hypotheses simultaneously.
+
+**Full credit requires BOTH:** `alert_oncall` (disk cleanup) AND `rollback/restart(ml-inference-service)`  
+**Optimal score: ~0.77**
+
+---
+
+### Task 5 — Security Incident: DDoS (`security`)
+**Max steps: 20 | Expected strong LLM: 0.40–0.60 | Random agent: 0.01**
+
+A botnet is targeting the login endpoint with 12,000 req/s from the `185.220.x.x` IP range. Standard rate limiting is ineffective (distributed attack). The access logs show 1,847+ failed login attempts per 60 seconds from that range.
+
+**New action: `block_ip_range`** — models real network-level DDoS mitigation.  
+**Wrong actions:** Restarting api-gateway won't help. Scaling up won't help. Must block at network level + escalate to security team.
+
+**Full credit:** `block_ip_range("185.220.0.0/16")` AND `alert_oncall`  
+**Optimal score: ~0.80**
+
+---
+
+### Task 6 — Database Degradation (`database`)
+**Max steps: 20 | Expected strong LLM: 0.45–0.65 | Random agent: 0.01**
+
+A schema migration added a `user_segment` column to the `orders` table 15 minutes ago — without an index. Every query is now doing a full sequential table scan. DB CPU is spiking. The slow query log shows `seq_scan on orders (847ms)`.
+
+**New action: `create_index`** — models real DBA response to missing indexes.  
+**Alternative fix:** Rolling back the migration is also accepted for full credit.
+
+**Optimal score: ~0.80**
+
+---
+
+### Task 7 — Multi-Region Failover (`failover`)
+**Max steps: 25 | Expected strong LLM: 0.35–0.55 | Random agent: 0.01**
+
+A network partition affects `us-east-1`. Four services support automatic failover to `us-west-2` and should be switched. Two services MUST NOT be failed over:
+- `payment-service` — PCI-DSS compliance requires human approval
+- `postgres-primary` — replication lag risk causes data loss
+
+**New action: `failover`** — with `target_region` parameter.  
+**Heavy penalty: -0.25 per wrong service.** Failing over payment or postgres is catastrophic.
+
+**The runbook explicitly lists which services are safe** — reading it first is rewarded.  
+**Optimal score: ~0.70**
+
+---
+
+### Task 8 — Generated Incident (`generated`)
+**Max steps: 20 | Variable difficulty | Seed-deterministic**
+
+The Incident Generator creates procedural incidents from any integer seed (0–99,999). Same seed always produces the same incident. Different seeds produce unique combinations of:
+- 6 failure modes × 8 services × 3 severity levels × 0–3 noise alerts
+
+```bash
+# Preview any incident before running it
+curl "https://arijit-07-devops-incident-response.hf.space/generate/preview?seed=12345"
+
+# Run it as a full episode
+curl -X POST .../reset -d '{"task_id":"generated","seed":12345}'
+```
+
+---
+
+## 🏆 Reward Function Design
+
+### The Formula
+
+```
+Final Score = Σ(step_rewards)
+            + efficiency_bonus          # (1 - steps/max_steps) × 0.05 if resolved
+            + diagnosis_precision_bonus # +0.03 if ≥50% keyword overlap, +0.01 if ≥30%
+            - noop_penalty             # (noop_count - 3) × 0.02
+            - repeat_restart_penalty   # (restarts - 1) × 0.05 per service
+```
+
+All scores clamped to **(0.001, 0.999)** — never exactly 0 or 1.
+
+> **Why (0.001, 0.999) not (0, 1)?** GRPO advantage normalization requires non-constant rewards within a group. Hard 0 or 1 creates zero-variance groups where the model doesn't update. The tiny clamp ensures a gradient signal always exists.
+
+### Step-Level Rewards
+
+| Action | Reward | Condition |
+|---|---|---|
+| `read_logs` (failing service) | +0.10–0.15 | First time only |
+| `read_metrics` (failing service) | +0.10 | First time only |
+| `read_runbook` (relevant) | +0.05 | Correct runbook for scenario |
+| `search_logs` (relevant query) | +0.05 | Query returns useful results |
+| `diagnose` (full match) | +0.30–0.35 | ≥50% keyword overlap |
+| `diagnose` (partial match) | +0.10–0.15 | ≥30% keyword overlap |
+| `restart_service` (correct) | +0.35–0.45 | Root cause service |
+| `rollback` (correct) | +0.30–0.40 | Root cause service |
+| `block_ip_range` (correct) | +0.40 | Security task, correct CIDR |
+| `create_index` (correct) | +0.40 | Database task, correct table/column |
+| `failover` (eligible service) | +0.30 | Per correctly failed-over service |
+| `alert_oncall` (required) | +0.15 | Hard/security/database/failover tasks |
+
+### Penalties (Anti-Gaming)
+
+| Action | Penalty | Why |
+|---|---|---|
+| Restart healthy service | -0.15 | Collateral damage — realistic cost |
+| Fix without diagnosing | -0.10 | Blind remediation — models real risk |
+| Failover payment-service | -0.25 | PCI-DSS compliance violation |
+| Failover postgres-primary | -0.25 | Data loss risk |
+| Excessive noops (>3) | -0.04/each | Forces active investigation |
+| Repeat restart same service | -0.05/extra | Discourages guess-and-check |
+
+### Semantic Diagnosis Matching
+
+The `diagnose` action uses **keyword overlap** not exact string matching. An agent saying "memory exhaustion in payment-service" correctly matches the ground truth "memory_leak_payment_service". This is critical for LLM agents that paraphrase — exact string matching would unfairly penalize valid diagnoses.
+
+### SLA Degradation
+
+Every step where an incident is unresolved, the environment worsens:
+- `down` services: error_rate increases
+- `degraded` services: latency_p99 increases
+- SLA status: `ok` → `warning` (~3 steps) → `breached` (~7 steps)
+
+This creates real time pressure and rewards faster resolution.
+
+---
+
+## 🌟 ARIA Features
+
+### Curriculum Engine
+
+The Curriculum Engine tracks agent performance per task using a rolling average of the last 5 episodes.
+
+- **Promotion:** rolling_avg > 0.75 → advance mastery level (Novice → Intermediate → Advanced → Mastered)
+- **Demotion:** rolling_avg < 0.30 → step back mastery level
+- **Scaffolding:** if avg < 0.30 over 3+ episodes → provide task-specific hint
+
+```bash
+GET /curriculum/status    # See mastery per task
+GET /curriculum/next      # Get recommended next task
+GET /curriculum/hint/easy # Get scaffolding hint for a task
+POST /curriculum/record   # Feed your training results in
+```
+
+**Why this matters for training:** RL fails when agents never see successful trajectories. The curriculum ensures agents always train at the edge of their capability — easy tasks first, harder tasks as they master the fundamentals.
+
+### Incident Generator
+
+Procedural incident generation from seeds. 6 failure modes × 8 services × 3 severities × 0–3 noise alerts = thousands of unique training scenarios.
+
+**Difficulty formula:** `base_difficulty[failure_mode] + (noise_count × 0.05)`, clamped to 1.0
+
+| Failure Mode | Base Difficulty |
+|---|---|
+| oom | 0.20 |
+| cascade | 0.50 |
+| database | 0.60 |
+| security | 0.60 |
+| network_partition | 0.70 |
+| corruption | 0.80 |
+
+```bash
+GET /generate/preview?seed=42     # Preview without starting
+POST /reset  # body: {"task_id":"generated","seed":42}
+```
+
+### Dual-Agent Mode
+
+One incident. Two agents. Split observability.
+
+- **Agent A (Observer):** Sees logs, alerts, evidence. Can ONLY call `share_finding` — passes natural language observations to Agent B. Reward: +0.05 per finding.
+- **Agent B (Responder):** Sees metrics, service dependencies, SLA status. Cannot see logs directly. Must rely on Agent A's findings. Executes all real actions.
+
+Neither agent can solve the incident alone.
+
+```bash
+# Start a dual-agent session
+POST /multi-agent/reset  {"task_id":"easy","seed":42}
+# → returns session_id + split observations
+
+# Agent A shares a finding
+POST /multi-agent/step/a/{session_id}  {"finding":"payment-service OOM, memory at 98%"}
+
+# Agent B takes action (has access to Agent A's findings)
+POST /multi-agent/step/b/{session_id}  {"action_type":"restart_service","service":"payment-service"}
+
+# See full session state
+GET /multi-agent/state/{session_id}
+```
+
+---
+
+## 🧠 Training
+
+### Model
+
+**Llama-3.2-3B-Instruct** fine-tuned with **GRPO** (Group Relative Policy Optimization) using HuggingFace TRL and Unsloth.
+
+- **LoRA:** rank=16, alpha=32, targeting all 7 projection layers
+- **Adapter size:** ~97MB
+- **Training:** 140 episodes (easy + medium tasks) on Kaggle T4 x2 GPUs
+- **Model repo:** https://huggingface.co/Arijit-07/aria-devops-llama3b
+
+### Why GRPO?
+
+GRPO eliminates the value network that PPO requires. For environment-based RL where rewards come from an external API, a value model adds complexity without benefit. GRPO estimates the baseline from a group of 6 completions per step — simpler, more memory-efficient, and well-suited to fast environment APIs.
+
+### Training Loop
+
+```python
+# Each training step:
+# 1. Generate 6 completions for the current observation
+# 2. Score each on a FRESH env snapshot (prevents reward gate exhaustion)
+# 3. Normalize rewards to advantages (GRPO)
+# 4. Policy gradient update on best completion + KL penalty
+# 5. Advance episode with best action
+
+# Key hyperparameters:
+learning_rate = 5e-6
+group_size = 6
+kl_coefficient = 0.05   # prevents catastrophic forgetting
+update_strategy = "episode-level"  # one update per full episode
+```
+
+### Results
+
+| | Base Model | Fine-tuned (ep140) |
+|---|---|---|
+| **Easy task** | 0.000 | 0.150 |
+| **Behavior** | Jumps to diagnose immediately | Reads logs on correct service first |
+| **Why the difference** | Base model triggers blind remediation penalty | Fine-tuned model learned to gather information before acting |
+
+**The trained model consistently reads logs on the failing service before acting** — this is the foundational operational behavior: information gathering before remediation. The base model never does this.
+
+**Training challenge identified:** The original training loop called `env_step` during group generation, burning reward gates before the best action could advance the episode. After fixing to score completions on fresh environment snapshots, the model successfully learned step 1 of the optimal policy. With more episodes using the corrected loop, the full sequence would emerge.
+
+### Training Notebook
+
+See `train_grpo.ipynb` — Colab-compatible, runs against the live HF Space API (no local setup needed).
+
+[![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/Twilight-13/devops-incident-response/blob/main/train_grpo.ipynb)
+
+Compatible with: TRL, SkyRL, ART, Oumi, Axolotl.
+
+---
+
+## 🚀 Setup
+
+### Docker (Recommended)
+
+```bash
+docker build -t aria-devops-incident .
+docker run -p 7860:7860 aria-devops-incident
+curl http://localhost:7860/health
+```
+
+### Local Python
+
+```bash
+pip install -r requirements.txt
+uvicorn api:app --host 0.0.0.0 --port 7860
+```
+
+### Validate
+
+```bash
+python validate.py    # 22 automated checks, exit 0 = all pass
+curl http://localhost:7860/validate
+```
+
+---
+
+## 📡 API Reference
+
+| Method | Endpoint | Description |
+|---|---|---|
+| GET | `/health` | `{"status":"ok"}` liveness check |
+| GET | `/about` | Full environment description (machine-readable) |
+| GET | `/tasks` | All 8 tasks with descriptions |
+| POST | `/reset` | Start episode: `{"task_id":"easy","seed":42}` |
+| POST | `/step` | Take action: Action JSON |
+| GET | `/state` | Full state + ground truth + analytics |
+| GET | `/validate` | Self-test: random agent on all 7 tasks |
+| GET | `/metrics` | Aggregate episode statistics |
+| GET | `/leaderboard` | Top 10 episodes |
+| WS | `/ws` | WebSocket: real-time agent-environment |
+| GET | `/curriculum/status` | Per-task mastery and recommendations |
+| GET | `/curriculum/next` | Recommended next task for training |
+| GET | `/curriculum/hint/{task_id}` | Scaffolding hint for struggling agents |
+| POST | `/curriculum/record` | Feed episode result to curriculum engine |
+| GET | `/generate/preview` | Preview procedural incident: `?seed=N` |
+| POST | `/multi-agent/reset` | Start dual-agent session |
+| POST | `/multi-agent/step/a/{id}` | Agent A shares a finding |
+| POST | `/multi-agent/step/b/{id}` | Agent B takes an action |
+| GET | `/multi-agent/state/{id}` | Full dual-agent session state |
+| GET | `/multi-agent/sessions` | List active sessions |
+| GET | `/docs` | Swagger UI — interactive documentation |
+
+---
+
+## 📊 Benchmark Comparison
+
+| Benchmark | Domain | Partial Obs | Dense Reward | Multi-Step | Curriculum | Multi-Agent |
+|---|---|---|---|---|---|---|
+| SWE-bench | Code repair | ✗ | ✗ | ✓ | ✗ | ✗ |
+| WebArena | Web navigation | ✓ | ✗ | ✓ | ✗ | ✗ |
+| AgentBench | General tools | ✗ | ✗ | ✓ | ✗ | ✗ |
+| **ARIA (ours)** | **Incident response** | **✓** | **✓** | **✓** | **✓** | **✓** |
+
+---
+
+## 🏗️ OpenEnv Compliance
+
+```bash
+openenv validate .
+```
+
+- Inherits from `openenv.core.env_client.EnvClient`
+- Standard `reset()`, `step()`, `state()` interface
+- Valid `openenv.yaml` manifest with all 8 tasks
+- FastAPI server with health endpoint
+- WebSocket support at `/ws`
+- Hosted on HuggingFace Spaces
+
+---
+
+## 📁 Repository Structure
+
+```
+aria-devops-incident-response/
+├── api.py                    # FastAPI app — all endpoints
+├── env.py                    # DevOpsIncidentEnv — thin dispatcher
+├── models.py                 # Pydantic models — Action, Observation, State
+├── tasks/
+│   ├── base.py               # BaseTask ABC, InternalState, reward logic
+│   ├── task_easy.py          # OOM crash-loop
+│   ├── task_medium.py        # Cascading failure
+│   ├── task_hard.py          # Silent data corruption
+│   ├── task_bonus.py         # Dual simultaneous failure
+│   ├── task_security.py      # DDoS attack
+│   ├── task_database.py      # Missing index
+│   ├── task_failover.py      # Multi-region failover
+│   └── task_generated.py     # Procedural incidents
+├── curriculum/
+│   └── engine.py             # CurriculumEngine — adaptive difficulty
+├── generator/
+│   └── incident_factory.py   # IncidentFactory — procedural generation
+├── multi_agent/
+│   └── session.py            # DualAgentSession — split observability
+├── graders/
+│   └── grader.py             # Deterministic episode grader
+├── data/runbooks/            # 6 operational runbooks (Markdown)
+├── client.py                 # openenv-core EnvClient implementation
+├── inference.py              # LLM baseline (CoT + fast modes)
+├── train_grpo.ipynb          # GRPO training notebook (Colab-compatible)
+├── validate.py               # 22 automated validation checks
+└── openenv.yaml              # OpenEnv spec manifest
+```
+
+---
+
+## 📝 License
+
+Apache 2.0
+
+---
+
+*Built solo for the Meta × PyTorch × HuggingFace OpenEnv Hackathon Finals — Bangalore, April 2026*