Request a narrow evaluation

The evaluation mode asks a bounded question over a jointly authorized record and returns only one authorized party outcome or indeterminate. It uses the same submissions, record confirmation, AI-first adjudication, Award, webhook, and settlement infrastructure as other cases. Its finality path is pinned: a human appeal for every new track unless both parties expressly waive it.

Output

POST /api/filings with caseMode: evaluation
              ↓
bilateral authorization (before or after claimant confirmation)
              ↓
one simultaneous evidence stage → both confirm records
              ↓
Assigned Tribunal issues Award + pinned appeal stay or bilaterally waived appeal
              ↓
GET /api/cases/{id}/evaluation

Create the evaluation draft

Choose one authorization flow:

Intake mode	Flow
`claimant_proposed`	Claimant confirms → respondent receives an invite → `POST /api/cases/{id}/evaluation/accept` confirms the exact digest
`bilateral_api`	Claimant and respondent independently confirm the immutable case draft before it opens
`bundled_bilateral`	One coordinating partner supplies separate, digest-scoped authority artifacts for both parties and confirms once

claimant_initiated remains the ordinary Complaint/Answer mode and is rejected for evaluations. A platform API key alone never grants authority over both parties.

For bundled_bilateral, both pre-registered consent artifacts must use the exact scope People's Court narrow evaluation {externalEvaluationId} under evaluation digest {evaluationDigest}. Fill in both values from the evaluation draft before registering those artifacts. With bilateral_api, each participant instead confirms the complete case-draft digest independently.

Use PrepareCanonicalFilingInput with caseMode: "evaluation", intakeMode: "bilateral_api", confirmationPolicy: { mode: "all_participants" }, and explicit caseTrack: "ai_standard" with appealWaived: false for AI-only with an appeal. The evaluation definition belongs in evaluation; the review packet binds the exact procedureTerms. Supply its externalEvaluationId, question and criteria, and allowed outcomes with their settlement actions.

The regular transaction, policy, authority, consent, amount, party, and participant fields are also required. Do not send summary, backgroundFacts, or claim; the server derives those record fields from the digest-bound evaluation definition.

Claimant-proposed acceptance

After claimant confirmation, issue or rotate the one-time handoff:

createInvitationPreview returns a hostedLink for the respondent’s account flow. A wallet or independent partner integration that needs the raw evaluation digest and confirmation statement uses the implemented issueRespondentHandoffV2 compatibility method. Its RespondentHandoffV2 result discriminates action: "accept_evaluation"; pass the exact statement and show-once invitation to acceptEvaluationCanonical with NarrowEvaluationAcceptanceInputV2. The canonical invitation response does not expose actionPath or respondentInviteToken.

The proposal cannot reach submissions or adjudication before acceptance. After acceptance, each party reads GET /api/cases/{id}, files through POST /api/cases/{id}/submissions while permitted, and independently confirms its exact record at /record-summary/confirmations. Use the canonical acceptance route with the exact proposal digest and consent statement returned by the invitation. Canonical and versioned aliases share the same acceptance journal. Acceptance claims its idempotency key before checking mutable invite/case state. Retrying the same key and body therefore replays the stored success after the case advances, never repeats the show-once party capability, and a changed body returns idempotency_conflict.

Read the result

GET /api/cases/{id}/evaluation returns pending, under_review, or served.

A served result contains:

Exactly one authorized outcomeCode.
One structured satisfied | not_satisfied | indeterminate finding for every criterion ID.
The settlement action attached to that authorized outcome.

Generic split or conditional Awards are never reinterpreted. An incomplete, out-of-scope, or prose-only evaluation decision is rejected before service.

Finality uses the same appeal projection as decision status and settlement. It distinguishes an unpaid live appeal_reserved checkout window from a docketed appeal_pending review, evaluates deadline expiry directly even before a sweeper updates case status, and treats human merits decisions and decided appeals as final. A human appellate substitution must provide a complete replacement structured evaluation decision; the appealed outcome is never carried into a reversed Award.

Bind and execute settlement

Output

POST /api/cases/{id}/settlement-binding
  → evaluation digest + external reference + adapter + mode
  → allowed actions + USD amount/party/expiry corpus constraints

POST /api/cases/{id}/settlement-executions
  → bindingDigest + dryRun: true     (validation receipt only)
  → bindingDigest + dryRun: false    (derived authorized action)

manual_partner, partner_callback, and platform_adapter are distinct modes. The caller never chooses the settlement action: the boundary derives it from the served structured outcome, verifies the Award/evaluation/binding digests and corpus constraints, and appends an immutable attempt. Live execution requires a dedicated adapter-bound settlement:execute credential. Retries with the same idempotency key return the same attempt.

Register the binding after both parties have authorized the evaluation but before either side closes the merits record. The only accepted dispute states are awaiting_submissions and awaiting_validation, and no Award may exist. The revision/status check and binding insert are one atomic commit. After closing or Award service, a new idempotency key is rejected while the original key and body still replay the stored success.

Settlement bindings currently support USD. The response contains server-derived immutable authority metadata for the authenticated platform credential/principal, represented principal, case authority grant, required settlement:bindings:manage scope, and authorization time. Callers cannot supply this object; it is included in bindingDigest with the corpus contract.