The Core Guarantee

“Completed” is not proof. Verified is.

Most agent platforms report that the model finished. Davirix reports whether the effect actually happened — confirmed at the source system. These are two different questions, and confusing them is how enterprises end up sending the same payment twice.

The most important rule

status: completed ≠ done

One execution carries two independent facts: whether the agent finished processing, and whether the external effect occurred. Davirix keeps them in separate fields so your code can never mistake one for the other.

Two fields, two questions

Did the agent finish processing?

status

Did the external effect actually occur?

operations[].status

The five operation states

Every side effect an agent produces — an SMS, a payment, a ledger write — resolves to exactly one of these.

VERIFIED

Confirmed at the source. The only true “done”.

Proceed.

ACKNOWLEDGED

The connector accepted the request. Transport only — not a result.

Wait for verification.

UNKNOWN

The outcome is genuinely uncertain.

Never retry. Wait for reconciliation.

MANUAL_REVIEW

The operation needs a human decision.

Resolve in the console.

FAILED

A definitive failure. Nothing happened.

Safe to retry.

The mistake, and the fix

Wrong — the most common bug
if n.status == "completed":
    send_receipt()   # ⛔ the payment may never have happened
Correct
if n.verified:
    send_receipt()               # ✅ confirmed at the source
elif n.unknown:
    hold_for_reconciliation()    # ⚠ never retry here

Why this prevents duplicates

A silently swallowed UNKNOWN is precisely where duplicate effects come from. If the code treats uncertainty as failure and retries, the customer gets charged twice. Davirix makes the uncertain case explicit and un-retryable by default, so the safe path is also the default path.

Verification is what makes the audit trail worth having

An audit log that records intent proves nothing. Because every operation carries a source-confirmed state, the Davirix audit trail records what actually happened — which is the version regulators and risk committees ask for.

Read the rule in the documentation

The full specification, including reconciliation behaviour and idempotency keys, lives in the docs.