A refund is a useful test of an agent contract because evidence, identity, approval and external provider state must agree before the system can claim useful completion.
The earlier article’s illustrative ₹24,500 run mixed noncanonical types and receipt statuses, carried an unresolved escalation into execution, and treated an evidence hash and reversal token as sufficient authorization/recovery. That path is replaced here. This is a source-backed reference walkthrough, not a production payment or measured latency result.
The complete specifications are Execution Contract, Context Pack and Decision Record. The repository’s synthetic enterprise fixture demonstrates validator composition; it does not operate a bank, credential broker, sandbox or atomic store.
1. Admit the actual workflow
Bind request, run, tenant and trace, immutable release/configuration references and exact selected profile/control revisions. Derive enabled features from trusted application configuration. contextos.enterprise revision1 declares obligations; support negotiation does not grant permission or prove active enforcement. Unknown required versions or missing support block admission without demotion.
Keep canonical InvokeRequest and RunContext shapes. Intent lives on request.input.intent; identity claims, budgets and a destructive compatibility ceiling are not authenticated grants. Do not add tutorial-only user_id, on_behalf_of, max_steps or scalar bucket fields to those types.
2. Compile pinned supplied facts
Use new ContextPackCompiler(pack).compile(request, runContext, deps). The caller supplies eligible evidence, conflict markers and promoted memory. The compiler normalizes admission, packs the six canonical buckets, records omissions and emits manifests/evidence gates/runtime obligations.
An applicable policy-expression error rejects compilation with a structured ContextCompileError; it cannot select a permissive false/else branch. Retrieval and current identity verification are implementation-owned dependencies, not live services performed by compilation.
3. Preserve open evidence and escalation
If a required order, identity or refund-window fact is missing, stale, conflicting or omitted, keep the required evidence gate open and block dependent commitment. Obtain an eligible authoritative refresh or entitled resolution, then recompile/revalidate as needed. A model-appended reference does not authenticate the fact.
An independent escalation remains blocking until its actual policy-defined resolution. A finance approval cannot simply clear must_escalate. Evidence sufficiency and dispatch authorization are separate conjunctive requirements.
4. Propose the complete action
Bind the exact actor, purpose, capability/version, resource/order, payment destination, nested arguments, evidence, authority/policy/profile/release pins and integer minor-unit business amount/currency into the action digest. INR minor units are distinct from rupees and from runtime compute cost; every argument’s units must be explicit and consistent.
Native ActionRisk evaluates effect, authority, reversibility, interaction and data scope independently. The five v1 compatibility labels remain unchanged; a lower projection cannot remove a mandatory approval or expand a grant.
5. Verify current authority
A trusted verifier establishes the current requester/workload, owner/tenant/audience scope, root/child run linkage, grant contents, expiry and every ancestor restriction/revocation. Model output, a stored user name or a self-reported verified flag cannot supply that trust.
Already authorized narrow work may proceed without another prompt when no mandatory gate applies. Scheduled or resumed work still needs the current owner mandate, rather than relying on the authority that existed before suspension.
6. Obtain the exact required approval
Use the protected stored proposal/request/action/evidence/pins, current entitled distinct approvers and required quorum. Verify expiry/revocation and any self-approval/separation rules. A general plan approval, evidence-only hash, plugin callback or signature alone is insufficient. A changed amount, destination, nested argument or mandatory pin invalidates the old binding.
Approval redemption is an intended atomic compare-and-swap transition. Its recovery explicitly does not permit an additional effect. The store owner must persist the transition under current revision/operation ownership.
7. Verify actual boundaries and data routes
Require current observed credential, broker, filesystem/process/network/resource controls for every actual execution path, including hosted tools and generated subprocesses. Missing required support or observations block the path rather than choosing weaker containment.
Admit actual data purpose, readers, recipient/processor/residency and source-bound transformations before collection, inference, tool input/output, telemetry, cache, candidate/memory storage, export or delegation. A redaction rule in a compiled manifest does not prove transformation or make the original eligible for an otherwise forbidden processor.
8. Reserve capacity and claim ownership
Use protected atomic operation, approval and budget stores. Claim the stable operation under current lease/generation/revision and target fencing, and reserve capacity before dispatch. Reject stale workers; an audit event cannot serialize competing claims.
Preserve original immutable ceilings and spent/reserved token/tool/replan/cost usage across root work, children, reviewers, repairs, retries and resume. A fresh session is not a fresh workflow allowance. Use exact cost units and trusted cumulative settlement; business refund exposure is a separate constraint.
9. Dispatch and retain uncertainty
Dispatch only after every current mandatory condition passes. Tool response status and external effect state are different. A timeout can follow a committed refund; preserve unknown or partial rather than declaring failure, success or absence from the transport result alone.
Keep the original operation/action identity and provider duplicate/query/recovery pins. Retry after uncertainty only when the declared supported mode and verified provider evidence permit it. A fresh key or an idempotency-conflict message is not proof of safety or completion.
10. Reconcile, stop or compensate honestly
A definitive provider receipt can settle the original operation without granting a stale worker new dispatch authority. A cancellation request remains a request until actual dispatch/children stop is observed; it does not prove the supplier reversed a refund. Retain uncertain reservations until reconciliation supports release.
Compensation is a new governed action with its own current authority, exact approval when required, active controls, preconditions and capacity. A reversal token cannot make an irreversible effect reversible. Re-pinning an old pack governs future work, not past provider effects.
11. Record and evaluate useful work
Produce a complete canonical DecisionRecord with actual status, evidence, policy decisions, approval references, controls, lineage and budget usage. Its statuses include DECIDED, DEFERRED, REJECTED, ESCALATED, IN_FLIGHT and CLOSED; lower-case completed is not a new DecisionStatus. Durable run lifecycle status is a separate type.
Do not finalize useful completion while required effects/children or mandatory escalation remain unresolved. A stored receipt, score of 1.0 or hash chain cannot authenticate its own observations. Protect eligible metadata/payloads and retention; track correction/deletion across derived/cache/exported/delegated copies with bound receipts. Pending or externally unknown copies remain incomplete.
12. Replay without issuing another refund
Retain eligible pinned inputs and recorded model/tool artifacts. Compare deterministic compiler/policy results exactly; use recorded outputs or declared properties/scorecard tolerances for model-dependent stages. Report missing or deleted payloads as replay gaps. A trace ID alone cannot recreate lost state or confer current permission.
The four-case replay exercise is deliberately narrow. It is not evidence that this article executed a payment or reproduced an entire production DecisionRecord byte for byte in eighteen seconds.
Inspect the synthetic composition
The repository-local example below calls the real validators over the existing enterprise fixture. All broker/observer/provider facts are synthetic test inputs. It does not dispatch any effect or persist transitions.
import { enterpriseSupportFixture } from "./tests/fixtures/execution-workflows"
import { negotiateExecutionContract } from "@/lib/contextos/execution-contract"
import { evaluateAuthorization } from "@/lib/contextos/authorization"
import { evaluateBoundaryReadiness, evaluateDataFlow } from "@/lib/contextos/execution-boundary"
import { reserveBudget } from "@/lib/contextos/durable-execution"
import { assessConformanceReport } from "@/lib/contextos/conformance"
const f = enterpriseSupportFixture()
const admission = negotiateExecutionContract(
f.selection.contract, f.selection.support, f.selection.registry, f.selection.features,
)
const authorization = evaluateAuthorization(f.authorization)
const boundary = evaluateBoundaryReadiness(
f.boundary.requirement, f.boundary.observation, f.boundary.evaluation_time,
)
const data = evaluateDataFlow(f.data.request, f.data.policy, f.data.evaluation_time)
const reservation = reserveBudget(f.budget, f.reservation)
const runtimeEvidence = assessConformanceReport(f.conformance)
console.log({
admission: admission.status, authorization: authorization.verdict,
boundary: boundary.allowed, data: data.allowed, reservation: reservation.status,
runtimeEvidence: runtimeEvidence.outcome,
})Place the snippet at repository root so the fixture import resolves, or use the existing tests:
rtk npx vitest run tests/execution-workflows.test.ts tests/authorization.test.ts tests/durable-execution.test.tsThe unchanged enterprise fixture uses 4200 integer INR minor units, not the old article’s ₹24,500 scenario. Successful synthetic checks yield accepted/allow/true, while runtime evidence remains insufficient_evidence. Existing cases reject wrong tenant, actual recipient and stored-proposal substitution; lost-acknowledgement cases preserve identity and forbid blind retry.
The conformance contract needs useful positive and required denial/fault cases with current independent evidence for the actual workflow, implementation, release and environment. A reference pass leaves deployed runtime controls unevaluated and does not certify a payment workflow.