Reality Resolver
Inspiration
Digital systems are very good at remembering what was recorded.
They are not always good at knowing what is true right now.
A maintenance system may say that a technician is confirmed for an intervention, while a recent message from that technician says, "I may no longer be able to make it today."
A calendar may show an appointment as confirmed while an email suggests the person might cancel.
A delivery may still appear scheduled even though the driver has reported a problem.
The problem is not simply that the data conflicts.
The real problem is deciding what to do next.
Sometimes the uncertainty can be resolved from existing evidence. Sometimes a phone call is the fastest way to verify reality. But an AI system should not automatically call someone every time two data points disagree.
Before making a call, it should answer two questions:
Do I need to call?
Am I allowed to call?
That is why I built Reality Resolver.
What it does
Reality Resolver is a decision layer between digital information and the real world.
It takes structured evidence about an operational situation and evaluates four conditions:
- R1 — A structured system asserts a current state
- R2 — Human evidence contradicts, qualifies, or weakens that state
- R3 — No later evidence resolves the contradiction
- R4 — A real-world decision deadline is approaching
When all four conditions are satisfied, the uncertainty becomes decision-critical.
Reality Resolver then determines whether a phone call is justified and passes the case through a compliance gate.
Only when the call is both necessary and allowed does CALL-E execute the real phone call.
The result of that call is then reconciled back into the decision engine.
Possible outcomes include:
RESOLVEDRESOLVED_ALTUNRESOLVED_AMBIGUOUSUNRESOLVED_CALL_BLOCKEDNO_CALL_NEEDED
A core rule of Reality Resolver is:
Unresolved stays unresolved.
If the phone call does not provide enough evidence to determine the real-world state, the system does not guess. It escalates the case for human review.
Live CALL-E execution
Reality Resolver uses CALL-E at runtime for real outbound phone calls.
The live workflow is:
Evidence → Reasoning → Call Decision → Compliance → CALL-E → Result → Verdict → Action
During the recorded demo, Reality Resolver identified a decision-critical technician dispatch case, determined that a phone call was justified, passed the compliance checks, and executed a real CALL-E call.
CALL-E successfully completed the call.
The responder could not verify whether the technician would attend the intervention, so Reality Resolver correctly returned:
UNRESOLVED_AMBIGUOUS → HUMAN_REVIEW
This is intentional behavior.
The system prefers an explicit unresolved state over inventing certainty.
Primary use case
The main demonstration is a critical field-service escalation.
A technician is scheduled for an intervention on important equipment.
The maintenance system says the technician is confirmed, but a recent technician message suggests they may no longer be available.
As the intervention deadline approaches, Reality Resolver determines that the contradiction is important enough to verify.
CALL-E is then used as the bridge between the digital record and the real world.
The same pattern can also be applied to:
- appointment coordination
- delivery confirmation
- recruiting interviews
- hospitality reservations
- property maintenance
- customer callbacks
- equipment servicing
- other operational workflows where digital state and real-world state may diverge
How I built it
Reality Resolver has two main layers.
Deterministic decision engine
The Python backend evaluates structured evidence, the R1-R4 reasoning rules, deadlines, compliance conditions, call authorization, and final reconciliation.
The final decision to make a call is deterministic and auditable.
Decision Cockpit
The React/TypeScript frontend provides a visual interface for:
- viewing evidence
- understanding R1-R4 reasoning
- seeing whether a call is justified
- reviewing compliance checks
- executing CALL-E in live mode
- inspecting provider results
- viewing the resulting verdict and operational action
The application supports both predefined scenarios and custom structured cases.
It also includes deterministic demo scenarios so the decision engine can be demonstrated without making unnecessary real phone calls.
CALL-E integration
CALL-E is not simply referenced by the project.
It is called at runtime after Reality Resolver has independently determined that a phone call is both necessary and permitted.
The backend:
- evaluates the evidence
- determines whether a call is required
- evaluates the compliance gate
- authorizes the exact destination
- creates the CALL-E call
- polls CALL-E for the terminal result
- reconciles the structured result into a final operational verdict
Live calls require an explicit API key and explicit destination authorization.
The API key is used only for the current request and is never persisted by the application.
Safety and compliance
Reality Resolver was designed around the principle that autonomous calling should be selective rather than automatic.
The system includes:
- explicit live-call authorization
- exact E.164 destination verification
- compliance checks before calling
- no automatic live calls
- no automatic retries of live calls
- concurrency limits for live execution
- sanitized provider errors
- no API-key persistence
- explicit unresolved states
- human escalation when evidence remains ambiguous
This makes the phone call part of a controlled decision process rather than the default action.
Web and local deployment
Reality Resolver can run as a deployed web application or locally inside an organization's environment.
For this hackathon, the public demo consists of a hosted frontend and backend.
The same application can also be run locally, which makes the architecture suitable for environments where organizations prefer to keep operational systems within their own infrastructure.
Challenges
One of the biggest challenges was making the system reliable around a real-world asynchronous action.
A phone call is very different from a normal API request.
The application must handle:
- queued calls
- calls that remain in progress for a significant period
- provider failures
- ambiguous conversations
- blocked calls
- unanswered or automated destinations
- cases where making a call is unnecessary
Another important challenge was preventing the interface from presenting uncertainty as certainty.
A technically successful phone call does not necessarily mean that the real-world question was successfully answered.
That distinction became one of the central design principles of Reality Resolver.
What I learned
The most important lesson was that adding an AI phone agent to a workflow is not only a conversation problem.
It is also a decision problem.
The interesting question is often not:
"Can AI make this phone call?"
It is:
"Should this call happen at all, and what should the system believe after the call?"
CALL-E makes it possible to connect software decisions to real-world conversations.
Reality Resolver explores the decision layer that can sit immediately before and after that call.
What's next
The current hackathon version uses structured evidence supplied manually or through generated operational scenarios.
A production version could ingest events from systems such as:
- CRM platforms
- ERP systems
- calendars
- ticketing systems
- messaging platforms
An extraction layer could transform those raw events into structured evidence, while keeping the final call decision deterministic and auditable.
The longer-term goal is to make Reality Resolver a reusable verification layer for operational workflows where the digital record is no longer enough.
Don't guess. Resolve reality.
Built With
- ai
- api
- automation
- call-e
- css
- python
- react
- rest
- start
- tailwind
- tanstack
- telephony
- typescript
- vite
Log in or sign up for Devpost to join the conversation.