Inspiration
Invoice exceptions are often resolved through scattered email, texts, and memory. A controller can see that an invoice is above quote, while an operations manager may be away from the dashboard and still owns the decision. The phone is useful for surfacing the exception quickly; it becomes risky when a workflow can repeat the call, lose the status boundary, or claim more than the evidence proves. We built ASHVUN to combine one bounded phone-agent action with an explicit human checkpoint and inspectable evidence.
What it does
ASHVUN turns a fictional $9,650 emergency-work invoice against an approved $8,200 quote into one controlled exception workflow. It organizes the $1,450 variance, policy, supporting documents, budget impact, and requester-safe status. Nothing is preselected: the manager chooses an outcome, supplies a reason, reviews the exact policy, authority, consequence, and request digest, and only then can create an immutable local Record.
At the phone boundary, an explicit manager action prepares a redacted briefing that summarizes the variance and sends the manager back to ASHVUN to Approve, Reject, Defer, or Escalate. The public judge evaluator is static and cannot place a call. It links to a privacy-safe receipt from one founder-authorized server-side CALL-E request. CALL-E reached provider terminal status completed; briefing delivery was no, so delivery was not confirmed. CALL-E never receives authority to decide, approve payment, contact a vendor, or change the workflow.
How we built it
We built ASHVUN as a deterministic TypeScript workflow with explicit tenant, workspace, scope, authority, idempotency, and immutable-Record boundaries. The CALL-E integration is a server-side raw Calls API adapter behind a durable private one-request reservation. The controlled path validates the recipient and scope, permits one CREATE/POST attempt, uses a fixed idempotency key, prohibits automatic create retries, and reconciles only GET /v1/calls/{bound_call_id}. It does not depend on /events.
A schema-constrained result keeps request creation, provider terminal status, briefing delivery, and business authority separate. A redacted exporter produces the public runtime receipt without the credential, private destination, full provider call ID, transcript, or recording. The accepted judge bundle is static, requires no login, uses connect-src 'none', and contains no server adapter or call-triggering route.
CALL-E integration
CALL-E is necessary at the point where a time-sensitive exception must leave the dashboard and reach the responsible manager by voice. ASHVUN prepares one scoped briefing request; CALL-E is the external voice runtime that processes that request and returns structured provider state. Once the create response binds a call ID, ASHVUN performs GET-only reconciliation against that exact call resource. The real runtime invocation reached provider terminal status completed, while briefing_delivery=no and delivery_confirmed=false. ASHVUN therefore proves runtime use without claiming delivery, a ringing phone, or a conversation.
Challenges we ran into
The hardest problem was bounding a real external action without turning uncertainty into a duplicate call or an inflated success claim. We had to separate create attempt, provider terminal status, briefing-delivery judgment, and business authority; reserve the one request before creation; prohibit automatic retries and second POSTs; bind reconciliation to the returned call ID; and keep the workflow independent of the /events path. We also had to expose useful proof without publishing a credential, phone number, full provider call ID, transcript, recording, or private manager evidence.
Accomplishments that we're proud of
The accepted successor passed 100/100 local regressions, typecheck, lint, secret scan, browser/network review, and deterministic judge builds. One founder-authorized CALL-E CREATE/POST attempt produced one create request with zero automatic retries. CALL-E was actually invoked at runtime and reached provider terminal status completed; reconciliation stayed GET-only and /events requests stayed at zero. The bounded result was briefing_delivery=no, so delivery_confirmed=false, and the submission makes no delivery claim. The public evaluator requires no login, cannot place a call, and contains only redacted evidence. Our safety-first invoice-exception manager-briefing contribution is merged as PR #40 in CALL-E’s public community repository.
What we learned
The most damaging automation failure is not always a failed request; it can be pretending that an uncertain outcome is a success. We learned to treat invocation, provider completion, delivery, and business authority as separate facts. That separation made the product easier to explain, safer to operate, and more useful to the person who remains accountable for the decision.
What's next
Next, we will test the workflow with controllers and operations managers, add more exception types, and improve opt-in provider-side delivery diagnosis without adding automatic create retries. We will keep the same product boundary: CALL-E can process a bounded briefing request, but the responsible human reviews the evidence and owns the decision.
Contest-period update
During the contest period, we rebuilt the pre-existing submission as ASHVUN and added a controlled server-side CALL-E Calls API path. The successor uses one durable reservation, exactly one CREATE/POST attempt, zero automatic create retries, GET-only call-resource reconciliation, no /events requests, and a redacted terminal receipt. The real CALL-E runtime invocation is proven and the provider reached terminal status completed; the bounded delivery result was no, so delivery confirmation is not claimed. We also produced a no-login static judge experience and merged a reusable safety-first manager-briefing contribution as PR #40.
Log in or sign up for Devpost to join the conversation.