Represent conversations in Cases
Definition
A canonical Case input can represent a multi-message interaction when correctness depends on prior turns, accumulated context, or state carried across an exchange. “Conversation” describes the shape of the Case input; it is not a separate first-class object or a public schema guarantee.
Use this reference when review or evaluation depends on exactly which messages were available before the response being judged.
Fields, states, or lifecycle rules
- Preserve the message order and roles needed to interpret the Case.
- Identify the response being judged separately from prior user or assistant messages.
- Store supporting documents or structured material according to the Project Input Schema instead of flattening everything into message text.
- Removing, reordering, or summarizing material can change the Case and should follow the normal Case version boundary.
- Output mapping joins an external response to the Case ID; it does not repair missing conversational context.
- This page does not define a public conversation serialization contract.
Related objects
Read this representation with Cases, Outputs, Project Input Schema, and Metadata and Context.
Worked example
Plan context carried across turns
A user first identifies an enterprise plan, then asks whether a feature is available. The later response can only be judged correctly if the earlier plan message remains part of the canonical Case input. If that message is removed, create a new Case version rather than trying to restore it during output mapping.
Source confidence
Code-backed: Case-content services support structured project input and material fields, while record presentation and Case-view types preserve the context used for review. The sources support conversation-shaped Case input but not a distinct Conversation Case object or public import schema.