A payment test from task to reviewable evidence
This synthetic, runnable contract example connects the platform, sequence, isolation and recovery diagrams. It is a reference design, not a production gateway or a claim about bank infrastructure. The approved rule is: a negative payment amount returns HTTP 422 and creates no payment.
Pan horizontally to explore the full diagram. A text description is available below.
Research behind this design & diagram description
Lifecycle and action-risk guidance require versioned evidence and scoped authority.
Design implicationProvide joined artifacts and negative fixtures so the logical design can be exercised.
A payment test task binds permitted context, resource scope and deadline. A policy decision authorizes only the sandbox action. An evaluation manifest joins artifact and corpus versions. The evidence record links task, policy and evaluation and remains held for human review.
Inspect methods and source documents →Download and exercise the artifacts
- Complete example bundle and JSON Schema.
- Task envelope: PAY-042, allowed resource, contract digest, context references, deadline and budget.
- Policy decision: DEC-042, identity, policy version, scoped action, expiry and idempotency key.
- Evaluation manifest: EVAL-042, artifact and oracle digests, configuration, corpus, runner and independent checks.
- Evidence record: REC-042 joins every ID and remains held for human review.
- Approved contract and illustrative candidate assertions.
In the repository, run python tools/validate_contracts.py after installing tools/requirements.txt. It checks the schema plus joins, artifact digests, identity, scope, time validity, idempotency binding, independent checks and separation of approval. Ten negative fixtures exercise denial, wrong resources, stale policy, expiry, mismatched artifacts, failed mutation checks, missing evidence and self-approval. Example timestamps are evaluated against the recorded request time, not the reader’s current clock.
The same case across architectural views
| View | Payment case mapping | Boundary assertion |
|---|---|---|
| Component platform | Context → runtime → action gateway → sandbox/evaluation → release owner | Every consequential action passes an independent authorization boundary |
| Runtime sequence | PAY-042 → DEC-042 → EVAL-042 → REC-042 | The artifact reviewed is the artifact that was evaluated |
| Deployment | Runtime identity outside ephemeral sandbox; no production credentials | The negative-amount test cannot access production payment systems |
| Evidence | Immutable content digests plus joined IDs and durable receipt | Missing or inconsistent evidence holds promotion |
| Recovery | Disable new actions, route to manual review, validate fix, owner resumes | Previous side effects require reconciliation; model rollback cannot undo them |
Failure and retry semantics
| Condition | Required behavior | Observable acceptance test |
|---|---|---|
| Runner timeout with unknown completion | Stop issuing actions. Query execution status using the same idempotency key. Retry only an idempotent operation after its outcome is resolved | One logical RUN-042 produces no duplicate execution or side effect |
| Transient read failure | At most two retries with bounded backoff, still within the task deadline and budget | Third failure or expired deadline enters manual queue |
| Expired decision or changed policy version | Deny execution; obtain a fresh decision from the current authority | DEC-042 cannot be replayed after expiry or a policy revision |
| Authorization service unavailable | Fail closed for tool execution; retain a local denial event where possible | No tool invocation and an explicit unavailable reason |
| Evidence store unavailable | Hold promotion. If a configured durable outbox exists, retain a bounded event and reconcile; otherwise halt new actions | No review-ready status without a durable receipt; full outbox stops intake |
| Artifact, oracle or configuration changed | Invalidate prior evaluation and regenerate the evidence | A changed digest cannot reuse EVAL-042 |
| Confirmed control breach | Revoke the task’s execution authority, retain minimal incident evidence and invoke the manual runbook | No automated resumption without owner approval and a passing replay |
The JSON checks demonstrate local contract consistency. Production identity verification, signed decisions, clock handling, secrets, concurrency, durable storage and actual payment behavior require integration tests and platform implementations. The policy version and identity in this fixture are allowlisted examples, not a substitute for an authorization service. [A01][A03][R01]