MISE

MISE turns a failed supplier delivery into a committed recovery by calling the supplier and refusing to move until they say exactly what they’ll deliver and when.

Comment

MISE

Don't let “maybe” become “done.”

A critical supplier delivery fails.

The usual workflow is simple:

delivery failed → notify someone → someone calls the supplier → someone figures out what happens next.

MISE changes that.

MISE takes over the recovery.

It determines the next action, uses CALL-E to call the supplier, understands the response, rejects weak commitments, and keeps the incident moving until there is a commitment strong enough to recover the delivery.

CALL-E isn't just being used as a voice API.

CALL-E is what gives MISE the ability to take the recovery out of the dashboard and onto the phone.

The problem

A failed delivery isn't a notification problem.

It's a recovery problem.

Suppose 4 units were supposed to arrive today and didn't.

MISE calls the supplier through CALL-E.

The supplier says:

“We'll try to get them out this afternoon.”

The call happened.

The problem didn't get solved.

MISE doesn't mark the recovery successful.

It asks the question that actually matters:

Did the conversation produce a commitment that can move the recovery forward?

If not, the case stays open.

MISE closes the loop

DELIVERY FAILS
      ↓
MISE TAKES OVER
      ↓
CALL-E CALLS SUPPLIER
      ↓
SUPPLIER RESPONDS
      ↓
DID THEY ACTUALLY COMMIT?
      ↓
   NO              YES
   ↓                ↓
CONTINUE          RECOVERY
RECOVERY          SECURED
   ↓                ↓
   └────────────→ MONITOR

This is the core product.

The goal isn't to make a successful phone call.

The goal is to recover the failed delivery.

See it happen

The demo begins with INCIDENT #1842.

Four units were supposed to arrive.

They didn't.

MISE takes ownership of the incident and determines that the supplier needs to be contacted.

First call

CALL-E contacts the supplier.

The supplier says:

“We'll try to get it out by 4 PM.”

MISE rejects the response.

Recovery: NOT SECURED.

The incident stays blocked.

There is no false success just because the call completed.

Second attempt

MISE continues the recovery.

The supplier is contacted again.

This time:

“Yes. Four units. We'll ship today. Delivery is scheduled for 2 PM.”

MISE accepts the commitment.

Recovery: SECURED.

The incident moves into monitored recovery.

That's the product.

What counts as a recovery?

MISE needs enough information from the phone conversation to establish:

What? What is being delivered?

How much? What quantity is committed?

When? When will it arrive?

A supplier saying:

“We'll try.”

doesn't count.

Neither does:

“We can probably ship.”

And neither does an unsupported agent statement:

“The supplier confirmed delivery.”

But:

“Yes, 4 units. Shipping today. Delivery at 2 PM.”

can move the recovery forward.

CONTRACTOR: the control behind the recovery

CONTRACTOR is the decision layer underneath MISE.

It answers one question:

Is this phone interaction strong enough to change the state of the recovery?

The answer is deliberately simple:

ACCEPTED
REJECTED

Rejected calls receive explicit reasons:

SUPPLIER_HEDGED
DELIVERY_WINDOW_MISSING
NO_EXPLICIT_COMMITMENT
PROOF_NOT_TRUSTED

This keeps the distinction clear:

CALL-E determines what happened in the conversation. CONTRACTOR determines whether that conversation earned a state transition.

MISE keeps the evidence

When a recovery is accepted, MISE records the evidence behind the decision:

  • CALL-E call ID
  • timestamp
  • supplier statement
  • extracted commitment
  • quantity
  • delivery window
  • confidence
  • state transition

The transition is appended to a hash-linked ledger.

Opening a recovery therefore doesn't just show:

RECOVERY COMMITTED

It can show why MISE was allowed to put it there.

The attack lab

The recovery gate is tested against deliberately bad inputs:

“We'll try to get there by 4 PM.”
→ REJECTED
→ SUPPLIER_HEDGED

“We can probably ship.”
→ REJECTED
→ DELIVERY_WINDOW_MISSING

“Delivery confirmed.”
→ REJECTED
→ PROOF_NOT_TRUSTED

“Yes, 4 units. Ship today. 2 PM.”
→ ACCEPTED

The objective is not to make every phone call look successful.

The objective is to make the recovery successful.

Why CALL-E makes this possible

CALL-E changes the boundary of what an automated recovery system can do.

Before a phone agent, the workflow could detect a failed delivery and create a task:

“Call supplier.”

The task then waits for a human.

With CALL-E, MISE can actually perform that step.

The workflow becomes:

detect → call → listen → decide → continue → recover.

The phone conversation is no longer a dead-end interaction.

It becomes an action inside the recovery loop.

That's the capability MISE is built around.

A commitment isn't a completed delivery

MISE deliberately does not declare the physical delivery complete.

A supplier saying:

“Yes, we'll deliver 4 units at 2 PM”

means the recovery has been committed.

It does not mean the truck has arrived.

So MISE stops at:

RECOVERY COMMITTED

and leaves fulfillment to the supplier.

The system coordinates the recovery without pretending the real-world action has already happened.

Live CALL-E + deterministic demo

MISE supports live CALL-E execution with a consented E.164 destination and live credentials.

It also includes a deterministic offline mode for repeatable demonstrations.

Both exercise the same loop:

FAILED DELIVERY
      ↓
RECOVERY ACTION
      ↓
CALL-E
      ↓
PHONE CONVERSATION
      ↓
COMMITMENT DECISION
      ↓
RECOVERY STATE

The offline mode makes the full product reproducible without requiring a live phone call for every run.

Built with

  • CALL-E — autonomous phone conversations
  • Python — recovery engine
  • CONTRACTOR — commitment verification
  • SQLite — case and evidence persistence
  • Hash-linked ledger — transition integrity
  • Browser dashboard — recovery operations
  • Deterministic simulation — repeatable demo mode

Run the project with:

python3 demo.py --db contractor.db
python3 server.py --db contractor.db
python3 -m unittest discover -s tests

The result

A failed delivery enters MISE.

MISE takes action.

CALL-E gets the supplier on the phone.

A weak answer gets rejected.

The recovery continues.

A firm commitment is obtained.

The incident moves into monitored recovery.

CALL-E gives MISE the ability to act in the real world.

MISE gives that capability a job worth doing: recovering what failed.

Built With

Share this project:

Updates

Submission history