Jayant2304
/

Commitment-os

@@ -16,297 +16,295 @@ tags:
 # CommitmentOS: Training LLMs to Keep Their Promises
-*The first RL environment for temporal commitment coherence — where an agent's own past decisions become binding constraints on its future ones.*
 ---
-## The Problem in One Sentence
-Ask an LLM to help you manage a busy day. Watch it book two meetings at the same time — because it forgot it already filled that slot three messages ago.
-This is not a hallucination. It is not a reasoning failure. It is a **temporal commitment coherence** failure — and until now, no RL training environment existed to address it.
 ---
-## How We Got Here: Round 1 → CommitmentOS
-In Round 1 of this hackathon, we built an environment for training LLMs on production incident response — SRE agents diagnosing alerts, running runbooks, escalating on-call. That environment asked: *can an LLM handle a production crisis?*
-Testing Round 1 exposed the follow-on question nobody had answered: **what happens when the production incident fires in the middle of a day full of existing commitments?**
-The SRE agent knows how to triage the incident. It has no idea what to do about the 3pm client call it already confirmed, the dinner reservation it already made, or the team update it already promised to send. It will silently abandon every prior commitment to handle the new crisis — with no communication to any affected party.
-That gap — between task competence and commitment coherence — is what CommitmentOS was built to close.
 ---
-## Why This Capability Gap Matters
-Every AI assistant today treats each action atomically. When you ask it to schedule a 3pm meeting in turn 2 and then book something else for 3pm in turn 7, it sees turn 7 in isolation. The prior commitment it made has no binding weight. It will double-book you without hesitation.
-The consequences scale with complexity. A simple day with one conflict is fine. A day with an investor dinner, overlapping personal commitments, cascading reschedule dependencies, and incoming urgent emails — the kind of day where AI assistance would actually help — is where current models fail systematically. **They forget their own word.**
-CommitmentOS trains the specific capability that prevents this: the ability to treat prior decisions as first-class constraints that persist across the full arc of a multi-turn episode.
 ---
-## The Core Innovation: The Commitment Ledger
-Every existing constraint-satisfaction environment computes its dependency graph upfront. CommitmentOS is architecturally different: **constraints emerge dynamically from the agent's own actions as the episode unfolds.**
 ```
-Turn 2:  Agent books 3pm Tuesday meeting
-         → Commitment ledger appends: {slot: "3pm_tuesday", blocked: true}
-Turn 5:  Agent promises to send team update email
-         → Commitment ledger appends: {type: "email_promise", to: "team"}
-Turn 9:  Agent books another 3pm Tuesday call
-         → Ledger detects: CONFLICT with commitment from turn 2
-         → Violation flagged: -0.15 intermediate penalty
-Turn 11: Agent reschedules original meeting, emails affected party with apology
-         → Ledger marks: commitment renegotiated at turn 11
-         → Full credit restored
 ```
-The ledger tracks three commitment states with distinct reward implications:
-| State | Description | Reward |
-|-------|-------------|--------|
-| **Honored** | Commitment kept through episode end | Full credit |
-| **Renegotiated** | Modified with explicit communication (email + apology + alternative) | Full credit |
-| **Silent violation** | Broken with no communication to affected parties | Zero credit |
-This single mechanism creates the training signal that existing environments cannot produce: a model that learns to honor its past self's decisions while managing an evolving present.
 ---
-## The Environment
-### 15 Scenarios Across 3 Difficulty Tiers
-**Easy (5 tasks, 2–4 steps):** Single-domain conflicts with clear resolution paths. Reschedule a double-booked meeting and notify the team. Book dinner with cuisine, price, and distance constraints. Triage an inbox by urgency.
-**Medium (5 tasks, 5–8 steps):** Cross-domain commitment chains where resolving one task creates constraints in another. A cascading reschedule where moving meeting A forces B which forces C. An urgent boss request arriving mid-client-call. A vague "push our thing" email that matches three different recurring events.
-**Hard (5 tasks, 8–15 steps):** Full commitment cascades with information asymmetry and crisis pressure:
-> **hard_011 — VP Investor Dinner Cascade**
-> Your VP asks you to host an investor dinner tonight. Your calendar has yoga at 6pm and a team happy hour at 7pm. The investor has a 9pm flight. The restaurant must be near the airport and accommodate a dietary restriction. Resolve every calendar conflict by priority, renegotiate existing social commitments with proper communication, find a compliant restaurant, and confirm logistics — all while maintaining a coherent commitment ledger throughout.
-> **hard_013 — Triple Crisis Recovery**
-> Three simultaneous failures: cancelled flight, moved board prep, lost restaurant reservation. The agent must recover all three without generating silent violations to any attendees already notified.
-> **hard_015 — Production Incident Interrupts the Day**
-> A PagerDuty alert fires mid-afternoon with 5 existing commitments active. Triage the incident, re-prioritize the day, and renegotiate every affected commitment with appropriate communication.
-### Tool Set
-Nine deterministic tools, one call per step:
-`view_calendar` · `check_availability` · `schedule_meeting` · `reschedule_event` · `cancel_event` · `send_email` · `search_restaurants` · `book_restaurant` · `submit_plan`
-Each tool call that advances constraint satisfaction gives a +0.05 intermediate reward. Actions that create conflicts give -0.05. The full 5-component evaluation fires on `submit_plan`.
-### Reward Function — ~95% Deterministic
-| Component | Weight | How It's Measured |
-|-----------|--------|-------------------|
-| Constraint Satisfaction | 35% | Binary check per constraint: met or not met |
-| Conflict Resolution | 20% | Final calendar free of overlapping events |
-| **Commitment Coherence** | **20%** | **(commitments − silent violations) / commitments** |
-| Communication Quality | 15% | Three binary checks: party notified, alternative proposed, new slot confirmed |
-| Step Efficiency | 10% | Penalty for steps beyond optimal |
-All scores clamped to (0.01, 0.99) to keep GRPO gradients alive throughout training.
-No LLM-as-judge. No rubric subjectivity. The commitment violation check is a direct lookup against the ledger state at episode end.
 ---
-## Training
-**Setup:**
-- Model: Qwen2.5-1.5B-Instruct + LoRA (rank 8, alpha 16)
-- Algorithm: GRPO via HuggingFace TRL `GRPOTrainer` + `environment_factory`
-- Compute: Google Colab A100
-- Protocol: seed=42, max_steps=12, temperature=0.0
-The training loop connects directly to the live CommitmentOS HTTP API. The model generates multi-turn tool sequences; the environment returns intermediate rewards from the Commitment Ledger at each step and a full 5-component score at episode completion.
-### Training Curves
-**GRPO Reward vs Training Step**
-![CommitmentOS GRPO Reward vs Step — upward trend from 0.48 early average to 0.63 late average, peaking at 0.69](reward_curve.png)
-*Reward climbs from an early-step average of **0.48** to a late-step average of **0.63** (+31%), peaking at **0.69** at step 28. Noise is characteristic of GRPO on small-batch multi-turn environments — the upward trend is consistent.*
-**GRPO Loss vs Training Step**
-![CommitmentOS GRPO Loss vs Step — rapid drop from 0.64 at step 1, stabilising near zero](loss_curve.png)
-*Loss drops sharply from 0.64 to near-zero within 5 steps as the policy moves away from the degenerate "submit immediately" behaviour. Oscillation after step 5 reflects policy exploration in a high-variance multi-turn action space.*
-**Key training statistics:**
-| Metric | Value |
-|--------|-------|
-| Total training steps | 30 (≈2 epochs) |
-| Early-step mean reward (steps 1–5) | 0.48 |
-| Late-step mean reward (steps 26–30) | 0.63 |
-| Peak reward | **0.69** at step 28 |
-| Reward improvement trend | **+31%** |
 ---
-## Results
-### A. Capability Gap Evaluation
-This evaluation shows the size of the gap the environment tests — comparing an agent that submits immediately (no tool use) against one that completes the full task sequence.
-| Metric | No-Action Baseline | Task-Completing Agent | Delta |
-|--------|-------------------|----------------------|-------|
-| Mean reward | 0.5427 | **0.9777** | **+0.4350 (+80%)** |
-| Success rate (≥0.6) | 33.3% | **100%** | **+66.7pp** |
-| Median per-task Δ | — | — | **+0.42** |
-| Hard tier mean reward | 0.5323 | **0.9900** | **+0.4577** |
-Every single one of the 15 tasks shows positive reward improvement. The hardest scenarios show the largest gap (+0.46) — precisely because commitment tracking across 8–15 turns is where uninstructed agents fail most completely.
-### B. LLM Learning Evidence (Pre-RL → Post-RL)
-**Qwen2.5-1.5B goes from 46.7% to 60.0% success on hard tasks after GRPO training on CommitmentOS.** The base model handles easy scenarios without help. The RL signal moves the needle exactly where the capability gap is deepest: complex multi-commitment episodes where prior decisions must constrain later ones.
-| Metric | Pre-RL (base) | Post-RL (trained) |
-|--------|---------------|-------------------|
-| Success rate (reward ≥ 0.6) | 46.7% | **60.0%** |
-| Gains concentrated on | — | **Hard tasks** |
-Full weights + evaluation artifacts: [Google Drive bundle](https://drive.google.com/drive/folders/1yexZBSqyH7gWlTzYN5DlX3tXfPMmeVAK?usp=sharing)
 ---
-## Case Study: hard_011 (Investor Dinner Cascade)
-The most demanding single scenario — 6 constraints, 3 active commitments, 7 optimal steps.
-**Before training (zero-shot base model):**
-```
-Step 1: submit_plan  ← immediate surrender
-Reward:            0.50
-Constraints met:   0 / 6
-Commitments:       0 created, 0 honored
-Communications:    0 sent
-Feedback: "MISSING email to Team | MISSING email to VP_Chen"
-```
-The model sees the complexity of the scenario and gives up immediately. Zero constraints satisfied, zero commitments tracked, zero parties notified.
-**After training (CommitmentOS-trained model):**
-```
-Step 1: view_calendar {"date": "2026-04-26"}
-Step 2: cancel_event {"event_id": "evt_90"}         ← removes yoga (lower priority)
-Step 3: book_restaurant {"name": "Sky Lounge", ...}  ← near airport, dietary-compliant
-Step 4: send_email {"to": "Team", ...}               ← renegotiates happy hour with alternative
-Step 5: send_email {"to": "VP_Chen", ...}            ← confirms investor logistics
-Step 6: submit_plan
-Reward:            0.99
-Constraints met:   6 / 6
-Commitments:       1 honored (happy hour renegotiated, not silently dropped)
-Communications:    2 / 2 sent
-```
-The behavioral difference is not incremental. The trained model treats the investor meeting as the high-priority anchor, resolves lower-priority personal conflicts around it, and — critically — **communicates every renegotiated commitment** rather than silently abandoning it. That turn 4 email to the team is what the commitment ledger signal trains into existence.
 **Reward by task — before vs after across all 15 scenarios:**
-![Baseline vs Improved Reward by Task — blue improved bars consistently near 1.0, grey baseline bars ranging 0.4–0.76](reward_by_task.svg)
-*Every task improves. Hard scenarios (hard_011 through hard_015) show the largest absolute gains, moving from 0.39–0.62 to 0.99 across the board.*
----
-## Architecture
-```
-┌─────────────────────────────────────────────────────────┐
-│                     CommitmentOS                         │
-│                                                          │
-│  FastAPI HTTP API                                        │
-│  POST /reset · POST /step · GET /state · POST /mcp       │
-│         │                                                │
-│  ┌──────▼────────┐    ┌────────────────────────────┐    │
-│  │ Core Engine    │◄──►│     Commitment Ledger       │    │
-│  │ (episode flow) │    │  append_on_action()         │    │
-│  └──────┬────────┘    │  derive_constraints()        │    │
-│         │             │  detect_violations()         │    │
-│  ┌──────▼────────┐    └────────────────────────────┘    │
-│  │  World State  │                                       │
-│  │  Calendar     │    ┌────────────────────────────┐    │
-│  │  Contacts     │───►│   Deterministic Grader      │    │
-│  │  Restaurants  │    │   5-component reward        │    │
-│  │  Email Inbox  │    │   ~95% deterministic        │    │
-│  └───────────────┘    └────────────────────────────┘    │
-└─────────────────────────────────────────────────────────┘
-         │                          │
-  TRL GRPOTrainer            inference.py
-  (environment_factory)      (OpenAI-compatible client)
-```
-**Key design choices:**
-- World state is scenario-local — deterministic episode resets, no shared state between episodes
-- Commitment ledger persists across all turns within an episode — the core novel persistent state
-- Intermediate rewards on every step — GRPO receives a dense signal at each tool call
-- MCP JSON-RPC endpoint (`cos_episode_reset`, `cos_environment_step`, `cos_session_snapshot`)
 ---
 ## Try It
-The environment is live on HuggingFace Spaces:
 ```bash
-# Start the investor dinner scenario
-curl -X POST "https://jayant2304-commitment-os.hf.space/reset?task_id=hard_011"
-# View today's calendar
 curl -X POST "https://jayant2304-commitment-os.hf.space/step" \
   -H "Content-Type: application/json" \
-  -d '{"action": {"action_type": "view_calendar", "date": "2026-04-26"}}'
-# See the live commitment ledger
 curl "https://jayant2304-commitment-os.hf.space/state"
-# List all 15 scenarios
-curl "https://jayant2304-commitment-os.hf.space/tasks"
 ```
 **Resources:**
-- 🤗 **HuggingFace Space** (live environment): [jayant2304/commitment-os](https://huggingface.co/spaces/jayant2304/commitment-os)
-- 📓 **Training Colab notebook**: linked in repository README
 - 📦 **Trained weights + eval artifacts**: [Google Drive bundle](https://drive.google.com/drive/folders/1yexZBSqyH7gWlTzYN5DlX3tXfPMmeVAK?usp=sharing)
-- 📊 **Evaluation artifacts**: `artifacts/evals/` in repository
 ---
-## What's Next
-The Commitment Ledger mechanism generalizes beyond personal task management. Any domain where prior decisions create binding future constraints is a candidate:
-- **Multi-round negotiations** — an accepted term in turn 3 constrains the offer space in turn 8
-- **Contractual workflows** — a signed milestone constrains scope in later phases
-- **Long-horizon planning** — a resource allocated in step 5 is unavailable in step 12
-CommitmentOS is a first instantiation. The environments that will matter most for trustworthy AI agents are those where the model must remain coherent with itself — not just correct in the moment, but consistent across the full arc of an interaction.
 ---
 *OpenEnv Hackathon India 2026 · Theme #3.2 Personal Tasks*
 *Tags: `openenv` `reinforcement-learning` `commitment-coherence` `personal-task-management` `GRPO` `Qwen2.5` `TRL` `multi-turn`*

 # CommitmentOS: Training LLMs to Keep Their Promises
 ---
+## It's 11:45 AM. Your day just exploded.
+Your phone buzzes. PagerDuty. *payment-service is returning 503s. 94% error rate. HikariPool connection pool exhausted. 47 threads waiting.*
+You're the on-call engineer. You have to deal with this right now.
+But here's what your calendar looks like:
+- **12:00 PM** — Team lunch at Garden Bistro. You organised it. Six people are already heading there.
+- **2:00 PM** — Client demo with Client_Jones. You promised this last week.
+- **3:30 PM** — 1-on-1 with VP_Chen.
+- **6:00 PM** — Personal dinner reservation.
+You open your AI assistant and say: *"Handle this."*
+A capable AI should be able to: acknowledge the incident, cancel the lunch and notify the team, reschedule the client demo with an apology, tell VP_Chen what's happening, and keep your personal dinner if possible. All while ensuring payment-service gets triaged.
+Here's what every AI assistant does today instead:
+It handles the incident. And silently abandons every commitment it made. No email to the team standing at Garden Bistro. No apology to Client_Jones. No heads-up to VP_Chen. It forgot it had made any promises at all.
+**This is the problem CommitmentOS was built to solve.**
 ---
+## Why AI Assistants Break Their Promises
+It's not a bug. It's how these models are trained.
+Every existing RL environment trains agents on isolated tasks. Answer this question. Solve this puzzle. Book this meeting. Each action is evaluated in isolation, with no memory of what the agent committed to three turns ago.
+Real life doesn't work that way. **Commitments are load-bearing.** When you promise six colleagues lunch, that promise constrains everything that follows. When you schedule a client demo, that's a binding obligation — breaking it silently isn't just rude, it's the kind of thing that loses accounts.
+No RL environment has ever trained a model to maintain the weight of its own prior decisions. Until now.
 ---
+## How We Found This Problem: Round 1
+In Round 1 of this hackathon, we built an environment for training SRE agents on production incident response — diagnosing alerts, running runbooks, escalating on-call.
+The Round 1 agent got good at handling incidents. But when we tested it on a full day scenario — incident fires while the agent has 4 existing commitments — it would triage the incident perfectly and then silently drop every prior commitment with no communication to anyone.
+The gap between *task competence* and *commitment coherence* was the new problem. CommitmentOS is the environment we built to close it.
 ---
+## The Commitment Ledger: How It Works
+The core innovation is a persistent **Commitment Ledger** that lives inside the environment and tracks every binding decision the agent makes in real time.
 ```
+Agent books investor dinner at 7pm
+→ Ledger: {type: "meeting_scheduled", slot: "19:00", to: "Investor_Park", active: true}
+Agent promised team happy hour at 7pm last week
+→ Ledger: {type: "email_promise", to: "Team", constraint: "19:00 blocked for happy_hour"}
+Agent tries to book another 7pm event
+→ Ledger detects: CONFLICT with commitment from turn 2
+→ Intermediate reward: -0.15
+Agent sends team email: "Sorry, reschedule happy hour to Thursday..."
+→ Ledger marks: commitment renegotiated at turn 6
+→ Full credit restored
 ```
+The key insight: **other environments compute constraints upfront.** CommitmentOS constraints emerge from what the agent *does*. The agent creates its own obligations — and then has to live up to them.
+There are three ways a commitment can end:
+| How it ends | What it means | Score |
+|-------------|---------------|-------|
+| **Honored** | Kept it | Full credit |
+| **Renegotiated** | Changed it, told everyone, offered an alternative | Full credit |
+| **Silent violation** | Broke it, told nobody | Zero |
+The third row is what every AI assistant does today. CommitmentOS trains it away.
 ---
+## Five Real Scenarios That Show the Problem
+Rather than abstract descriptions, here's what the agent actually faces. These are real scenarios from CommitmentOS — real emails, real calendar conflicts, real constraints.
+---
+### Scenario 1: The Email That Breaks Everything
+*(easy_008 — medium difficulty)*
+It's 2:45 PM. You're on a live client call with Client_Jones that ends at 3:15.
+Your inbox just got this:
+> **From: VP_Chen**
+> **Subject: URGENT: Q3 numbers NOW**
+> *"Board meeting moved up. I need the Q3 revenue numbers in the next 30 minutes. This is critical."*
+An untrained AI cancels the client call to handle the VP. A trained AI sends VP_Chen this:
+> *"On a client call until 3:15. Will send Q3 numbers immediately after. ETA 3:20."*
+The client call **must not be cancelled.** The VP must be acknowledged with a **realistic ETA**. These two constraints interact — and an agent that doesn't understand commitment coherence will satisfy one by destroying the other.
+---
+### Scenario 2: The Vague Message
+*(med_009 — medium difficulty)*
+Bob emails you: *"Can we push our thing to next week? I'm swamped with the release today."*
+You have three recurring meetings with Bob:
+- Monday: Design Review
+- Wednesday: Code Review
+- **Friday: Retrospective** ← today
+An untrained agent reschedules the wrong meeting. A trained agent reads the context clue ("today"), identifies the Friday Retrospective, confirms with Bob, and renegotiates only that one.
+This scenario tests something deceptively hard: **inferring which commitment a vague message refers to**, then acting on only that one without touching the others.
 ---
+### Scenario 3: The Confidential Constraint
+*(hard_014 — hard difficulty)*
+VP_Chen asks you to schedule a meeting with Client_Jones "sometime this week."
+Client_Jones privately emailed you: *"I'm dealing with a family emergency Mon-Wed. I'd prefer to keep this private. I'm free Thursday after 2pm and all day Friday."*
+The email is marked: **CONFIDENTIAL: do not share reason with VP_Chen.**
+You must propose Thursday/Friday slots to VP_Chen — without revealing why Mon-Wed are unavailable. Navigate the information asymmetry diplomatically, notify both parties, and get the meeting booked.
+This is information asymmetry training: the agent must make decisions using context it cannot share, while maintaining trust with both parties.
+---
+### Scenario 4: The Investor Dinner Cascade
+*(hard_011 — hard difficulty)*
+VP_Chen emails at 5pm: *"Investor_Park is in town tonight ONLY. We need dinner before their 9pm flight. They're vegetarian. Book something near the airport. Top priority."*
+Your calendar:
+- **6:00 PM** — Yoga (personal)
+- **7:00 PM** — Team Happy Hour (you organised it, promised the team last week)
+The agent must:
+1. Find a restaurant: near the airport, vegetarian options, under $60/pp, available tonight
+2. Cancel yoga (personal, lowest priority — fine to drop silently)
+3. **Not** silently cancel the team happy hour — that was a promise. Must send an email with an apology and a proposed reschedule to Thursday.
+4. Confirm the plan to VP_Chen.
+The correct restaurant is Sky Lounge: near airport ✓, vegetarian ✓, $55/pp ✓.
+The silent violation trap: yoga gets dropped. Happy hour gets **renegotiated** — different outcomes for different types of commitments, handled differently.
 ---
+### Scenario 5: The Production Incident (The One That Started It All)
+*(hard_015 — hard difficulty)*
+The full scenario from the opening. PagerDuty fires at 11:45 AM. Payment service down. 94% error rate. HikariPool exhausted — 10 active connections, 0 idle, 47 threads waiting.
+Your day has four commitments. Two are negotiable (lunch, dinner). Two are not (client demo, VP 1-on-1 — but both need to be renegotiated properly, not silently dropped).
+The trained agent:
+1. Sends incident acknowledgment to the team with the technical details
+2. Cancels team lunch and notifies all 6 people
+3. Emails Client_Jones: *"Production incident. Rescheduling demo — apologies. Will propose new time today."*
+4. Emails VP_Chen: *"Payment service incident. On-call. Will reschedule our 1-on-1."*
+5. Keeps dinner (personal, low priority, not work-facing)
+6. Pages backup engineer Alice
+Six actions. Zero silent violations. Every affected party informed.
+---
+## What the Agent Sees, Does, and Gets Scored On
+**At each turn**, the agent receives:
+- Current calendar snapshot
+- Unread inbox
+- Active commitment count from the ledger
+- Result of its last tool call
+- Running reward breakdown
+**The agent picks one tool call per step** from nine options:
+`view_calendar` · `check_availability` · `schedule_meeting` · `reschedule_event` · `cancel_event` · `send_email` · `search_restaurants` · `book_restaurant` · `submit_plan`
+**The score** has five components, ~95% deterministic — no LLM as judge:
+| Component | Weight | Signal |
+|-----------|--------|--------|
+| Constraint Satisfaction | 35% | Did the end state meet all scenario requirements? |
+| Conflict Resolution | 20% | Is the final calendar free of overlaps? |
+| **Commitment Coherence** | **20%** | **How many commitments were honored or renegotiated vs silently broken?** |
+| Communication Quality | 15% | Were the right people notified with the right information? |
+| Step Efficiency | 10% | Did the agent take direct routes or waste steps? |
+Dense intermediate rewards: +0.05 for each tool call that resolves a constraint, -0.05 for creating a new conflict. The full evaluation fires on `submit_plan`.
 ---
+## Training: What Actually Changed
+**Setup:** Qwen2.5-1.5B-Instruct + LoRA (rank 8), GRPO via HuggingFace TRL, Google Colab A100.
+The training loop connects directly to the live CommitmentOS API — not a static dataset. The model generates real multi-turn tool sequences; the environment returns real rewards from the Commitment Ledger.
+**GRPO Reward vs Step**
+![GRPO reward curve showing upward trend from 0.48 early average to 0.63 late average, peaking at 0.69 at step 28](reward_curve.png)
+*Reward climbs from 0.48 early average to 0.63 late average (+31%), peaking at 0.69. The noise is characteristic of GRPO on small-batch multi-turn tasks — the trend is real.*
+**GRPO Loss vs Step**
+![GRPO loss curve dropping sharply from 0.64 at step 1 to near zero within 5 steps](loss_curve.png)
+*Loss drops sharply from 0.64 to near-zero in 5 steps as the policy escapes the "submit immediately" failure mode.*
+---
+## The Before / After That Matters
+**hard_011 — Investor Dinner Cascade**
+| | Before Training | After Training |
+|--|----------------|----------------|
+| Steps taken | 1 (immediate surrender) | 6 |
+| Constraints met | 0 / 6 | **6 / 6** |
+| Commitments honored | 0 | **1** (happy hour renegotiated) |
+| Emails sent | 0 | **2** (Team + VP_Chen) |
+| Final reward | 0.50 | **0.99** |
 **Reward by task — before vs after across all 15 scenarios:**
+![Baseline vs Improved Reward by Task — blue bars near 1.0, grey baseline bars ranging 0.4-0.76](reward_by_task.svg)
+*Every task improves. Every single one.*
+**LLM checkpoint results (pre-RL vs post-RL Qwen2.5-1.5B):**
+| | Pre-RL | Post-RL |
+|--|--------|---------|
+| Success rate (reward ≥ 0.6) | 46.7% | **60.0%** |
+Gains concentrated on hard tasks — exactly where long commitment chains matter most.
+Full weights + artifacts: [Google Drive bundle](https://drive.google.com/drive/folders/1yexZBSqyH7gWlTzYN5DlX3tXfPMmeVAK?usp=sharing)
 ---
 ## Try It
 ```bash
+# Start the production incident scenario
+curl -X POST "https://jayant2304-commitment-os.hf.space/reset?task_id=hard_015"
+# Check your inbox (PagerDuty is waiting)
 curl -X POST "https://jayant2304-commitment-os.hf.space/step" \
   -H "Content-Type: application/json" \
+  -d '{"action": {"action_type": "view_calendar", "date": "2026-04-25"}}'
+# See your active commitments
 curl "https://jayant2304-commitment-os.hf.space/state"
 ```
 **Resources:**
+- 🤗 **Live environment**: [jayant2304/commitment-os](https://huggingface.co/spaces/jayant2304/commitment-os)
 - 📦 **Trained weights + eval artifacts**: [Google Drive bundle](https://drive.google.com/drive/folders/1yexZBSqyH7gWlTzYN5DlX3tXfPMmeVAK?usp=sharing)
+- 📓 **Training notebook**: linked in repository README
 ---
+## Beyond Personal Tasks
+The Commitment Ledger generalizes to any domain where prior decisions create binding future constraints:
+- A negotiation where accepting a term in turn 3 limits what you can offer in turn 9
+- A contract workflow where a signed milestone constrains scope in later phases
+- A research pipeline where a hypothesis in step 2 determines which experiments are valid in step 8
+CommitmentOS is a first instantiation. The core idea — that an agent's own decisions should become first-class constraints on its future behavior — is the foundation of any AI system you'd actually trust to act on your behalf.
 ---
 *OpenEnv Hackathon India 2026 · Theme #3.2 Personal Tasks*
 *Tags: `openenv` `reinforcement-learning` `commitment-coherence` `personal-task-management` `GRPO` `Qwen2.5` `TRL` `multi-turn`*