ProvelyThe verdict is PENDING, which states that the evidence does not decide yet. Your agent reports the operation id and exits, so no process waits. Provely keeps reading the provider, and a provider event wakes the operation early.
A side effect completes in the provider, not in your process. Stripe accepts a refund in milliseconds. The bank moves the money later. Provely never collapses the two moments into one word.
Why is PENDING not a failure?
PENDING states one fact: the evidence does not decide yet. An operation moves CREATED to ACTION_STARTED to ACTION_ACCEPTED to OBSERVING to PENDING. A terminal verdict is VERIFIED, CONTRADICTED, FAILED, UNVERIFIABLE, EXPIRED, or HUMAN_REVIEW.
Safety rule 3 is frozen. When an operation can still make progress, the runtime returns PENDING, not FAILED. Read the PENDING definition.
The signed contract stripe.refund.succeeded names the provider states that keep an operation open. Each one gives PENDING.
Which promise does each contract prove?
The Stripe integration 0.1.0 ships two completion levels, and each level is one contract. A completion level is a promise, not a stage.
| Level | Contract | What the contract proves |
|---|---|---|
created | stripe.refund.created | The created level proves that the Refund object exists at the provider with the requested amount and charge. It does not prove that money moved. |
succeeded | stripe.refund.succeeded | A Refund object does not prove that money moved. This contract proves the succeeded state on the refund resource and a refund.updated event that carries it. |
A created Refund object is not moved money. A page, a receipt, and an agent must never present the lower level as terminal success.
Which evidence proves that the money moved?
The contract stripe.refund.succeeded reads the refund back from Stripe, and it reads the Stripe events. Neither comes from the agent. The action response alone never decides.
The readback and the events answer at different speeds, so the runtime does not depend on one of them. A readback that is fresh decides without a callback. A callback decides when a readback is stale.
How long does the runtime observe?
The signed contract states the timing policy. The runtime reads it. No code holds a Stripe number.
The runtime stops at the first limit that it reaches: the attempt count, or the deadline. A callback that arrives while the operation is open wakes it, so a late event does not wait for the next poll.
What happens when a callback arrives?
Every delivery passes the same rules. None of them trusts the agent.
Explain: the six rules every delivery passes
| Rule | What the runtime does |
|---|---|
| One endpoint | A provider posts to POST /v1/events/{provider}/{workspace}. The route takes no API key. |
| Signature first | The connection states the signature scheme. A delivery that fails the check is refused. |
| Duplicate delivery | The store deduplicates on the provider event id. A repeat answers 200 and writes nothing. |
| Late and out of order | The runtime orders events by provider_timestamp. The arrival order decides nothing. |
| Correlation | The event must name this operation. An event that the contract cannot tie to it decides nothing. |
| Wake | An event that correlates with an open operation moves its next attempt to now. The verifier reads the provider again at once. |
Safety rule 6 says that evidence must correlate with the exact operation. A refund that existed before the operation started proves nothing, and the contract contradicts it. Read the correlation definition.
What happens when a callback never arrives?
The operation reaches its timeout. The contract states the result: UNVERIFIABLE, and the operation moves to HUMAN_REVIEW. The verdict is never FAILED. Provely does not know that the refund failed. It knows that no evidence arrived.
Before the deadline, a channel that cannot answer gives UNVERIFIABLE with the reason evidence_unavailable. The frozen retry table then permits one action: retry the verification. Never the refund. Read the verdicts and the retry rules.
Never retry a side-effecting action on PENDING. The action can still succeed, and a second call refunds the customer twice.
What must the agent do while it waits?
Nothing. An ephemeral agent must not hold a process open until the deadline, which can be days away.
- Report the action result to the operation.
- Read the verdict. PENDING is a normal answer.
- Report the operation id, and exit.
- Ask again later with
GET /v1/operations/{id}. - Never repeat the action while the verdict is PENDING.
The verifier keeps observing without the agent. The receipt is ready when the evidence decides. Read what a receipt proves.
Does PENDING mean the refund failed?
No. PENDING means that the evidence does not decide yet. A refund in a transitional state can still succeed. A retry would refund the customer twice.
Does a late webhook break the verdict?
No. The runtime orders events by provider_timestamp, and it deduplicates on the provider event id. The arrival order decides nothing.
What does Provely return when no evidence ever arrives?
UNVERIFIABLE. The verdict states that the evidence stayed insufficient. It never states that the provider failed.