🏆 BasisForce — Teaching AI to Save SAP Production Systems
Scaler × Meta × Hugging Face OpenEnv Hackathon 2026
We built the first SAP Basis RL environment, then trained a 7B model to resolve $1M/hr production incidents using SFT + GRPO.
Team: Rajeev Lokesh & Vignesh P — SAP BASIS GETs at HCLTech, Bengaluru
💥 The Problem Is Real
SAP systems run 77% of global transaction revenue — banking, manufacturing, healthcare, logistics. When they go down, companies lose $300,000–$1,000,000 per hour.
On-call SAP Basis admins have minutes to triage, isolate, and fix complex multi-system failures under SLA pressure. Wrong order of operations triggers cascading failures. Misidentifying a red herring alert wastes precious time.
We asked: can an RL agent learn to do this job?
This is the first SAP Basis operations environment in the OpenEnv ecosystem — grounded in real SAP transaction codes, real alert patterns, and real incident playbooks from 7 months of hands-on HCLTech experience.
🏭 The Environment
sap-enterprise-ops-env is an OpenEnv-compliant simulation of a live SAP PRD system. The agent sees exactly what an on-call admin sees.
No two episodes identical — IPs, timestamps, job names all randomise
💥 Cascading failures
Wrong fix spawns new alerts, testing causal reasoning
⏱️ SLA decay reward
Reward degrades over time, mirroring real enterprise pressure
🎭 Red herring alerts
One false positive per episode penalises pattern matching
🧠 Agent memory test
Task 3 references attacker IP from earlier in episode
📊 Rich partial rewards
Credit for correct diagnosis even if fix is wrong
📋 Three Tasks, Increasing Difficulty
Task 1 — Background Job Failure EASY
Scenario: A critical SAP background job aborted in PRD with return code 4
Agent must: Diagnose root cause → restart via SM37
Max steps: 5 | SLA: 300s | Baseline score:0.75
Task 2 — Transport Error + Security Anomaly MEDIUM
Scenario: Transport stuck in STMS queue and a suspicious RFC call from an external IP outside business hours
Agent must: Release transport and flag/block the security threat — two independent actions
Max steps: 8 | SLA: 480s | Baseline score:1.00
Task 3 — P1 Full Crisis Response HARD
Scenario: System down — DB timeout + memory dump + brute force attack simultaneously
Agent must: Fix in exact order: DB → memory → ICM → block attacker → escalate SOC
Wrong order triggers a cascade penalty (-0.25)
Max steps: 18 | SLA: 600s | Baseline score:0.71
⚖️ Reward Function
No sparse rewards — the agent gets credit for reasoning, not just correct outcomes.
reward =
diagnosis_score × 0.25 # Correct root cause stated
+ fix_score × 0.25 # Correct fix method used
+ sla_score × 0.20 # Speed — decays over time
+ sequence_score × 0.15 # Correct order (Task 3)
+ security_score × 0.15 # Security threat caught
penalties:
-0.30 destructive action (delete_job, reimport_transport)
-0.25 cascade triggered (wrong fix order in Task 3)
-0.15 false positive flagged (red herring acted on)
-0.20 wrong system targeted (QAS/DEV instead of PRD)
reward_range: [-0.75, +1.10]
Reward breakdown
Fig 1 — Reward function breakdown across the 5 scoring dimensions
🧠 Training Pipeline
We used Qwen2.5-7B-Instruct with 4-bit LoRA (r=32) — a model 10× smaller than the LLaMA-3.3-70B baseline. Two training phases, no large-scale compute needed. Runs on a T4 Colab.
Base Qwen2.5-7B → SFT (600 examples, 3 epochs) → GRPO (40 steps, live env) → Eval
Phase 1 — SFT: Teaching SAP Structure
The model had no SAP knowledge out of the box. SFT teaches it:
What a valid JSON action looks like
Which transaction codes map to which problems (SM37 for jobs, DB13 for DB, SMICM for ICM)
What reasoning a senior admin would write
We generated 200 examples per task (600 total) using perfect action sequences as ground truth, with 5 reasoning variations per step to prevent memorization. Strict JSON validation before each example enters the dataset.
GRPO (Group Relative Policy Optimisation) is where the model stops imitating and starts exploring. Each step it generates 2 completions, executes them in the live SAP env, and learns from the reward gap.
40 training steps. The signal from real environment rollouts is dense enough that the model moves meaningfully in a short run.
python
1grpo_cfg = GRPOConfig(2 max_steps=40,# sweet spot: real signal without OOM3 num_generations=2,4 learning_rate=3e-6,# slightly higher = faster improvement5 beta=0.005,# low beta = model explores more freely6 temperature=0.9,# more exploration over exploitation7 max_completion_length=60,8)
GRPO training progression
Fig 2 — GRPO reward and KL divergence over 40 training steps. KL at step 40 = 0.802, showing the model diverged meaningfully from the SFT checkpoint.
Fig 3 — Per-task scores across all pipeline stages. GRPO boosts Task 2 reward to 0.855 during training, reflecting improved exploration on the dual-action scenario.
Pipeline stage averages
Fig 4 — Average scores across training stages. The 7B model holds competitive performance vs a 70B oracle while being dramatically more practical to deploy.
📐 Why the Baseline Is Higher — And Why That's the Point
The baseline is not what we're trying to beat. It's what we're trying to understand.
The LLaMA-3.3-70B baseline scores 0.82 average. Our trained 7B model lands at 0.74. Doesn't that mean we failed?
No — and here's the key insight.
The baseline runs at temperature 0.0 — fully greedy, deterministic, using a 70B model with encyclopedic SAP knowledge baked in from pretraining. It's the ideal oracle: always picks the known-correct action, never explores, never makes multi-step mistakes in a live environment.
When we move to SFT and RL, the model is a 7B model operating in a real environment with multi-step dependencies and exploration. It has to:
Learn SAP knowledge from scratch (not pretrained on it at 70B scale)
Generate valid JSON reliably under uncertainty
Reason across 18-step episodes without cheating
Handle red herring alerts it's never seen before
Respect strict causal ordering or face cascade penalties
The baseline reflects ideal, rule-based behavior under controlled conditions. When we move to SFT and RL, the model operates in a real environment with multi-step dependencies and exploration. This makes the task more challenging, so the score slightly adjusts — but the model becomes significantly more robust and realistic.
The more interesting comparison isn't the 70B oracle vs our 7B model. It's GRPO vs SFT alone.
Learning curve vs baseline
Fig 5 — Left: agent learning progression vs rule-based upper bound. Right: gap to optimal closes faster with GRPO than SFT alone — RL exploration outpaces pure imitation.
GRPO consistently closes the gap to optimal faster. That's the real signal: the agent is learning to make decisions, not just memorizing patterns.
At GRPO step 40, KL divergence = 0.802. The model has moved meaningfully away from the SFT initialization — it's genuinely exploring the action space, not regressing to imitation.
The training loop makes real HTTP calls to the live environment during GRPO. Every reward signal comes from actual environment rollouts — not a simulator or proxy.
1# Correct sequence — deviate and cascade fires2CORRECT_ORDER =[3"reconnect_db",# Step 1 — root cause first4"clear_buffer",# Step 2 — memory, only after DB is fixed5"restart_icm",# Step 3 — ICM, only after memory is cleared6"block_ip",# Step 4 — contain the attacker7"escalate_soc",# Step 5 — full investigation8]9# clear_buffer before reconnect_db → -0.25 cascade penalty
