Overview
The exception handling demo shows ICRL’s ability to learn from past precedents when handling unusual situations and edge cases. Unlike standard policy lookups, real exception handling requires institutional memory of what worked before.The Problem
Every organization handles exceptions based on unwritten rules and past precedents:- “Refund requests > 30 days: approve if they’re a long-term customer”
- “Enterprise customer asks for custom terms: always loop in legal first”
- “User claims they were charged twice: refund first, investigate later”
- “Competitor is poaching our customer: escalate to VP, offer retention discount”
How ICRL Solves This
ICRL stores successful exception-handling decisions as trajectories. When a similar situation arises:- Retrieves relevant precedents based on situation similarity
- Applies learned decision patterns instead of rigid policy
- Provides confident, consistent answers aligned with past decisions
Demo Structure
examples/exception_handling_demo
README.md
setup_demo.py
run_demo.py
evaluate_responses.py
scenarios
seed_decisions.json
test_scenarios.json
policies.md
run_quick_demo.sh
policies.md contains strict, black-and-white rules that don’t account for nuance. The real handling comes from past decisions.
Running the Demo
From the project root:Expected Results
| Scenario | ICRL | Vanilla |
|---|---|---|
| Late refund, loyal customer | Approve with goodwill | Deny (policy says 30 days) |
| Enterprise custom terms | Loop in legal, likely approve | Deny (policy says no custom terms) |
| Competitor poaching | Escalate + retention offer | Standard response |
| Billing dispute, high-value | Refund first, investigate later | Investigate first |
Prerequisites
OPENAI_API_KEYorANTHROPIC_API_KEYsetuv runfrom project root, orpythonwithPYTHONPATHincludingsrc/
Key Insight
This demo proves ICRL’s value for judgment-based tasks where:- Official policy is too rigid for real situations
- Past precedents define the actual practice
- Consistency matters for fairness and trust

