Follow the decision and execution
Read the authorized case at GET /api/cases/{id}. decision.served means the Award has been released to both parties through the Case Page. decision.finality and its hold reasons describe the pinned procedure. Neither fact confirms payment.
In the served Award and its JSON artifact, fundsInstructions[].timing: "immediate" means the funds instruction is unconditional. When funds may move is governed by the Award’s executionTiming and the applicable Rules stays and holds; the row’s timing value does not authorize immediate payment.
Read execution records at GET /api/cases/{id}/executions, then follow each record’s links.self to GET /api/executions/{id}. A record names the exact Award hash and identifies its mode, status, reports, receipt, and payment provenance. The case view includes execution.mode, execution.executionStatus, execution.paymentConfirmed, and the collection link. Operational partner readers receive status metadata with reports, receipts, and attestation text withheld. A served case without a journal entry still projects its selected mode honestly; an authorized initialize command creates its follow-up record.
Record GETs never prepare an export. HTTP 202 returns data.status: "not_prepared", data.prepare and data.poll. POST completes with status: "ready" and the bundle identity. Retry an interrupted POST with the same key; use a new key to prepare a newer case snapshot. Poll the advertised GET without scheduling work. The case-page download controls and SDK download methods perform this explicit preparation step. Hosted MCP 0.1.1 callers continue using get_case_record_manifest alone; the server prepares and polls internally. The explicit prepare_case_record tool is optional.
| Step | Actor and request | Expected result and next action | Interruption |
|---|---|---|---|
| Observe | A case-authorized party or operational reader calls GET /api/cases/{id}; GET /api/cases/{id}/events provides the authorized docket view. | Inspect decision.served, decision.finality, decision.executable, decision.holdReasons, and execution.status. | An observer’s access does not confer party mutation authority or reveal sealed material. |
| Retrieve the served record | Prepare with POST /api/cases/{id}/record-bundle, JSON { "profile": "party" } and an Idempotency-Key. Then read GET /api/cases/{id}/award and GET /api/cases/{id}/record-bundle; follow the returned artifact download and attestation paths. Verify downloaded artifacts against their published hashes and your signer trust policy. Hand a person GET /api/cases/{id}/record-bundle?format=readable (the case view's links.readableRecord): a self-contained readable record with the caption, timeline, filings, exhibit list and served Award, which prints to a court-ready document. | Exact served artifacts, hashes, and party-scoped record material. | Unserved artifacts, an integrity failure, or insufficient grants stop the read. Do not substitute a locally rendered document for a signed artifact. |
| Exercise a permitted remedy | An authorized party uses the current action for POST /api/cases/{id}/appeals or /post-award-requests, with its required fields, revision, and idempotency key. Read an appeal’s /fee when payment is required. | A recorded remedy or payment requirement and an updated case view. | A reserved fee checkout and a docketed appeal are different states. Effective deadlines continue to apply before any sweeper runs. |
Retained requests and signed supplements
For the current consented tracks, completed execution does not remove the seven-day correction request period after service (Rule 8.3). Rule 8.3 states: “An appeal waiver does not remove this procedure.” Under Rule 8.4, a party may request an additional Award within seven calendar days after service only for a claim that party submitted for decision and the Tribunal inadvertently omitted; the other party may respond within seven calendar days. An additional Award may decide only that omitted claim, and a timely request stays execution until decided even after an appeal waiver. The Rule 4.12 micro-claim procedure has no additional-Award route; a party may instead request a correction or, unless waived, appeal. The existing appellate deadlines remain specific to the affected material. Use the authorized /post-award-requests action; a timely pending request holds fresh execution while existing unknown payment outcomes continue through their original reconciliation process.
The served-Award response may include award.postExecutionSupplements alongside the immutable original Award. Each envelope contains payload, the exact signed canonicalJson, sha256, and signature. The payload binds the source disposition, Award hash and revision, procedure-terms hash, request, issuer and preceding supplement hashes. Amounts use exact {currency:"USD",minorUnits:"…"} objects, and executionEffect is always none. A correction states the corrected obligation without erasing prior performance or creating a second debt for the full amount. An additional monetary component is a separate stated obligation with no automatic payment authority. An incompatible unpaid balance remains held after a monetary correction; a supplement never authorizes a clawback or replacement execution operation.
To request correction of a supplement, include kind: "correction" and sourceSupplement: {id, sha256} using the exact returned coordinate. The target must be verified, belong to this case and have no correction successor when filed. Its seven-day period runs from that supplement’s service; it does not renew the deadline for unrelated original material. Additional-Award requests cannot use sourceSupplement. The issuer kind reviewer identifies only a bounded nonsubstantive correction to an AI-issued Award, not a new human merits decision.
Verify each supplement against your separately configured signer trust policy, its source and its predecessor chain. Never rewrite money or redact a signed payload to make it pass validation. The record bundle preserves the exact payload at record/award/supplements/<index>/payload.json and its signature-bearing envelope at record/award/supplements/<index>/signed-supplement.json. These artifacts accompany the original signed documents and payment receipts.
The four modes
| Mode | What happens | What completion means |
|---|---|---|
partner_executed | The partner receives the decision through the case view and event stream and performs in its own system. | executed requires a provider-verified receipt. Delivery, a report, or a reminder does not establish payment. |
court_escrow | The existing bilateral escrow or x402r lock releases the authorized allocation after all applicable holds. | The provider confirms the exact Award and receipts. Outstanding bilateral withdrawal credits remain pending. |
external_provider | Stripe Connect or ACP executes through its registered adapter. An already captured x402r payment uses its merchant-refund evidence path. | Only a confirmed matching receipt establishes execution. Unknown outcomes remain unresolved. |
decision_only | The served Award states obligations; the parties perform outside People’s Court. | Performance may be reported, acknowledged, or disputed. None of those states means People’s Court executed a payment. |
The settlement binding selects the mode. Without a binding, partner-origin cases use partner_executed and hosted cases use decision_only. Callers cannot switch modes in an execution request. Test and synthetic receipts are shown as simulated, with paymentConfirmed: false.
Report performance
An account session with case membership can POST the following to /api/cases/{id}/executions. A partner acting for a side needs an explicit execution:report membership grant. New claimant filings obtain it only when their authorization expressly includes report_execution; existing authorizations and memberships gain no authority. OAuth needs fresh consent to executions:report; previous scopes do not acquire this authority. Include an Idempotency-Key and the current served awardHash.
{
"action": "report_performance",
"awardHash": "<served Award hash>",
"description": "The ordered payment was sent by bank transfer.",
"reference": "<performance reference>"
}The response is performance_reported. The other side may POST action: "acknowledge" or action: "dispute", with that report’s reportId, the same Award hash, and an optional reason. The reporting side cannot acknowledge its own report. A report and its response record statements without deciding discharge or reconsidering the Award.
Follow partner execution
Delivery begins at decision_delivered; a release request records execution_pending. The execution clock issues durable reminders: by default, a reminder after one day and an overdue status after seven days. Each record captures its deadlines on admission. An overdue result does not prove nonperformance.
The dedicated adapter credential may submit action: "partner_receipt" with a provider reference. The server queries the existing partner provider and requires a confirmed reference bound to the exact Award hash. A partner that will not execute may instead submit action: "will_not_execute" with a reason. That attestation closes follow-up as will_not_execute; it cannot erase an unknown or confirmed provider operation.
Both commands require a signature in addition to bearer authentication. Set x-execution-timestamp to the current Unix time in milliseconds and x-execution-signature to the lowercase hex HMAC-SHA256 of canonical JSON containing caseId, awardHash, idempotencyKey, timestamp, and body. Use the presented bearer credential as the HMAC key; the timestamp is a string. The five-minute acceptance window limits replay exposure. Credential revocation is checked again in the commit transaction. A valid signature authenticates the report; receipt verification is separate.
Request a controlled release
A dedicated settlement:execute credential bound to the case’s adapter may POST action: "request_release" and the Award hash. Party sessions and OAuth reporting tokens cannot release provider funds. The existing execution clock also processes authorized Awards.
Awards with an unwaived internal appeal wait through the seven-day window and all applicable stays. A bilaterally waived appeal removes that appeal wait but leaves every other applicable execution condition intact. Historical cases retain their pinned finality controls. A vacated Award cannot execute. Every provider uses the same journal and execution fence. A timeout returns an unknown outcome, which must reconcile before any provider-proven safe continuation; a new HTTP key never authorizes a second payment.
Live execution providers are enabled separately for each integration. A completed simulation is not a live settlement.
Retries and notifications
Reuse the same key and payload after an interrupted response. A conflicting payload is refused. Current authorization is required on every read and replay. Send execution commands to POST /api/cases/{id}/executions; read the collection at GET /api/cases/{id}/executions and follow each record’s links.self.
The shared event cursor includes award_execution_updated and award_execution_reminder. Signed partner webhooks notify the integration that the execution record changed; read the authorized resource for current details. Preserve event IDs to suppress duplicate delivery. Award documents remain immutable and link conceptually to this separate execution history.
Committed receipt commands replay from the journal after current caller and signature validation, even while the provider is unavailable. A changed reference with the same command identity conflicts. An unknown provider outcome must be reconciled before another payment attempt. submissionAttempts counts adapter invocations, excluding status reads, and is null when a count is unavailable.