Execution and verification

Work ends in the firm's systems of record, not in a draft. Before Proxara changes anything in a provider it writes down exactly what it intends to do, executes once, then reads the provider back to find out what actually happened. What is reported afterwards is the observed state, not the attempt.

What is recorded before anything changes

The firm's environment durably records, as one immutable set:

• the accepted proposal;
• the digest of the artifact revision it was accepted against;
• the bound target: the real client, record, recipient and provider object;
• the exact payload;
• the purpose and the authority behind it;
• the consequence decision, and who made it;
• the replay strategy for that provider;
• the expected post-state;
• the rule that will decide whether the effect verified.

Binding happens inside the firm. A model names an opaque reference; it never selects a provider identifier.

Intervention follows consequence, not novelty

Reads, local reasoning, private artifact creation, revision and reversible internal updates run under delegated authority. Nothing prompts a preparer because a model was involved.

Fresh confirmation is normally required for a client send, a filing or submission, a payment, finalizing a return, a destructive or externally visible effect, a materially widened set of recipients or sources, and unresolved ambiguity. At that point the preparer sees the real target and the real payload, not a summary of them.

Execution, once

Execution uses the firm's own credentials and a typed provider capability, dispatched once under that provider's idempotency and concurrency behavior. Authority is rechecked at dispatch: the employee's own permission, the current policy revision, the target's current state, and the provider capability for that exact action.

A provider success response is not a verified effect

An HTTP acceptance means the request was received. A model's assertion that it finished is not evidence. Verification is an authoritative read of the provider's own state, compared with the expected post-state recorded at binding.

These are distinct. None of them collapses into another.

Ordered effects, worked

A missing-document follow-up commits in order:

1. save the artifact revision;
2. create the Outlook draft;
3. send the client message after the preparer confirms it;
4. update the Karbon requirement and set the next chase date;
5. read both providers back.

Dependencies are explicit. Step 4 does not run because step 3 was attempted; it runs because step 3 verified.

Repair never resends a verified effect

If the send verified and the practice-management update did not, the work becomes partial and a repair is prepared that contains the practice-management continuation only. The client message that already went out is excluded from it, permanently. A verified effect cannot become unexecuted, and no repair reopens one.

Reconciliation is not retry

When an outcome is ambiguous, the options are a safe authoritative read, matching an execution marker the provider returned, comparing provider versions, resuming a pending verification, retrying an effect proven absent and known to be idempotent, compensating a reversible effect where that is authorized, or creating narrowed repair work.

Retry is not the universal answer to uncertainty. A consequential call whose response was lost is investigated, not repeated.

Where to go next