Digital Forensics / Advanced: models, validation, correlation, and reporting / Lesson 18
Review a complete synthetic analysis package
Connect scope, byte identity, parsing, correlation, time limits, and findings into one reproducible argument.
On this page
Lesson goals
- Trace a finding to exact created inputs and executed local checks.
- Keep unresolved mechanism and attribution distinct from reproducible artifact differences.
Define the fictional question and available material
The classroom package contains two author-created workshop snapshots and an application-like event list. The question is whether the supplied records consistently associate version 2 with import-lab-4, not who performed a real action. The material includes no device image, actual account, browser profile, capture, or private record. State those boundaries and the unknown completeness of any imagined wider system. A complete package can be analytically useful without pretending it is acquired evidence. The workflow demonstrates how separate narrow observations combine into a supported, limited conclusion.
Compare exact fields before explaining a cause
The first program compares two known dictionaries and identifies a version and title change while the workshop id remains fixed. It states the expected differences independently rather than accepting any nonempty diff. The program does not infer the mechanism from the changed title. In an actual analysis, source identity, parsing, and field semantics would need their own verified basis. Preserve both original objects and the comparison rule. A version increment may be application metadata rather than proof of a unique commit, and this fixture assigns its meaning only for the classroom scenario.
before = {"workshop":"w4", "version":1, "title":"Paper Gardens"}
after = {"workshop":"w4", "version":2, "title":"Paper Gardens Revised"}
changed = {key:(before[key], after[key]) for key in before if before[key] != after[key]}
assert changed == {"version":(1,2), "title":("Paper Gardens", "Paper Gardens Revised")}
assert before["workshop"] == after["workshop"]
print("two declared fields changed; workshop identity stayed fixed")
two declared fields changed; workshop identity stayed fixed
The complete program compares local invented objects and performs no collection or mutation of an application. The result establishes the stated fixture differences only. It proves neither a real import nor who caused a change.
Link a declared event without expanding its meaning
The second program selects a supplied event matching workshop, version, and import id. It requires exactly one match in the fixture and retains that narrow statement. It does not establish completeness, source authenticity, or a human actor. If two matches appeared, the analyst would need to explain cardinality rather than choose the first. If no match appeared, the result would remain absence in supplied material rather than proof that no import happened. This explicit relation supports consistency within the fictional package while leaving the imagined external history unestablished.
events = [{"id":"e1","workshop":"w4","version":2,"import":"import-lab-4"}, {"id":"e2","workshop":"w9","version":2,"import":"import-lab-8"}]
matching = [e for e in events if (e["workshop"], e["version"], e["import"]) == ("w4", 2, "import-lab-4")]
assert len(matching) == 1
assert matching[0]["id"] == "e1"
assert "person" not in matching[0]
print("one supplied event consistently references the declared import")
one supplied event consistently references the declared import
The complete program filters two invented events. It does not inspect a log source, authenticate an import, or identify a person. The one-match result is exact for this supplied list and cannot establish the wider event population.
Assemble methods, provenance, and unresolved limits
Include fixture identities and digests, handling and derivation notes, parser version, row accounting, field definitions, comparison rules, correlation keys, raw times, uncertainty, and actual outputs. A manifest should point to the objects and methods rather than invent evidence that was never produced. Distinguish a planning record from an executed check. Keep report derivatives separate from source material and explain disclosure limits. No real acquisition, tool certification, device validation, or legal assessment was performed in this course. Those claims must not appear merely because the package uses familiar forensic terminology.
Write the supported answer and remaining questions
The supplied snapshots differ in version and title, and one supplied event consistently links workshop w4 version 2 to import-lab-4 under the stated key. That is the supported local finding. The package does not establish actual causation, actor identity, intent, clock accuracy, or completeness of a real system. State what additional authorized material would be needed for stronger questions. A reviewer can reproduce the computations and challenge the assumptions without being asked to accept a complete story. This is the central discipline of defensible digital analysis over any bounded material.
Common errors and fixes
The fictional import relation becomes a real causal finding
- Why it happens
- Declared consistency is expanded beyond the created material.
- How to fix it
- State exact fixture relationships and unresolved external questions.
- Prevent it next time
- Keep synthetic provenance visible in the final conclusion.
Any difference passes the comparison
- Why it happens
- The oracle does not specify expected changed and unchanged fields.
- How to fix it
- Assert exact differences and stable identity.
- Prevent it next time
- Review whether the case rejects a plausible wrong observation.
A polished package hides unexecuted checks
- Why it happens
- Planning and presentation are mistaken for observed analysis.
- How to fix it
- Attach actual outputs and preserve pending boundaries.
- Prevent it next time
- Audit claims against executed methods and supplied material.
Check your understanding
1. The event list contains two matching rows. Should the program simply use the first?
Show worked solution
No. Preserve both and investigate whether they represent duplicate delivery, separate observations, or a key that is not unique. Reconcile counts and explain the relationship before making a finding. A first-row shortcut can hide the very ambiguity the case is meant to examine.
2. Write the final conclusion for the executed capstone programs.
Show worked solution
The created snapshots have exactly the stated version/title changes with a stable workshop id, and one supplied event matches the declared workshop/version/import key. These are reproducible local fixture findings. No real acquisition, event causation, person attribution, or legal admissibility was established.
Key takeaways
- A complete package links each claim to actual local observations.
- Consistency within fixtures does not establish external history.
- Reproducible findings can remain partial and useful.