OREF-Logo
Exception lifecycle and status
WhatsApp temperature alert and resolution
Exception assessment and recommendations
Temperature monitoring and audit trail

Inspiration

Enterprises detect operational problems in seconds, but fixing them is still manual. When a refrigerated medicine shipment starts warming up, someone has to notice the alert, call the driver, find a cold store nearby, get approval, chase replies and prove the product stayed safe. Most of those people (drivers, partner facilities, quality reviewers) sit outside the company's systems. We wanted to move operations from "detect and alert" to "detect and resolve".

What it does

The Operational Exception Resolution Framework takes ownership of an exception the moment it is detected and drives it through seven stages: Detect → Understand → Assess → Coordinate → Act → Verify → Close.

Our first playbook is cold-chain shipment rescue. A pharmaceutical shipment that must stay at 2–8°C crosses 8°C because its refrigeration unit fails. The platform:

opens an incident on its own and checks in with the driver on WhatsApp (buttons first, "pull over safely" wording);
reads a photo of the unit's display to identify the fault code;
compares every option (carry on, or divert to an approved cold store) against the product's excursion allowance, using deterministic rules;
gets a one-tap approval from the operations manager, secures a facility, and automatically falls back to the next one if a facility declines;
reroutes the driver, confirms the transfer, and marks the incident Contained only after sensor data shows the product back in range;
sends QA a full excursion report by WhatsApp and email, and closes only when QA records a disposition.

If someone goes quiet, configurable follow-up ladders send reminders and escalate (WhatsApp → SMS → supervisor). The platform is multi-tenant: two tenants in the same domain can have different allowances, people and timings, and the same event can lead to a different, rule-correct outcome for each.

How we built it

Orchestration: AWS Step Functions (Standard) runs each playbook. Task tokens pause the workflow until a person replies, and a reusable engagement sub-workflow handles reminders and escalation.
Messaging: one channel router is the only component allowed to send anything. It calls AWS End User Messaging Social for WhatsApp and Amazon SES for email. SMS is wired into the escalation ladder but mocked in the demo while our India DLT registration is pending. Inbound replies come in through Amazon SNS and Amazon SQS and are matched to the right tenant, incident and question.
AI: Amazon Nova Lite on Bedrock reads free-text replies and photos of the unit's display, with Bedrock Guardrails and a number-match validator on top. An optional agent on Amazon Bedrock AgentCore (Strands Agents), switched on by a flag, adds advisory input. Neither can send a message or change state.
Rules: a pure-Python rules engine makes every decision. For each option it projects the time the product will spend above its limit:

$$T_{peak} = T_{now} + r_{rise}\,(d + l), \qquad \text{projected} = u + d + l + \frac{T_{peak} - T_{max}}{r_{cool}}$$

where $u$ is the allowance already used, $d$ the drive time, $l$ the unload time and $T_{max}$ the tenant's upper limit. An option is feasible only if the projected time stays within the product's excursion allowance.

Data: Amazon DynamoDB (four tables, with every key prefixed by tenant), Streams for live dashboard updates, and Amazon S3 with KMS for evidence and reports.
Front end: a React dashboard and admin portal on CloudFront, with Cognito sign-in and API Gateway (REST and WebSocket).
Operations: CloudWatch alarms and dashboards, and X-Ray tracing across every Lambda and state machine.
Infrastructure: AWS CDK in Python (four stacks), deployed from GitHub Actions through an OIDC role, plus a deterministic telemetry simulator and a scripted responder for repeatable tests.

Challenges we ran into

AI must never decide regulated outcomes. We drew a hard line: "AI understands, rules decide, people approve." The AI only interprets; it cannot send messages, change state, or state a number a tool didn't return. Sending is limited to the channel router, so this is enforced by the architecture, not just by a prompt.
WhatsApp's business-messaging rules. Every message to someone who hasn't replied yet must be a pre-approved template, so the whole message catalog, including reminders, had to be designed up front.
One shared WhatsApp number for many tenants. Replies are matched using the message context, with a disambiguation question if one person is active in two tenants.
Choosing escalation channels. We looked at voice for the escalation ladder, but End User Messaging voice can't capture keypresses, so it could only be a one-way attention call. We kept WhatsApp as the place where people actually respond.
Calibrating the rules engine. The engine had to reproduce the reference scenario and still find the backup facility feasible when it is re-checked after the first facility declines.
Demo time vs human time. An accelerated clock makes a 60-minute incident fit in about 3 minutes, but real people on demo phones can't reply in 3 seconds.

Accomplishments that we're proud of

A design where every decision is deterministic and traceable to a versioned configuration snapshot.
True multi-tenancy from day one, with per-tenant thresholds, people, follow-up timing and messaging style.
Resilience paths for silence, declines, missed confirmations and temperature rebounds.
A fully specified test strategy: golden rules-engine cases, 51 scenario tests, tenant-isolation tests, and AI evaluation sets for replies and photos.
A judge sandbox where anyone can text "JOIN" and play the driver.

What we learned

Coordinating people outside your systems is the hard part of operations, and ordinary messaging channels are the way to reach them.
Separating "understanding" (AI) from "deciding" (rules) makes agentic systems far easier to test and to trust.
Messaging-channel rules (templates, 24-hour windows, opt-in, one-way channels) shape the architecture as much as the cloud services do.

What's next for Operational Exception Resolution Framework

A second domain playbook, such as a manufacturing line down or a disrupted concrete delivery.
Real IoT and TMS/WMS integrations in place of the simulator.
Live SMS once DLT registration clears, two-way voice, per-tenant WhatsApp numbers and per-tenant quotas.
Pilots with cold-chain logistics partners, measuring time to containment against today's manual handling.