{
"id": "fields",
"schema_version": "1.0",
"version": "1.1.0",
"published": "2026-10-01",
"updated": "2026-10-09",
"last_reviewed": null,
"canonical_url": "https://syntheticforensics.org/data/fields.json",
"license": "CC-BY-4.0",
"items": [
{
"id": "synthetic-media-forensics",
"name": "Synthetic Media Forensics",
"shortName": "Synthetic Media",
"code": "01",
"definition": "Synthetic media forensics examines digital media that may have been generated, altered, or assisted by AI, together with evidence of its creation and transformation.",
"answer": "Examination can combine file structure, encoding, metadata, detection results, creation-side records, and authenticated provenance. Images, video, audio, voice clones, text, and multimodal outputs need different methods. A detector score does not establish provenance; an original file and its associated records often support more useful questions than a circulated copy alone.",
"description": "Examine AI-generated and AI-assisted images, audio, video, and text through file analysis, validated detection, transformation history, and provenance.",
"summary": "Examine the media object, its transformations, and the records behind it.",
"sections": [
{
"id": "scope",
"title": "Scope",
"paragraphs": [
"The object under examination can be wholly generated, partly generated, conventionally edited, or assembled from multiple sources. AI assistance is a workflow property, not a single visual appearance. Separate questions about generation, modification, ownership, and distribution. A synthetic voice can appear inside an otherwise genuine recording; generated text can be embedded in a manually authored document."
],
"items": []
},
{
"id": "why-it-matters",
"title": "Why the field matters",
"paragraphs": [
"A persuasive recording can circulate without its original encoding, timestamps, or production context. The investigative task is to establish which claims the available evidence can support, rather than to assign an authenticity label to every pixel or sentence. This matters when a derivative has become the only publicly available object."
],
"items": []
},
{
"id": "evidence-sources",
"title": "Evidence sources",
"paragraphs": [],
"items": [
"Original media and derivatives, including container structure, codecs, frame timing, audio tracks, and embedded metadata.",
"Editing projects, source images, generation records, uploads, export settings, and model configuration where available.",
"Content Credentials, manifests, cryptographic signatures, watermark results, distribution records, and independently acquired copies."
]
},
{
"id": "questions",
"title": "Typical investigative questions",
"paragraphs": [],
"items": [
"Is this the original file or a transformed copy, and what changed between versions?",
"Which portions are consistent with generation or alteration, and what non-AI explanations remain?",
"Do creation-side records connect a particular workflow to this object?",
"What does a verified provenance assertion actually say, and who signed it?"
]
},
{
"id": "examination-methods",
"title": "Examination methods",
"paragraphs": [
"Preserve the acquired bytes and record the source before decoding or re-encoding. Inventory metadata and file structure, then compare available originals and derivatives. For video, examine temporal as well as frame-level properties; for audio, distinguish codec effects from signal features. Generated text usually lacks a unique durable trace of the model that produced it.",
"Use statistical detectors only with a documented version, tested conditions, and a relevant population. Record false positives, false negatives, thresholds, and sensitivity to transformations when these are known. An unexplained percentage is not a calibrated probability that the case proposition is true. NIST AI 100-4 provides an overview of these method families."
],
"items": []
},
{
"id": "corroboration",
"title": "Corroborating evidence",
"paragraphs": [
"A project file, source asset, application record, or signed creation assertion can connect a media object to a workflow. Compare byte hashes for identical files and explain when perceptual similarity is used for derivatives. Independent sender copies may clarify whether a sharing platform stripped metadata. Two detectors trained on similar material are not necessarily independent corroboration."
],
"items": []
},
{
"id": "failure-modes",
"title": "Common failure modes",
"paragraphs": [],
"items": [
"Treating compression artifacts as unique evidence of AI generation.",
"Testing a screen capture as though it were an unmodified original.",
"Applying an image model to another medium or a text detector outside its validated domain.",
"Reporting a watermark or signature result without the validation settings and trust assumptions."
]
},
{
"id": "limitations",
"title": "Limitations",
"paragraphs": [
"Cropping, transcoding, recompression, noise, and manual edits can alter both detection signals and provenance bindings. Unknown generators and unfamiliar domains can defeat assumptions learned from a test set. Missing metadata can mean that it was removed, was never recorded, or is held elsewhere. These possibilities should remain distinguishable in the report."
],
"items": []
},
{
"id": "reporting-cautions",
"title": "Reporting cautions",
"paragraphs": [
"State what was observed in the exact examined file, then describe the method and the inference. Write “the tested detector classified this derivative as synthetic under these settings” when that is the observation. Do not turn that result into a claim about a named creator or model without separate evidence. Media perception and memory raise additional questions explored by the adjacent project Synthetic Imprinting; those questions do not replace digital examination."
],
"items": []
}
],
"sources": [
"nistSynthetic",
"c2pa",
"nist86"
],
"related": [
"provenance-forensics",
"ai-artifact-forensics",
"synthetic-identity-forensics"
],
"terms": [
"synthetic-media",
"deepfake",
"watermark",
"content-credentials",
"transformation-history"
],
"url": "https://syntheticforensics.org/fields/synthetic-media-forensics/",
"path": "/fields/synthetic-media-forensics/",
"version": "1.1.0",
"last_reviewed": null,
"status": "Reference draft"
},
{
"id": "ai-artifact-forensics",
"name": "AI Artifact Forensics",
"shortName": "AI Artifacts",
"code": "02",
"definition": "AI artifact forensics examines records and residual data created, used, or stored by AI applications and their surrounding device, browser, and cloud environments.",
"answer": "An AI application can leave evidence beyond its visible output: conversation records, attachments, configuration, model labels, caches, logs, session files, and exports. Availability depends on the application version, platform, account state, retention, and acquisition method. This reference identifies artifact classes; it does not assert unverified storage paths or guarantee that deleted conversations can be recovered.",
"description": "Investigate AI application databases, browser storage, logs, exports, synchronization, and deletion with version-specific validation and cautious interpretation.",
"summary": "Recover meaning from application state, storage, logs, and exports.",
"sections": [
{
"id": "scope",
"title": "Scope",
"paragraphs": [
"Examine the relationship between an application’s visible behavior and its underlying records. A message can appear in an interface while different representations exist in a local database, browser storage, remote account, and exported archive. Identify each source separately. A JSON record copied from an export is not equivalent to a directly acquired application database."
],
"items": []
},
{
"id": "why-it-matters",
"title": "Why the field matters",
"paragraphs": [
"The interface may display only the selected branch, latest revision, or synchronized state. Application records can help reconstruct missing context, but they can also contain stale caches, drafts, partial writes, or identifiers whose meaning is undocumented. Reliable interpretation begins with versioned testing rather than a filename that resembles a conversation."
],
"items": []
},
{
"id": "evidence-sources",
"title": "Evidence sources",
"paragraphs": [],
"items": [
"Application databases, including SQLite where actually present; related WAL and shared-memory files when applicable.",
"JSON, logs, session files, conversation records, attachment indexes, model selection, configuration, and export manifests.",
"Browser IndexedDB, LocalStorage, SessionStorage, caches, profile state, and downloads.",
"Authorized cloud exports, synchronization records, account settings, timestamps, and independent device copies."
]
},
{
"id": "questions",
"title": "Typical investigative questions",
"paragraphs": [],
"items": [
"What action creates or updates a record, and which version and platform were tested?",
"Does a timestamp describe creation, server receipt, synchronization, display, or export?",
"Are revisions, branches, uploads, and model changes retained in this source?",
"Does deletion remove a visible item, a local record, remote state, or several copies?",
"What survives restart, logout, clearing storage, offline use, or synchronization?"
]
},
{
"id": "examination-methods",
"title": "Examination methods",
"paragraphs": [
"Inventory sources before launching an application, because startup and synchronization may change state. Document live-collection decisions. Acquire within authorization and preserve originals; perform examination on working copies. For SQLite WAL databases, recently committed content may reside in the WAL before checkpointing. Follow SQLite’s documented file behavior and use a consistent acquisition method; copying one live database file can miss related state.",
"Inspect schema, record types, key relationships, encoding, and null values. Preserve the raw timestamp representation alongside any normalized time. Compare identifiers and content with a controlled interaction conducted in the same application version, operating system, and relevant settings. Test an empty or ordinary session as a control. A parser should expose unsupported fields rather than silently discard them.",
"Separate browser interface semantics from product storage behavior. LocalStorage and SessionStorage describe browser APIs; they do not establish what an AI service stores there. IndexedDB and caches may hold unrelated assets or transient data. Do not label every storage record from an AI domain as evidence of generation."
],
"items": []
},
{
"id": "corroboration",
"title": "Corroborating evidence",
"paragraphs": [
"Compare a parsed message with an authorized export, acquired attachment, browser visit, and independently collected device or service record. Check whether sources share the same backend; copies of one record do not add independent support. Tie local downloads to file digests and examine whether filenames or timestamps were assigned by the exporting system."
],
"items": []
},
{
"id": "failure-modes",
"title": "Common failure modes",
"paragraphs": [],
"items": [
"Publishing a storage path from a different version as a universal artifact location.",
"Opening evidence in the original application and allowing writes or synchronization.",
"Converting timestamps without verifying units, epoch, timezone, or event meaning.",
"Claiming recovery from a deletion test conducted only once or under different retention settings.",
"Interpreting a stale cache as the final conversation state."
]
},
{
"id": "limitations",
"title": "Limitations",
"paragraphs": [
"Encrypted storage, remote-only state, retention limits, access restrictions, schema changes, and acquisition gaps can prevent reconstruction. File deletion, application deletion, and account deletion are different operations. Residual content is not guaranteed after any of them. General database recovery possibilities cannot establish a particular product’s persistence behavior."
],
"items": []
},
{
"id": "reporting-cautions",
"title": "Reporting cautions",
"paragraphs": [
"Use an Artifact Report to record the tested environment, creation behavior, persistence, deletion, synchronization, and validation status. Describe “a record with these values was present in this acquired source” before assigning an event meaning. Report inaccessible and untested sources. Anti-Forensics.com is an adjacent resource for digital evidence and anti-forensic considerations; it is not an authority that validates this site’s findings."
],
"items": []
}
],
"sources": [
"sqlite",
"storage",
"webStorage",
"nist86"
],
"related": [
"interaction-forensics",
"agent-forensics",
"model-forensics"
],
"terms": [
"ai-artifact",
"forensic-artifact",
"persistence",
"sqlite-wal",
"timestamp-normalization",
"synchronization"
],
"url": "https://syntheticforensics.org/fields/ai-artifact-forensics/",
"path": "/fields/ai-artifact-forensics/",
"version": "1.1.0",
"last_reviewed": null,
"status": "Reference draft"
},
{
"id": "interaction-forensics",
"name": "Interaction Forensics",
"shortName": "Interaction Forensics",
"code": "03",
"definition": "Interaction forensics reconstructs human-AI exchanges and their context, revisions, branches, tool activity, and downstream consequences from available evidence.",
"answer": "A conversation is a sequence of events, not just a prompt and a final answer. Reconstruction can connect inputs, uploaded material, model selection, responses, revisions, regeneration, tool calls, and user actions. Reconstructing an interaction does not automatically establish intent. Missing context and incomplete exports must be recorded rather than filled with assumptions.",
"description": "Reconstruct prompts, responses, branches, uploads, tool calls, and downstream actions while distinguishing recorded input from inferred human intent.",
"summary": "Reconstruct exchanges, context, revisions, and downstream actions.",
"flow": [
"Human Input",
"Context",
"Model Response",
"Revision / Regeneration",
"Tool or Agent Action",
"Downstream Artifact"
],
"sections": [
{
"id": "scope",
"title": "Scope",
"paragraphs": [
"The unit of examination is the interaction and its relationships. It can include prompts, system or application context when available, retrieval material, attachments, model labels, selected branches, edits, and responses. Separate content presented to a model from content merely stored in the same account. A rendered transcript can flatten relationships that existed in the source."
],
"items": []
},
{
"id": "why-it-matters",
"title": "Why the field matters",
"paragraphs": [
"A quoted prompt may omit an earlier correction, uploaded instructions, or a regenerated response. The final document may combine several responses with manual edits. Reconstructing these transitions can explain a workflow without claiming access to the person’s beliefs, motive, or complete mental state."
],
"items": []
},
{
"id": "evidence-sources",
"title": "Evidence sources",
"paragraphs": [],
"items": [
"Acquired conversation records, authorized exports, message identifiers, branches, revisions, and regeneration relationships.",
"Uploads, attachment hashes, retrieval references, available context, model selection, and application settings.",
"Tool-call messages and results, timestamps, browser activity, generated files, and downstream user edits."
]
},
{
"id": "questions",
"title": "Typical investigative questions",
"paragraphs": [],
"items": [
"Which response belongs to which input, and were alternate responses retained?",
"What context was demonstrably available at the relevant turn?",
"Was a revision made by a person, an application, or a further model response?",
"Can a later file be connected to a specific response rather than just similar wording?",
"Which intervals and branches are absent from the acquisition?"
]
},
{
"id": "examination-methods",
"title": "Examination methods",
"paragraphs": [
"Preserve source structure before constructing a readable transcript. Map message identifiers, parent-child relationships, attachment references, and source timestamps. Build an event graph where branches exist rather than forcing every record into a single sequence. Record the difference between a server event time and a local display or export time.",
"Use raw records to verify selected transcript passages. Compare revisions and identify which representation an interface or export chose. Associate tool activity by identifiers when possible; approximate temporal proximity is weaker evidence. Re-run a prompt only as a controlled experiment: nondeterminism, changed context, model updates, and unavailable settings limit comparison with a historical exchange."
],
"items": []
},
{
"id": "corroboration",
"title": "Corroborating evidence",
"paragraphs": [
"Match attachments and generated files by digest where identical bytes exist. Correlate independent download, editing, or execution records with the conversation event graph. Distinguish a participant’s recollection from recorded activity. Synthetic Imprinting concerns memory and interpretation of synthetic information, an adjacent cognitive subject rather than an interchangeable forensic method."
],
"items": []
},
{
"id": "failure-modes",
"title": "Common failure modes",
"paragraphs": [],
"items": [
"Treating the currently selected branch as the only response ever produced.",
"Assuming an export includes hidden context, deleted records, or every tool call.",
"Reading a generated statement about an action as evidence that the action occurred.",
"Inferring intent solely from an instruction copied into a conversation."
]
},
{
"id": "limitations",
"title": "Limitations",
"paragraphs": [
"Providers may withhold internal state and context; applications can trim or summarize prior turns. An acquired prompt history may be incomplete. User-controlled text can include quoted material or adversarial instructions. Similar outputs may come from different systems, and an experimental replay cannot recover an inaccessible historical state."
],
"items": []
},
{
"id": "reporting-cautions",
"title": "Reporting cautions",
"paragraphs": [
"Publish a source-referenced timeline with explicit gaps. Label direct message content as observed, event relationships as corroborated or inferred as appropriate, and intent as unresolved unless separate evidence supports it. Identify the level of completeness supported by the collection instead of calling the transcript “the complete interaction” by default."
],
"items": []
}
],
"sources": [
"nist86",
"prov",
"mcp"
],
"related": [
"ai-artifact-forensics",
"agent-forensics",
"provenance-forensics"
],
"terms": [
"prompt",
"prompt-history",
"prompt-reconstruction",
"regeneration",
"response-revision",
"human-ai-interaction"
],
"url": "https://syntheticforensics.org/fields/interaction-forensics/",
"path": "/fields/interaction-forensics/",
"version": "1.1.0",
"last_reviewed": null,
"status": "Reference draft"
},
{
"id": "agent-forensics",
"name": "AI Agent Forensics",
"shortName": "AI Agent Forensics",
"code": "04",
"definition": "AI agent forensics examines AI-driven task execution, tool use, state, delegation, and effects on local or external systems.",
"answer": "An agent investigation follows activity across the initiating human, agent runtime, tools, external systems, and resulting artifacts. It can involve browser actions, shell commands, filesystem changes, APIs, MCP activity, credentials, and delegated agents. A plan is not an execution record. External effects need corroboration from the systems affected, not only the agent’s account of its own work.",
"description": "Follow AI agent tasks across tools, APIs, delegated agents, browser activity, shell commands, files, and external systems using corroborated event graphs.",
"summary": "Follow delegated actions from task initiation to external effects.",
"flow": [
"Human",
"Agent",
"Tool",
"External System",
"Resulting Artifact"
],
"sections": [
{
"id": "scope",
"title": "Scope",
"paragraphs": [
"Examine task initiation, runtime state, visible planning records, memory, available tool permissions, execution attempts, and resulting changes. Some agents delegate to sub-agents or invoke tools through an intermediary. Each transition may have different identifiers, clocks, logging policies, and access constraints. Do not assume that a visible plan exposes all internal computation.",
"For a practical walkthrough, read the AI Agent Forensics guide, including evidence to preserve, action states, an email example, and common questions."
],
"items": []
},
{
"id": "why-it-matters",
"title": "Why the field matters",
"paragraphs": [
"An agent’s output can be an action as well as text. A task may change files, send an API request, browse a site, or trigger another process. Explaining the resulting artifact requires a record of which boundary was crossed, with which permissions, and what outcome the affected system recorded."
],
"items": []
},
{
"id": "evidence-sources",
"title": "Evidence sources",
"paragraphs": [],
"items": [
"Task initiation, agent state, accessible planning and memory records, runtime configuration, and session identifiers.",
"Tool descriptions, call arguments, results, MCP messages, API request identifiers, browser activity, shell commands, and exit status.",
"Filesystem changes, before-and-after hashes, system logs, network records, authentication events, and external audit logs.",
"Delegation records, parent and sub-agent task identifiers, permission grants, and credentials references handled as sensitive evidence."
]
},
{
"id": "questions",
"title": "Typical investigative questions",
"paragraphs": [],
"items": [
"Who or what initiated the task, and what authorization was recorded?",
"Was a tool call attempted, accepted, completed, retried, or rejected?",
"Which agent or sub-agent acted under which account and permission boundary?",
"Do system logs and resulting artifacts support the reported outcome?",
"Did an external effect occur after an interruption or outside the visible task interval?"
]
},
{
"id": "examination-methods",
"title": "Examination methods",
"paragraphs": [
"Create an evidence graph linking task, agent, tool, external system, and artifact nodes. Preserve raw request and result records with their identifiers. Add authentication and permission context without publishing credential values. Correlate commands with process execution, file changes, and network evidence where those sources were acquired.",
"Record proposed actions, attempted actions, and confirmed effects separately. For delegated work, retain parent-child relationships and examine whether results were incorporated by the initiating agent. Treat retries and asynchronous completion as distinct events. MCP specifies tool-call semantics; implementations determine whether durable logs are kept and which fields are retained."
],
"items": []
},
{
"id": "corroboration",
"title": "Corroborating evidence",
"paragraphs": [
"A successful API response may be corroborated by an external audit event or resulting object. A shell transcript can be checked against process and file records; a browser action against destination-side evidence where authorized. Sources controlled by the same agent runtime share failure risks. Explain when independent corroboration was unavailable."
],
"items": []
},
{
"id": "failure-modes",
"title": "Common failure modes",
"paragraphs": [],
"items": [
"Taking “completed” in a generated summary as independent proof of execution.",
"Losing request identifiers while flattening multiple tool calls into prose.",
"Attributing a sub-agent action to a human without showing the delegation chain.",
"Treating tool permissions as evidence that every permitted action occurred.",
"Publishing secrets contained in arguments, logs, or authentication traces."
]
},
{
"id": "limitations",
"title": "Limitations",
"paragraphs": [
"Transient state, partial logging, asynchronous tasks, remote execution, and clock differences can break continuity. A tool result can report success before the external effect is durable. A credential identifies an access mechanism; it does not by itself establish who controlled the initiating session. Historical agent behavior may not be reproducible after tool or model changes."
],
"items": []
},
{
"id": "reporting-cautions",
"title": "Reporting cautions",
"paragraphs": [
"Describe the exact action boundary and level of confirmation. Report “a call requested a file write” separately from “the acquired filesystem contained the resulting bytes.” Identify gaps in the delegation and authentication trail. Include timeline uncertainty and redact sensitive credentials while preserving the unredacted evidence through appropriate controls."
],
"items": []
}
],
"sources": [
"mcp",
"nist86",
"prov"
],
"related": [
"interaction-forensics",
"ai-artifact-forensics",
"model-forensics"
],
"terms": [
"agent",
"tool-call",
"delegation",
"mcp",
"corroboration",
"timeline-reconstruction"
],
"url": "https://syntheticforensics.org/fields/agent-forensics/",
"path": "/fields/agent-forensics/",
"version": "1.1.0",
"last_reviewed": null,
"status": "Reference draft"
},
{
"id": "model-forensics",
"name": "Model Forensics",
"shortName": "Model Forensics",
"code": "05",
"definition": "Model forensics examines evidence about AI model identity, configuration, lineage, integrity, and modification within a particular deployment.",
"answer": "Model evidence can include deployment records, configuration, metadata, fine-tuning history, adapters, and legitimately available weights. It can support an association with a model or family, or an integrity comparison with a known reference. Output alone rarely permits certain identification. A displayed model name may be an alias whose historical meaning requires verification.",
"description": "Assess model identity, deployment configuration, lineage, fine-tuning, integrity, and attribution limits using documented records and acquired model evidence.",
"summary": "Assess model lineage, configuration, identity claims, and integrity.",
"sections": [
{
"id": "scope",
"title": "Scope",
"paragraphs": [
"The examined system may combine a base model, fine-tuned weights, adapters, retrieval sources, safety policies, routing, and tools. Define whether the question concerns a model file, an endpoint, a model family, or the whole deployed workflow. These are different attribution levels. Only inspect weights or proprietary records when legitimately available."
],
"items": []
},
{
"id": "why-it-matters",
"title": "Why the field matters",
"paragraphs": [
"A changing service alias can obscure which implementation answered a historical request. A local deployment can use modified weights while retaining a familiar label. Conversely, identical model bytes can behave differently under different configuration or context. An integrity finding and a behavioral finding therefore need separate evidence."
],
"items": []
},
{
"id": "evidence-sources",
"title": "Evidence sources",
"paragraphs": [],
"items": [
"Model metadata, registry records, deployment manifests, configuration, version history, and access logs.",
"Fine-tuning records, data references, adapter settings, lineage assertions, and legitimately acquired weight files.",
"Known reference digests, signed distribution records, runtime logs, evaluation inputs, and documented outputs."
]
},
{
"id": "questions",
"title": "Typical investigative questions",
"paragraphs": [],
"items": [
"Which identity is directly recorded, and does it refer to a stable version or an alias?",
"Can the acquired model bytes be compared with a known, independently obtained reference?",
"What fine-tuning or configuration changes were documented?",
"Does evidence support tampering, a backdoor hypothesis, or only unexplained behavior?",
"Which attribution level remains plausible if deployment records are missing?"
]
},
{
"id": "examination-methods",
"title": "Examination methods",
"paragraphs": [
"Preserve model files and configuration with digests, source details, and acquisition scope. Compare bytes and metadata with a documented reference; validate the reference’s provenance. Map the deployment’s components before attributing behavior to the base model. For behavioral tests, record prompts, context, parameters, tools, versions, and controls.",
"Investigate suspected tampering or backdoors through a defined hypothesis and reproducible tests. A surprising response is not proof of a malicious modification. Distinguish input-sensitive behavior, configuration effects, and altered model artifacts. Report limitations when weights, training records, or historical deployment state cannot be examined."
],
"items": []
},
{
"id": "corroboration",
"title": "Corroborating evidence",
"paragraphs": [
"A deployment record, signed release, registry entry, and file digest can support a lineage or integrity statement when their sources are trustworthy and their relationships are clear. Vendor identity assertions are useful records but are not independent validation. Correlate service logs and configuration changes with the interval of the investigated interaction."
],
"items": []
},
{
"id": "failure-modes",
"title": "Common failure modes",
"paragraphs": [],
"items": [
"Claiming a named model from writing style, phrasing, or a generated self-identification.",
"Treating a matching label as a matching file or deployment.",
"Equating byte integrity with the absence of harmful behavior.",
"Generalizing one behavioral experiment to every version or configuration."
]
},
{
"id": "limitations",
"title": "Limitations",
"paragraphs": [
"Hosted services may withhold weights and routing details. Model families can share output characteristics, and fine-tuning may alter them. A digest establishes a byte comparison with a reference; it does not establish the training process, authorized ownership, or semantic safety of the model. Unknown historical settings limit replay."
],
"items": []
},
{
"id": "reporting-cautions",
"title": "Reporting cautions",
"paragraphs": [
"State whether attribution is to a file, version label, endpoint, family, or workflow. Name the evidence that supports the association and the alternatives that remain. Avoid guaranteed identification claims. Report tampering as a supported conclusion only when the tested evidence supports that proposition, rather than treating every unexpected response as a backdoor."
],
"items": []
}
],
"sources": [
"hash",
"aiRmf",
"prov"
],
"related": [
"agent-forensics",
"ai-artifact-forensics",
"provenance-forensics"
],
"terms": [
"model-attribution",
"model-provenance",
"fine-tuning",
"model-lineage",
"integrity"
],
"url": "https://syntheticforensics.org/fields/model-forensics/",
"path": "/fields/model-forensics/",
"version": "1.1.0",
"last_reviewed": null,
"status": "Reference draft"
},
{
"id": "provenance-forensics",
"name": "Provenance Forensics",
"shortName": "Provenance",
"code": "06",
"definition": "Provenance forensics examines records and claims about the origin, derivation, handling, and transformation of content, interactions, models, and workflows.",
"answer": "Provenance examination asks what history is documented, what is cryptographically bound to an object, who made the assertions, and which links can be independently checked. A signature’s validity, a signer’s trustworthiness, and a claim’s truth are separate questions. The absence of provenance information is not proof that content is non-synthetic.",
"description": "Evaluate content, interaction, model, and workflow provenance through manifests, signatures, assertions, transformation history, and explicit trust assumptions.",
"summary": "Verify recorded history, signed assertions, bindings, and trust.",
"sections": [
{
"id": "scope",
"title": "Scope",
"paragraphs": [
"Content provenance concerns a media object and its derivatives. Interaction provenance concerns an exchange and its sources. Model provenance concerns lineage and configuration. Workflow provenance connects steps and actors. The W3C PROV model offers a vocabulary for relationships; C2PA specifies a content provenance system. Neither means that every platform records a complete history."
],
"items": []
},
{
"id": "why-it-matters",
"title": "Why the field matters",
"paragraphs": [
"A media classifier can estimate a pattern without documenting origin. A provenance record can document an assertion without resolving whether the signer was authorized or accurate. Examination needs both technical validation and an explicit account of the trust decisions. It must also describe where the documented history begins and ends."
],
"items": []
},
{
"id": "evidence-sources",
"title": "Evidence sources",
"paragraphs": [],
"items": [
"Embedded and external manifests, Content Credentials, assertions, signatures, certificates, and referenced ingredients.",
"Metadata, project histories, signed distribution records, interaction logs, model release records, and workflow manifests.",
"Watermark results, independent original files, and records of export, stripping, or transformation."
]
},
{
"id": "questions",
"title": "Typical investigative questions",
"paragraphs": [],
"items": [
"Is the record bound to the examined object, and what does that binding cover?",
"What assertion was signed, by whom, and under which trust policy?",
"Are referenced ingredients and earlier manifests available for examination?",
"Where are the gaps, and can export or stripping explain a missing record?",
"Do independent records support the asserted transformation or origin?"
]
},
{
"id": "examination-methods",
"title": "Examination methods",
"paragraphs": [
"Preserve object and manifest bytes before using a validator. Record the specification revision, software version, validation settings, trust list, certificate results, and any referenced resources that were unavailable. Distinguish an invalid signature, an untrusted signer, an unavailable record, and an unsupported feature.",
"Construct a relationship map for transformations and claims. A manifest may be internally consistent while omitting an earlier workflow. Compare signed assertions with independent creation records. Treat a watermark as a method-specific signal whose interpretation depends on its scheme and validation conditions; it is not interchangeable with a cryptographic signature."
],
"items": []
},
{
"id": "corroboration",
"title": "Corroborating evidence",
"paragraphs": [
"Compare claimed creation and editing events with project records, source assets, account events, and independently acquired copies. Verify cryptographic references against the actual bytes they address. Record where an origin claim relies on a signer’s assertion rather than directly observed creation-side evidence."
],
"items": []
},
{
"id": "failure-modes",
"title": "Common failure modes",
"paragraphs": [],
"items": [
"Calling a file “authentic” because a signature validated without specifying the claim.",
"Confusing an absent manifest with proof of an ordinary camera origin.",
"Assuming metadata is trustworthy because it is embedded in a file.",
"Presenting a provenance chain without indicating unavailable ingredients or trust decisions."
]
},
{
"id": "limitations",
"title": "Limitations",
"paragraphs": [
"Provenance can be partial, selectively recorded, inaccessible, or removed. Trust stores and validation software change. A compromised signer can make misleading claims, and a legitimate signer can record limited information. Cryptographic integrity is a narrower conclusion than factual accuracy, creator identity, or completeness."
],
"items": []
},
{
"id": "reporting-cautions",
"title": "Reporting cautions",
"paragraphs": [
"Quote the meaningful assertion and state the validator result separately. Describe the object binding, signature verification, trust policy, and independent corroboration. Use “no supported provenance record was found in the acquired sources” rather than “no provenance exists.” Link any unresolved gap to the investigative question it constrains."
],
"items": []
}
],
"sources": [
"c2pa",
"prov",
"hash",
"timestamp"
],
"related": [
"synthetic-media-forensics",
"interaction-forensics",
"model-forensics"
],
"terms": [
"provenance",
"manifest",
"cryptographic-signature",
"content-credentials",
"provenance-gap"
],
"url": "https://syntheticforensics.org/fields/provenance-forensics/",
"path": "/fields/provenance-forensics/",
"version": "1.1.0",
"last_reviewed": null,
"status": "Reference draft"
},
{
"id": "synthetic-identity-forensics",
"name": "Synthetic Identity Forensics",
"shortName": "Synthetic Identity Forensics",
"code": "07",
"definition": "Synthetic identity forensics examines evidence of generated or manipulated identity representations, synthetic personas, impersonation, and related account activity.",
"answer": "An investigation may connect generated faces, voice cloning, account traces, metadata, behavior, and cross-platform activity. A synthetic representation is not the same as a identified operator. Evidence of impersonation or coordinated accounts needs source-referenced correlation, careful attribution, and proportionate handling of personal information. Similar faces or posting patterns alone do not establish common control.",
"description": "Examine generated personas, voice cloning, identity fusion, impersonation, and account clusters while preserving privacy and stating attribution limits.",
"summary": "Examine represented identities, account traces, and coordination.",
"sections": [
{
"id": "scope",
"title": "Scope",
"paragraphs": [
"Separate the represented identity, the account, the access mechanism, and the person controlling it. A persona can mix invented details with information about real people, a process sometimes described as identity fusion. A voice clone may impersonate a real person without proving that person participated. Coordination is a relationship between activities, not a property of an avatar alone."
],
"items": []
},
{
"id": "why-it-matters",
"title": "Why the field matters",
"paragraphs": [
"A convincing identity representation can redirect attention from the actual account or workflow. The examiner needs to connect claims to records while avoiding an unsupported accusation against the person being imitated. Privacy limits also matter because cross-platform correlation can expose unrelated individuals."
],
"items": []
},
{
"id": "evidence-sources",
"title": "Evidence sources",
"paragraphs": [],
"items": [
"Profile images, voice samples, source files, media provenance, embedded metadata, and known transformation records.",
"Account creation and access records, authorized exports, posting history, identifiers, sharing relationships, and authentication traces.",
"Cross-platform links, reused assets, timing patterns, independent communications, and coordination records within authorized scope."
]
},
{
"id": "questions",
"title": "Typical investigative questions",
"paragraphs": [],
"items": [
"Is the represented identity generated, manipulated, impersonated, or simply unverifiable?",
"Which records connect a media asset to an account and a period of use?",
"Do independent traces support common control across accounts?",
"Could shared scheduling, syndicated content, or copied assets explain similarity?",
"Which personal details are necessary to answer the authorized question?"
]
},
{
"id": "examination-methods",
"title": "Examination methods",
"paragraphs": [
"Preserve account context and original media where available. Record acquisition dates because profiles and identifiers change. Compare asset digests for identical files and describe perceptual comparisons separately. Build a graph of accounts, assets, timestamps, and observed links, labeling inferred edges.",
"Evaluate coordination against plausible alternatives. Multiple accounts can share a stock image, copied biography, or common service without sharing an operator. Correlate behavior with independently acquired access or workflow records when lawful and available. Restrict collection and publication to the minimum identity information required for the examination."
],
"items": []
},
{
"id": "corroboration",
"title": "Corroborating evidence",
"paragraphs": [
"Creation-side records, an independently acquired source asset, authorized account access logs, or a documented communications chain can strengthen a link. A media detector and an avatar similarity measure examine representations; neither identifies an operator. Shared IP addresses can reflect infrastructure or households rather than a single person."
],
"items": []
},
{
"id": "failure-modes",
"title": "Common failure modes",
"paragraphs": [],
"items": [
"Equating a generated face with a fraudulent account without examining the account’s claims.",
"Naming an operator solely from resemblance, writing style, or shared infrastructure.",
"Collapsing accounts and represented persons into one graph node.",
"Collecting unrelated sensitive personal information to make a cluster look more complete."
]
},
{
"id": "limitations",
"title": "Limitations",
"paragraphs": [
"Platforms may restrict historical data, and public records can be curated or manipulated. Account access can be shared or compromised. Media provenance may be absent, and cross-platform identifiers may not be stable. A supported finding about a synthetic representation can coexist with unresolved operator attribution."
],
"items": []
},
{
"id": "reporting-cautions",
"title": "Reporting cautions",
"paragraphs": [
"State whether the conclusion concerns a representation, an account, coordination, or human control. Protect the person being impersonated and distinguish them from an alleged operator. Include competing explanations for each inferred cluster relationship and disclose the scope limits of acquired account evidence."
],
"items": []
}
],
"sources": [
"nistSynthetic",
"nist86",
"prov"
],
"related": [
"synthetic-media-forensics",
"agent-forensics",
"provenance-forensics"
],
"terms": [
"synthetic-identity",
"voice-cloning",
"impersonation",
"identity-fusion",
"attribution"
],
"url": "https://syntheticforensics.org/fields/synthetic-identity-forensics/",
"path": "/fields/synthetic-identity-forensics/",
"version": "1.1.0",
"last_reviewed": null,
"status": "Reference draft"
}
],
"classification_status": "Project working taxonomy; not externally standardized"
}