- 01Identify
- 02Preserve
- 03Acquire
- 04Extract
- 05Reconstruct
- 06Correlate
- 07Attribute
- 08Validate
- 09Interpret
- 10Report
Scope
SFIF applies to investigations involving synthetic media, AI applications, human-AI interactions, agents, models, identity representations, and provenance. Stages can loop and overlap. Validation begins when a method is selected and continues throughout; its numbered stage makes that work explicit rather than postponing it.
Assumptions
- Collection is authorized and bounded by a defined investigative question.
- Evidence scope, source state, methods, and unavailable material are documented.
- Examiners preserve raw representations and source relationships alongside derived views.
- Confidence depends on the evidence and validation conditions, not the framework’s stage count.
Limitations
This first draft has not undergone independent technical review or empirical validation as a framework. It cannot supply inaccessible cloud records, historical model state, or missing provenance. It does not specify every acquisition technique or jurisdictional requirement. Users must test relevant methods and document deviations.
Version and review
Version: Draft 0.1. Prepared for publication and last updated 1 October 2026. Last independently reviewed: not yet. Initial change: publish the stage model, evidence-to-claim reporting structure, and machine-readable specification for technical review.
Suggested citation: Shelley, J. (2026). Synthetic Forensics Investigation Framework (SFIF), Draft 0.1. SyntheticForensics.org. https://syntheticforensics.org/framework/ — CC BY 4.0. The citation page gives reusable formats.
Technical review is invited on stage boundaries, evidence coverage, failure modes, and reproducibility. Submit specific corrections through the corrections process or use the GitHub gateway when suitable repositories become available. Material historical versions should remain recoverable in release archives and version control.
01Identify
Bound the investigative question and identify potentially relevant systems, evidence, and authority.
- Typical inputs
- The question, authorization, known objects, accounts, devices, platforms, and initial incident information.
- Actions
- Define propositions that can be tested. Inventory media, applications, interactions, agents, accounts, model configuration, and provenance. Record versions and access constraints. Prioritize volatile sources without assuming they exist.
- Outputs
- A scoped question, source inventory, collection priorities, and explicit exclusions.
- Failure modes
- Starting with a detector and treating its result as the entire investigation; collecting without a defined scope; overlooking cloud or external system evidence.
- Validation considerations
- Check that each proposed source has a relationship to the question and that the planned collection is authorized. Record uncertainty in the initial inventory.
02Preserve
Reduce avoidable alteration or loss and document handling of the identified sources.
- Typical inputs
- The inventory, volatility assessment, access permissions, source state, and available collection controls.
- Actions
- Record current state and timing. Protect original objects. Decide whether live collection is necessary and document its effects. Preserve related files and remote records where authorized. Avoid launching applications merely to inspect them.
- Outputs
- Preservation records, source identifiers, custody documentation, and a record of unavoidable changes.
- Failure modes
- Allowing synchronization to alter evidence; assuming a screenshot preserves the full source; losing transient task or browser state while waiting.
- Validation considerations
- Check handling records and the scope preserved. A byte digest supports later comparison; it does not prove that the source was truthful or complete.
03Acquire
Collect evidence in a documented manner that permits examination and integrity checks.
- Typical inputs
- Preserved sources, collection plan, tools, access conditions, and known technical constraints.
- Actions
- Use an appropriate image, logical collection, export, or authorized service request. Capture related records and acquisition metadata. Hash collected objects where applicable. Record tool versions, filters, collection time, and failures.
- Outputs
- Acquired objects, digests, collection logs, scope description, and unavailable-source records.
- Failure modes
- Copying an inconsistent live database; presenting an export as a complete device image; omitting collection filters and failed sources.
- Validation considerations
- Verify acquired file accessibility, expected scope, digests, and collection logs. Explain differences between acquisition types and their limits.
04Extract
Expose relevant records while preserving their connection to the acquired source.
- Typical inputs
- Working copies, schemas, file format documentation, parser versions, and source identifiers.
- Actions
- Parse records and inspect raw data. Retain message and task identifiers, parent-child relations, attachment references, original timestamps, and unsupported fields. Store derived output separately from acquired evidence.
- Outputs
- Source-referenced records, parser logs, normalized views, and a list of unsupported or ambiguous values.
- Failure modes
- Discarding fields because a parser does not recognize them; silently converting time units; flattening a branch graph into a misleading transcript.
- Validation considerations
- Compare samples with raw records and an independent method. Use known-answer fixtures where available, and document parser coverage.
05Reconstruct
Build the sequence and relationships needed to explain the investigated activity.
- Typical inputs
- Extracted events, identifiers, timestamps, branches, tool calls, and transformation records.
- Actions
- Construct timelines and event graphs. Preserve alternate branches and revisions. Distinguish creation, receipt, synchronization, export, and acquisition times. Express intervals when clock relationships are uncertain.
- Outputs
- A source-referenced timeline or graph with explicit gaps and competing orderings where necessary.
- Failure modes
- Ordering by display time alone; treating a generated plan as an executed action; filling missing interaction context with plausible text.
- Validation considerations
- Check every graph edge against its supporting records. Record clock offsets, time resolution, and uncertainty rather than inventing a precise sequence.
06Correlate
Compare sources and test whether their relationships support or conflict with the propositions.
- Typical inputs
- The reconstruction, independent evidence, file digests, account events, network logs, and external system records.
- Actions
- Match reliable identifiers and byte digests. Compare timing with stated tolerances. Identify shared upstream sources. Seek contradictory records and test alternative explanations for apparent matches.
- Outputs
- A correlation matrix showing support, conflicts, source dependence, and unresolved links.
- Failure modes
- Counting replicated copies as independent corroboration; relying only on approximate time; suppressing evidence that conflicts with the preferred hypothesis.
- Validation considerations
- Check whether the sources are independent for the particular claim. A shared backend or parser may produce correlated errors.
07Attribute
Evaluate any supported association with a source, system, workflow, account, model, or actor.
- Typical inputs
- Correlated records, provenance assertions, configuration, authentication context, and alternative source hypotheses.
- Actions
- Name the attribution level. Separate represented identity, account, access mechanism, and human control. Test alias changes, shared accounts, copied content, and delegated actions. Preserve unresolved attribution when support is insufficient.
- Outputs
- A bounded attribution statement, its evidence basis, and explicit alternatives.
- Failure modes
- Naming a model from output style; equating a credential with a person; treating a signed assertion as proof of every origin claim.
- Validation considerations
- Review whether the claimed level is stronger than the evidence permits. Independent corroboration should address the actual attribution proposition.
08Validate
Test the methods and artifact interpretations used in the examination.
- Typical inputs
- Tools, versions, configurations, fixtures, controlled observations, relevant source documents, and reproducible procedures.
- Actions
- Check parser results and timestamp interpretation. Replicate material observations under stated conditions. Test controls and edge cases. Document detector domain and error limits. Record external specifications and trust settings.
- Outputs
- A validation record, repeatable procedures, observed limits, and an updated confidence assessment.
- Failure modes
- Calling a single successful observation “validated”; applying a benchmark outside its tested population; changing a tool version without recording it.
- Validation considerations
- Define what was tested and what was not. Review by another examiner is useful but does not replace an adequate experiment or scope statement.
09Interpret
Assess what the validated evidence supports about the original question.
- Typical inputs
- Observed records, correlations, attribution limits, validation results, conflicts, and unavailable sources.
- Actions
- Separate observation from interpretation and inference. Evaluate alternatives and contradictions. State material assumptions. Explain what would be needed to resolve remaining questions. Avoid translating project confidence labels into percentages.
- Outputs
- Reasoned findings with confidence vocabulary, alternatives, and limitations tied to each proposition.
- Failure modes
- Inferring intent from a prompt alone; treating missing provenance as proof of non-synthetic origin; conflating detector output with a forensic conclusion.
- Validation considerations
- Check that conclusions can be traced to evidence and survive quotation with their essential caveats. Ask whether contrary evidence changes the conclusion.
10Report
Communicate the examination so another reader can assess its basis, scope, and limits.
- Typical inputs
- Findings, source inventory, custody records, methods, versions, validation results, and supporting artifacts.
- Actions
- Report direct observations, interpretations, attribution, and confidence separately. Include unavailable sources, alternative explanations, and reproducibility details. Redact sensitive information proportionately. Version the report and preserve material revisions.
- Outputs
- A dated report, Artifact Reports where appropriate, supporting references, digests, and a recoverable version history.
- Failure modes
- Publishing unsupported certainty; omitting inconvenient gaps; disclosing secrets; silently replacing a materially important conclusion.
- Validation considerations
- Review evidence-to-claim traceability, reproducibility, citation accuracy, and redactions. Confirm that uncertainty remains visible in the final presentation.
Machine-readable reference: sfif.json · Release SHA-256 hashes
Sources & further reading
Source verification checks the official publication and its scope. It is separate from independent technical review of this reference page.
- 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.
- ISO/IEC 27037:2012
Guidelines for identification, collection, acquisition, and preservation of digital evidence. Only the public catalog scope was verified; full text is access-controlled.
- PROV-DM: The PROV Data Model
A model for entities, activities, agents, and derivation relationships; a W3C Recommendation from 2013.
Canonical reference: https://syntheticforensics.org/framework/
Report a technical correction