Case protocol — requests, records, prompts and results

P This is the implementation-level companion to Case journeys. The interactive walkthrough shows ten moments per case, including reversal. At each moment its Endpoint requests and saved data section gives the wire request, expected response class, records and next task. At Establish, expand each agent to read its initialization, parent task, task prompt, assembled model input and Karpathy working rules. At Plan / Prove, inspect model responses and inter-agent envelopes. At Act / Reverse, inspect the executor contract. The machine-readable traces contain these examples for all 68 catalogue ids.

The examples use synthetic ids, versions, grants, budgets and observations. They specify message shape and ownership; they are not captured production traffic, published profiles or a claim that a fixture probe exists on the estate. The supplied two-step model Plan/Result demonstrates preparation, not proof of a repaired target. Real implementation binds the same contracts to the published registry and recorded evidence.

1. What happens between screens

The existing One request screen has an action variant for customer-performed steps. Reporting and acceptance are different actions:

All HTTP paths are relative to /ai-support/api/v1, as declared in OpenAPI. The browser sends its Authority token and an Idempotency-Key on mutations. The server scopes the key to authenticated caller and operation, compares the exact body hash, rechecks current authority even on replay and returns 409 for a reused key with a different body or a stale resource/artefact revision. Clicking a page link is a read; it is not another workflow command.

P Attachments in these payloads are references to already uploaded, scanned case material. Raw files and unsanitised body text never become a model prompt just because the customer pressed Answer. Incoming mail/ticket evidence keeps the original actor and source message reference; an operator recording it is not relabelled as the person who executed the target action.

2. The persistence boundary a developer must implement

P Timers without an invented queue. Persist restoration due time in the current execution-obligations paper. The existing scheduler's due-work sweep reads the current papers for cases with parked restoration tasks and atomically queues H7 work using task/obligation id + due revision as its idempotency key. For the first small deployment this is a paged scan of the indexed current paper set, with due values read from the retained bytes; it requires no new table or overloaded execution-deadline column. Missing/unreadable paper bytes raise a visible recovery exception instead of silently skipping restoration. The due time means “evaluate this obligation”, not “fail the case” or “write now”. Rebuild the sweep's disposable due-time cache from papers after restore. A campaign successor obtains its own scoped target references/handle bindings before parent closure; it must not depend on a parent handle map whose retention ends at closure.

P Completion joins authoritative rows. The execution-obligations contract is a readable projection of those records. The service compares it with the approved plan, resolves all references in the current case, verifies member coverage and current scope, and checks no unknown/partial effect or required restoration remains. A model cannot remove a required step from a submitted paper and thereby complete the case. Waiving work requires a separately authorised scope revision; a required step marked waived fails the completion join.

3. Agent initialization and prompt assembly

P A task is initialized from published configuration, not by asking an LLM what powers it wants:

1. Resolve the pinned module/case variant, selected stage and published profile/version. Determine its immediate parent, memory node, allowed tool catalogue and input/output contracts. An Hd child gets an explicit accepted handover, narrowed authority and inherited authorised handle scope.
2. Persist the TASKS row and input paper references. The initial state is open, with no lease owner. The scheduler atomically claims it and advances the fence; only that worker may apply the task's next transition.
3. Intersect profile tools, inherited grants, connector capability and current deny/revocation state. The child cannot expand any of them. A verifier additionally loses access to the investigator transcript; hiding it in a prompt is insufficient.
4. Assemble and store the exact request document in Model Execution § 3's order: platform/profile protocol → available tools and schemas → task/current plan → authority summary → own index and selected knowledge → paper heads/questions → retained conversation → new evidence. Each item carries its source/hash/trust label.
5. Journal provider intent, call IInferenceClient.ExecuteAsync(InferenceRequestV1), persist the returned bytes/usage, validate the model action and tool arguments, then dispatch. The copied transport receives one assembled document and structured output schema; no native tool-calling or hidden chat-history interface is assumed.

P Karpathy discipline is part of the published protocol. The four practices from the workspace rules—state assumptions, keep the implementation minimal, preserve unrelated work, and verify explicit outcomes—become the fixed working-discipline block shown in every illustrative prompt. They are not substituted for insurance knowledge. Domain articles/checklists are separately sourced, versioned, fallible evidence; case requests are task data with an origin. A quotation inside a tariff, ticket or article cannot override scope or promote itself into the platform protocol.

P Task prompt examples are case-specific. In DC-02 the transfers task must enumerate periods and distinguish the MYR variant; the verifier must reject a missing last period even if the master prints. In CF-05 the tariff stage must test every selector/template and its negative caller; the root must join the declared keys. In DV-02 each repository/domain task has a different deliverable—selector code, stored package, registration or external BI template—and the parent joins their versions and print proof. The trace data gives each role's full task text and rendered input rather than one universal “solve the ticket” prompt.

P Deterministic tasks have no LLM prompt. source.test_runner runs the declared commands in the confined worktree. platform.write_executor runs only a constructed, current WritePacketCall. Both return typed results through the same durable task/message machinery. Their inability to invent an action is a code boundary, not a request in an English prompt.

4. Agent responses and communication

P The model produces model-turn v1: tool_calls with registered names and JSON arguments, or a typed message containing a payload and paper reference. The backend supplies case, sender, recipient, task ancestry, message id and time. It validates the payload against message-envelope before storing/delivering it. The model cannot choose another sender identity.

P The same message protocol applies in-process or over the existing Rabbit lanes. Recipient inbox insertion, state transition and outgoing messages share a transaction. On duplicate delivery the saved acknowledgement is returned. A Result arriving twice cannot create two release tasks; a late result from a superseded plan cannot satisfy the current revision.

5. Gates, connector execution and reversal

P Checkpoints decide scope/route/result; effect gates decide the specific mutation or send. The gate set is composed from the current target, write traits and accepted policy. The UI shows the one packet and the holding role; the service records each required decision. A write-auditor pass, parent PlanConfirmation, client business acceptance and technical write grant are four different things.

The connector SDK defines the concrete call:

• OperationCall: operation/version, environment scope, input JSON, stable idempotency key, case/task/runtime-call ids and fence epoch.
• WritePacketCall: that call plus approved shape/version, semantic artefact hash, bound steps with template hashes/concrete parameters/expected counts, assertions, teardown hashes and preflight requirement.
• GrantView: exact scope/mode/target/hash, expiry, reserved call/fence and decision ids; reloaded before dispatch.
• WriteResult: per-step expected/actual counts and returned ids, actual executed statement/call, verification assertions, teardown reference, nullable commit time and landed disposition. It never claims an external owner acted on the platform's credentials.

P Form A completes the deterministic apply/check/replay/commit sequence in one connector call. Form B leases an open transaction only to deterministic code. Form E journals DDL/external effects without claiming transactional rollback. A database-local failed assertion rolls back before commit. A committed partial family change requires reconciliation and a reviewed continuation or H7 compensation; the other database is not rolled back by pretending the two calls were one transaction.

P Reversal has its own stable plan step, current preflight, exact packet, gate decision, grant and runtime-call id. Derive it from the original write log, including generated documents, consumed numbers, published versions and external registrations. Compare target state with what this case wrote before restoring a before-image. If another actor changed it, park for reconciliation. Irreversible residues remain declared; a revert commit is not proof that the old image, package, BPMN and rows now serve the target. Run the reversal's own customer-surface assertions.

6. Four traces that must work before the architecture is accepted

7. After delivery and on the next request

P The result transaction queues the post-result task before acknowledging resolution. That task reads a retained sanitised result package and may run after the session ends or the customer closes the ticket. It records actual achieved outcome, outstanding causal issue, what knowledge was used, which claim failed and whether a reusable change is needed. It proposes to the canonical domain owner and submits the experience to support.curator. A duplicate worker run is idempotent; corrected result revisions retain prior provenance.

P Publication, retrieval and authority are tested separately. The new case first searches the active experience index, pins compatible article/skill versions and records a current applicability check. It can skip rediscovering a known mechanism only when its discriminator passes. It still enumerates its own scope, obtains current target evidence and new authority, and verifies the whole outcome. A contradicted or incompatible article returns the case to investigation; a repeatable trigger can propose a linked causal fix without treating every repair or mirrored ticket as another clean training instance.

P Acceptance boundary. validate_case_journeys.py checks catalogue coverage, synthetic state joins, API payload shapes, model/message envelopes and negative reuse cases. Real repository/service integration, model evaluations, Oracle behaviour and browser/target execution remain necessary implementation acceptance. This document deliberately makes those remaining checks visible.