Inspiration
Customers are often told that a case has been “transferred” from one organization to another, only to hear from the receiving side that they cannot find it or do not own the next action. In warranty and service workflows, the customer becomes the manual message bus between disconnected systems.
Handoff Receipt focuses on one narrow question: did the claimed handoff actually land?
What it does
Handoff Receipt is a preview-first CALL-E application for verifying a narrow inter-organization handoff claim.
The first call checks whether the sender has actually completed the handoff, which case/reference was transferred, and who it says owns the immediate next action.
Only after positive sender evidence is established can the receiver-side call proceed. The receiver is then asked whether it recognizes the same reference and whether it owns that next action.
A deterministic reconciliation layer returns explicit outcomes such as:
- acknowledged match
- handoff not acknowledged
- ownership contradiction
- reference mismatch
- sender denial
- unknown
The application does not decide fault, legal responsibility, refund eligibility, or warranty entitlement.
How we built it
Handoff Receipt is built in Python using the CALL-E Developer API.
CALL-E structured results are treated as claims rather than truth. Material claims must also be grounded in recipient transcript evidence.
The workflow uses explicit per-destination authorization, stable idempotency, saved call IDs before polling, no automatic redial after ambiguous creation, strict destination validation, masked human-facing outputs, and fail-closed redirect handling for authenticated requests.
The default mode is a safe preview and creates no calls.
Challenges
The main challenge was preventing technically successful automation from being mistaken for real-world proof.
Several audit rounds found cases where future or conditional statements, similar-but-different references, unsupported ownership claims, or incomplete sender evidence could incorrectly permit a stronger conclusion or another side effect.
Those failures were converted into explicit guards and regression tests.
A later external review also identified three important safety issues: the receiver call needed a stricter positive sender gate, destination validation and authenticated redirects required stronger handling, and human-facing output needed clearer privacy and cancellation limits.
These were repaired in the public pull request.
What we learned
Reliable external-action automation needs more than a successful API response.
Operational claims need identity, reference, actor, timing, authorization, certainty, and evidence binding.
Transport completion and real-world semantic success are different things.
A useful system should preserve uncertainty and disagreement instead of manufacturing a confident answer when the evidence is incomplete.
Live integration proof
A bounded live integration smoke reached CALL-E's real API and created one authorized call to CALL-E's official US English test hotline.
The saved call ID was reconciled to terminal status completed with simulated=false.
Because the official test hotline is not a real handoff sender, the business-semantic result remained UNKNOWN.
We do not claim a successful paired handoff from that smoke test.
What's next
The next step is to continue validating the bounded two-party handoff workflow, improve evidence verification across multilingual cases, and generalize the safety patterns for other external actions where duplicate or ambiguous side effects must be avoided.
Log in or sign up for Devpost to join the conversation.