RevisitZero

RevisitZero turns failed field visits into one policy-gated CALL-E contact and a privacy-minimised, human-reviewed rebook recommendation—without automatic booking or retries.

Comment

Inspiration

A field technician can arrive ready to work and still leave because a gate is locked, a dog is unsecured, an obstruction remains, or nobody can provide access. Rebooking immediately risks another failed visit, while uncontrolled outreach can introduce privacy, safety, consent, and operational risks.

RevisitZero focuses on the narrow gap between those choices: collect only the minimum structured facts needed to help a human decide whether a failed visit is ready for rebook review.

What it does

RevisitZero is a desktop operator workbench built around three fictional meter-access cases:

  1. An eligible case can proceed only after an operator reviews and approves the exact recipient, objective, allowed questions, visit windows, and guardrails.
  2. A body-corporate access case routes to manual review without broadening the recipient or placing a call.
  3. A suspected electrical or site defect is blocked before approval or contact.

For an eligible case, RevisitZero permits at most one policy-gated CALL-E attempt, validates a closed structured result, detects contradictions, and produces a deterministic disposition such as READY_FOR_REBOOK_REVIEW, MANUAL_REVIEW, or AUTOMATION_BLOCKED. Even a ready result is only a recommendation. A separate human decision is required before downloading a local JSON export packet.

It never books an appointment, updates a CRM or field-service system, contacts a landlord or body corporate, sends a customer notification, collects a gate code, or retries automatically.

How we built it

The workbench uses TypeScript, React, Vite, and a local Node.js server. Deterministic policy rules evaluate safety, vulnerability, consent, recipient authorisation, phone validity, suppression, and call-window constraints before CALL-E is available.

The operator approval is content-bound with a SHA-256 receipt. Editing any approved field invalidates it. The CALL-E boundary uses the official @call-e/calle TypeScript runtime, a stable idempotency key, one recipient, one task, and no application retry. Ambiguous provider outcomes are quarantined for reconciliation instead of triggering a redial.

A strict local schema accepts only a reached/unreached/do-not-contact outcome, closed access answers, one approved window or none, and an opt-out signal derived from the authoritative contact outcome. Unknown fields, free-form narratives, unapproved windows, or semantic contradictions fail closed and cannot become ready.

How CALL-E is used

The default public demo is fake/no-call mode. It needs no credentials, uses only fictional data, and creates no real external side effects.

Controlled live mode is disabled by default and requires server-side credentials, an explicitly consenting test recipient, a short current call window, and fresh operator approval. On August 16, 2026, one participant-authorised controlled-live test completed at the provider. RevisitZero rejected a contradictory opt-out/outcome result, routed it to manual review, blocked export, and prevented a duplicate call. That verified the live boundary and fail-closed behaviour; it was not a successful golden-path end-to-end result, and no second real call was placed.

Challenges we ran into

The hardest part was not initiating a call; it was proving when the application must refuse to call, retry, or accept a result. We had to bind approval to exact content, preserve ambiguous provider states, keep the provider schema within CALL-E's supported subset, and prevent contradictory or over-collected data from influencing a downstream recommendation.

Accomplishments that we're proud of

  • A credential-free three-case demo with one fake call and zero real side effects
  • Deterministic pre-call gates and final dispositions
  • Exact approval invalidation and stable duplicate prevention
  • Privacy-minimised structured collection with no transcript or free-form narrative
  • 63 automated tests across policy, approval, validation, workflow, adapter mapping, suppression, and ambiguity handling
  • A successful production build and local API/UI smoke test
  • One authorised live boundary test that failed closed exactly as designed

What we learned

A reliable voice-agent application needs more than a good conversation prompt. The surrounding controls—eligibility, recipient scope, approval, result validation, idempotency, suppression, reconciliation, and human ownership—determine whether the system is safe and operationally useful.

What's next for RevisitZero

A production version would need governed durable storage, authentication, multi-user access controls, concurrency-safe idempotency and suppression, operational reconciliation tooling, accessibility review, and security/privacy assessment. Any future field-service integration would retain the current human decision boundary: RevisitZero would still recommend, not automatically book or notify.

Known limitations

The current prototype is English-only, desktop-only, and limited to three fictional cases. Its ledger and suppression registry are in memory. It has no production persistence, authentication, multi-tenancy, mobile experience, analytics, SMS/email, inbound calling, bulk calling, automatic retry, CRM update, or scheduling action. The workflow stops at a human-approved local export packet.

Built With

Share this project:

Updates