Inspiration
A submitted warranty claim can be legitimate yet remain rejected, returned, unpaid, or stalled after the portal and documented routes stop producing an actionable answer. The expensive gap is the phone work required to learn what the counterparty says is wrong and what should happen next.
WarrantyOps handles that narrow exception. It does not adjudicate, negotiate, settle, resubmit, ship, pay, or accept credit.
What it does
WarrantyOps places one authorized, disclosed CALL-E call for a stalled submitted warranty-claim exception and converts the conversation into reviewable evidence.
Before calling, deterministic gates verify residual need, source freshness, organization-supplied economics, authorization, disclosure scope, and the exact destination. An atomic attempt ledger is reserved before the provider create, suppressing duplicate calls locally.
After the call, every asserted field must be grounded in a counterparty transcript turn. A reference is confirmed only through its own read-back exchange. Unsupported values remain UNKNOWN. Nothing is written back until a human approves the result, and the source version is checked again immediately before mutation.
How we built it
The project is a Python 3.9+ application. CALL-E performs the real phone interaction and returns the conversation and structured result. WarrantyOps adds the surrounding policy, evidence, idempotency, reconciliation, review, and write-back boundaries.
The default judge path needs no credentials and places zero calls. Six bundled synthetic scenarios demonstrate a useful result, source-sufficient refusal, missing-document action, corrected reference, transport failure, and stale-source refusal. Deterministic offline proof screens and receipts make the behavior inspectable without a live dependency.
What we demonstrated
One controlled CALL-E role-play with a consenting participant completed successfully. The sanitized public R1 receipt shows an installation photograph as the missing requirement, confirms reference BR-4821 through counterparty evidence, keeps formal claim status honestly UNKNOWN, and withholds write-back for human review.
A bundled synthetic scenario also demonstrates the memorable failure: CASE-48171 is confidently heard but wrong; read-back catches the final digit and only corrected CASE-48178 survives.
The contribution was merged into CALL-E's public repository in pull request #522.
Challenges
The difficult part was not placing a call. It was preventing a plausible structured answer from becoming an unsupported business record. Transport success, business outcome, evidence grounding, identifier confirmation, human approval, source freshness, and duplicate suppression therefore remain separate checks.
What we learned
Confidence is not confirmation. A schema-valid result can still contain the wrong reference, and a completed call can still produce no supported business status. Explicit UNKNOWN, bounded refusal, and evidence-linked receipts are product behavior rather than error cases.
What's next
The current release is a working prototype with a synthetic source adapter. A production DMS or ERP connector, real warranty-desk deployment, adoption, time savings, and recovered-value measurement remain future work. Those outcomes are not claimed in this submission.
Log in or sign up for Devpost to join the conversation.