Threshold

Inspiration

Unknown missed calls create an unfair choice: spend time calling back, or risk missing something important. Caller ID alone does not prove who called, but returning the call personally may expose information before the caller has earned any trust.

I built Threshold to place a safer boundary between an unknown call and the person receiving it. Its job is not to decide whether a caller is safe. Its job is to collect only supported facts, preserve uncertainty, and let the person decide whether the call deserves their attention.

What it does

Threshold reviews the phone number and call time entered by the user, checks whether the destination is supported, and presents a confirmation step before any outbound action.

Its result interface separates:

• what the respondent actually stated
• general guidance that must remain general
• information that could not be obtained
• supporting evidence and question counts
• safety boundaries that ended the conversation

It never treats caller ID as identity, never invents missing details, and never turns a refusal to disclose information into suspicious behavior. If one returned field is unsupported or inconsistent, Threshold rejects that field while preserving the other usable information.

The public demo uses five clearly labeled synthetic scenarios and places no calls. The final decision always remains with the user.

How I built it

Threshold is a TypeScript application built with React, Next.js, Drizzle ORM, and a D1-backed execution-ledger design. The CALL-E adapter validates reusable Goal inputs and structured results before they enter the product’s observation model.

The execution design reserves one active request per user and stores an idempotency key before dispatch. A lost response is recovered using the same request instead of silently creating another call. The normal workflow supports selected Japanese fixed-line and mobile-number formats, while an isolated authorized-test route was created specifically for CALL-E’s official US testing hotline.

The result validator checks field values, reasons, evidence, scope, readback status, question limits, and conversation-ending records. The interface then presents verified statements, general information, and unknowns as separate categories.

Challenges I ran into

The largest challenge was preserving uncertainty across several boundaries: caller identity, public contact information, conversation output, and CALL-E execution status.

Japanese voice settings were unavailable in the account’s current runtime scope, so Japanese calling quality could not be verified. An authorized control test against the official US testing hotline was performed on September 8, 2026. Planning succeeded, but no Run ID was returned during execution. Whether execution was accepted or a call began remains unconfirmed.

This behavior is tracked publicly in CALL-E Issue #229. I did not retry the call because a delayed or unreported execution could make another attempt dial twice.

Accomplishments that I am proud of

• A privacy-first missed-call workflow that does not disclose the user’s identity
• Fail-closed confirmation and idempotency controls before dispatch
• Structured results that distinguish facts, general guidance, and unknowns
• Partial-result preservation when one field is invalid
• Explicit handling of authentication-code and sensitive-information boundaries
• Five credential-free synthetic scenarios for judging
• 79 recorded automated tests: 76 core tests and 3 rendering or route tests
• A later focused checkpoint covering 20 hotline-path tests, TypeScript checking, and the production build

These automated checks use fake clients and local infrastructure; they do not claim that a live call completed successfully.

What I learned

A phone call does not automatically establish identity, truth, or safety. A useful calling agent must represent not only what it learned, but also how it learned it and what remains unknown.

I also learned that timeout handling is part of product safety. When an external execution may have been accepted but no identifier returns, retrying is not simply a reliability decision—it may create a real duplicate call. Threshold therefore treats unresolved execution as unresolved and leaves the next decision to a human.

Built With

• call-e
• cloudflare
• css
• d1
• drizzle
• next.js
• orm
• react
• tailwind
• typescript
• vite