A graph represents relationships, not just reading order
A conversation graph represents messages as nodes and supported relationships as edges. Those relationships might describe a reply, a selected branch, a revision, or a source transformation. Define the meaning of each edge rather than assuming that every connection means “happened next.”
The graph is an analytical representation unless the source itself provides that exact structure. Preserve the source records and document the mapping so another reader can distinguish recovered application state from layout decisions.
Which fields help preserve the original relationships?
| Evidence or distinction | What it supports | Limit or next question |
|---|---|---|
| Message identifier | Distinguishes nodes within the source’s identifier scope. | A displayed label may be an analyst-assigned identifier. |
| Parent or reply reference | Supports a directed relationship when semantics are validated. | Missing parents should remain explicit. |
| Revision or branch information | Distinguishes alternatives and changed inputs. | A selected view may omit other retained branches. |
| Timestamp and time basis | Helps evaluate recorded chronology. | Ordering by time alone does not recover parentage. |
| Source reference | Connects the graph node to acquired evidence. | Every consequential node needs traceable support. |
Two alternative answers are not two sequential events
Hypothetical example: a source contains one user message and two alternative model responses. A flat transcript lists the responses one after the other. A reader might assume the second response saw the first.
If validated parent references show that both responses descend from the same user message, the graph preserves that branching relationship. The layout can then show alternatives without inventing a conversational sequence between them.
How should a missing parent be represented?
Keep the recovered child and its recorded reference. Mark the parent as unavailable or unresolved rather than creating guessed text. If several sources use overlapping identifier formats, preserve their namespaces so that unrelated nodes are not accidentally merged.
An inferred connection can be useful when labeled and explained. Show which observation supports it and which alternatives remain. W3C PROV provides a general relationship model, but it does not define every chat application’s message fields. PROV-DM: The PROV Data Model.
Checks that make the graph reviewable
Confirm that represented source identifiers resolve or are marked missing. Check for duplicate identifiers, unsupported merges, and edges whose meaning changed during conversion. Where the model assumes acyclic parent relationships, investigate a cycle rather than silently deleting it.
Compare the readable view with the raw record set. State excluded material and the reason for exclusion. A graph that omits attachments or tool outputs may still be useful, but it should not be called the complete runtime context.
What can a conversation graph establish?
It can make recovered relationships, alternative branches, and known gaps easier to inspect. It can prevent a flat transcript from implying a sequence the evidence does not support.
It does not establish intent, every hidden input, or a downstream action. A visually convincing diagram cannot strengthen an unsupported edge. Use the linked reconstruction method for the broader examination workflow and retain the graph’s source mapping with the result.
How the sources support this guide
Source comparison: 2026-10-14. Technical concepts, supporting context, and editorial reasoning are distinguished below.
| Concept | Support | References and limits |
|---|---|---|
| Provenance relationships | Supporting context | PROV-DM: The PROV Data Model PROV represents relationships and derivation; it does not define a universal chat-message graph. |
| Message roles | Direct concept | Transformers — Chat templates Role/content serialization is documented for the named library, not every application’s parent/revision fields. |
| Branches, missing nodes, and inferred edges | Editorial interpretation | NIST SP 800-86 — full publication; PROV-DM: The PROV Data Model The graph representation and branch example are project analytical guidance. Application-specific relationships must be validated separately. |
Citation and editorial context
This is an editorial reference. Source checks are separate from independent expert review; no independent reviewer is recorded.
Examples are hypothetical. See the editorial policy, methodology, and correction process.
Shelley, Jesse (ed.). “Conversation graphs: branches, revisions, and supported relationships.” Synthetic Forensics, 1.1.0-citation-review-1, 2026-10-14. https://syntheticforensics.org/glossary/terms/conversation-graph/ Accessed: add the date you consulted this page.
Sources & further reading
Source verification checks the official publication and its scope. It is separate from independent technical review of this reference page.
- PROV-DM: The PROV Data Model
A model for entities, activities, agents, and derivation relationships; a W3C Recommendation from 2013.
- Transformers — Chat templates
Role/content messages and conversion to a model’s serialized input. This does not document a universal conversation export or revision graph.
- NIST SP 800-86 — full publication
Sections 3–8 and Appendix B cover collection, handling, files, operating systems, applications, and correlation. Published August 2006; AI-specific terminology is not defined here.
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
IT-oriented forensic process and sources; published 2006. It is not a complete investigative procedure or legal advice.
Canonical reference: https://syntheticforensics.org/glossary/terms/conversation-graph/
Report a technical correction