> For the complete documentation index, see [llms.txt](https://peoplescourt.ai/llms.txt). This page is also available as Markdown.

# 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`.

```json
{
  "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.