Chapter 4 — Evidence preservation and case records

Lesson map

Lesson 04 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Preservation answers a question"]
  N2["4.2 New cards: one export and one screenshot"]
  N3["4.3 A two-stage collection receipt"]
  N4["4.4 A safe byte-integrity lab"]
  N5["4.5 Evidence packages need an explicit negative clai"]
  N6["4.6 Use a provenance model that can survive handoff"]
  N7["4.7 Distinguish integrity, authenticity, completenes"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Preservation answers a question"]
  N2["4.2 New cards: one export and one screenshot"]
  N3["4.3 A two-stage collection receipt"]
  N4["4.4 A safe byte-integrity lab"]
  N5["4.5 Evidence packages need an explicit negative clai"]
  N6["4.6 Use a provenance model that can survive handoff"]
  N7["4.7 Distinguish integrity, authenticity, completenes"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX016"]

[Learning outcomes]
    |
    v
[4.1 Preservation answers a question]
    |
    v
[4.2 New cards: one export and one screenshot]
    |
    v
[4.3 A two-stage collection receipt]
    |
    v
[4.4 A safe byte-integrity lab]
    |
    v
[4.5 Evidence packages need an explicit negative clai]
    |
    v
[4.6 Use a provenance model that can survive handoff]
    |
    v
[4.7 Distinguish integrity, authenticity, completenes]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

The learner can specify a bounded collection request, keep an original separate from an analysis copy, verify byte integrity where bytes are available, reconcile timezones and state the limits of an incomplete custody record. The goal is a repeatable case trail for a second responder, not a declaration that a file or screenshot proves a legal conclusion.

4.1 Preservation answers a question

The 09:14 decision asked whether detailed IdP records could distinguish account sessions and clients before a stated 10:00 expiry. The analyst should request a source, time interval, fields, account or session selectors, purpose, authority and destination. A reasonable first request is IdP detailed events for svc-enroll, 08:50–09:05 UTC, including event ID, source timestamp and timezone, account, session, client, outcome and any export metadata. The custodian decides whether the requested fields and scope are permitted. If the source stores all identities in a shared object, the analyst does not independently broaden collection; the custodian should propose the least-privileged way to satisfy the question.

Preservation is not the same as analysis. A custodian may copy source bytes to an access-controlled evidence store; an analyst may parse a read-only working copy; a reviewer may compare notes. Each should leave a separate receipt: who, what, from where, when, under which approval, with which tool or method and which integrity result. A hash helps detect a later byte change to the hashed object, not prove that the source system emitted truthful events or that a screenshot depicts the authoritative state. NIST SP 800-86 discusses forensic techniques from an IT perspective, and NIST SP 800-92 discusses log-management planning. This book's record fields and synthetic workflow are instructional examples; the organization's current evidence policy governs a live case.

4.2 New cards: one export and one screenshot

Assume the fictional identity custodian obtained case approval at 09:16 for the bounded IdP request. This approval is part of card C09, introduced now; it was not available in Chapter 3. At 09:18 the custodian provides C09, a UTF-8 CSV export described as sourced from the 08:50–09:05 UTC IdP window. Its readable summary contains two rows: 08:58,svc-enroll,s-77,success,runner-03 and 08:59,svc-enroll,s-78,denied,unknown. The case intake says “copy received 09:18,” but the supplied screenshot of the export console does not show the export command, object version, original byte count or computed digest. C09 is useful yet incomplete. It corroborates that the exported rows have session/client fields, and it offers a possible C03/C04 connection. It cannot by itself establish that the CSV is a complete, unchanged copy of the underlying IdP source or connect either session to application request q-144.

At 09:22 UTC, support supplies C10, a screenshot whose display clock reads 11:21 UTC+02:00 and shows S42 as “unavailable.” If that fixed offset is correct, the depicted display time is 09:21 UTC. The support ticket records receipt at 09:22 UTC. The capture device, clock-setting evidence, exact URL, account context and whether the front end was cached are missing. Do not replace those gaps with assumptions. The screenshot supports “someone supplied a picture of an unavailable display,” not “the database slot was unavailable at 09:21.” Its visible time is a claimed capture/display time, not the moment the original slot changed.

Lesson table; scroll horizontally to read all columns →

4.3 A two-stage collection receipt

The analyst first writes a request record: CTN-IR-014 / IDP-01, requested by response lead at 09:14, limited to 08:50–09:05 UTC and the fields above, with intended custodian and expiry reason. Once C09 arrives, the analyst writes a receipt, not a fictional completed custody form: approved 09:16 by the case's identity authority; copy received 09:18; source described by custodian as IdP detailed export; two visible rows; original object ID, source query and byte-level integrity not supplied; use restricted to this case. The action item is to ask the custodian for those missing fields or a newly collected, documented copy while the source remains available. Never change the original CSV to “fix” missing columns. A parsed spreadsheet and a narrative timeline are derivatives, with their own filenames and provenance.

For C10, ask support to preserve the original screenshot file and ticket metadata. Record the displayed timezone and the arithmetic conversion as an analysis annotation. If a file is later obtained, compute a digest over that file's bytes, record tool/version and storage location, and compare copies. A cropped or re-encoded image has different bytes; hash equality should not be expected across transformations. The screenshot's content still needs contextual corroboration even when its file integrity is verified.

4.4 A safe byte-integrity lab

The next fixture V4 is not C09. It is a local, artificial 34-byte payload that demonstrates reproducible SHA-256 without claiming an IdP export was verified. Run the snippet only in a local Python 3 interpreter; it reads no network or user data.

import hashlib

payload = b"case=CTN-IR-014\nsource=idp-export\n"
print(len(payload))
print(hashlib.sha256(payload).hexdigest())

Expected output:

34
1407e98f466990ff5aa4eee42cd30291826490e2c910ee57887824e6946136cc

Now change one byte in a copy and rerun: the digest should differ. The conclusion is limited to byte integrity of the classroom payload and copied bytes. It does not validate the truth, completeness, collection method or authority of C09. In a live case, a file's digest belongs in a receipt alongside the source identifier and approved collection path; the digest alone is a poor case record.

4.5 Evidence packages need an explicit negative claim

A second responder must be able to answer: “Which source did we actually receive, and which conclusion must we not draw?” For C09, “two visible rows associate s-77 with client runner-03” is narrower than “the runner made the S42 edit.” For C10, “a supplied screenshot shows unavailable” is narrower than “S42 was unavailable to all learners.” Name negative claims in the package: no verified s-77 to q-144 key, no authoritative state, no validated full-source export, and no attribution of a human. These are limits, not evidence that the opposite is true.

A preservation queue orders requests by decision value and loss risk. C09's detailed source was stated to expire at 10:00, so its bounded metadata gap is time-sensitive. The C10 file and ticket should also be secured, but the visible screenshot does not replace the authoritative state check. A “collect everything” instruction makes privacy, review and provenance harder without answering a specific question. A narrow first collection may need an approved extension if a discriminator requires it; record that new request rather than retroactively widening the first one.

4.6 Use a provenance model that can survive handoff

For each received object, track five layers:

1. Source identity: generating system, dataset, partition or source event ID where provided, plus stated event interval. An object named "export.csv" is not a globally unique source identity.
2. Acquisition authorization: approving role, policy or case reference, allowed scope and time. This is not the same as the copy's contents.
3. Acquisition operation: who performed it, selection query, tool/method, source version, export location and completion time. If unprovided, explicitly mark "not supplied."
4. Received bytes: received object reference, byte count and cryptographic digest only if the actual bytes are available and measured; handling/access records; and a preserved original separate from derivatives.
5. Interpretive claim: what the object supports, what it does not support, and what other source is needed to test a hypothesis.

At C09, layers one and two are partially described; the case does not give a complete layer three or four. A reviewer can say "the case received a CSV copy with these two readable rows," not "the complete IdP source was forensically preserved." That narrower sentence is both accurate and actionable: a custodian can be asked for a richer acquisition receipt or a fresh, authorized bounded copy before the stated expiry.

An access history is not an automatic proof of a lawful chain of custody. Recording who viewed an artifact and when improves reproducibility, but legal admissibility and retention obligations depend on jurisdiction and organizational requirements. This teaching exercise does not certify legal handling. Likewise, a SHA-256 digest identifies bytes under a computation; it does not authenticate the producer unless a trustworthy baseline and collection process link those bytes to the stated source.

Consider a sample manifest entry for C09:

Lesson table; scroll horizontally to read all columns →

C10 requires a separate line: screenshot display time 11:21 +02:00, conditional 09:21 UTC; receipt 09:22; file identity and cache context unverified; supported claim restricted to the depicted UI. An analyst may propose obtaining the original image and support ticket metadata but may not silently record those as present.

4.7 Distinguish integrity, authenticity, completeness and relevance

These four qualities answer different questions.

Byte integrity: "Does this local byte sequence still match the reference digest?" A measured digest can answer this relative to the stated reference. It cannot answer whether the data were valid when produced.

Source authenticity: "Can we substantiate which producer emitted this event and the path through which this copy arrived?" This depends on collection records, producer validation, access control and sometimes signed outputs; a bare digest is insufficient.

Completeness: "Does the selected set cover the specified event interval and field scope?" Completeness may require producer counts, query semantics, paging checks, source-object versions or known-good control events. Two visible rows do not prove there were only two matching source events.

Decision relevance: "Will the record change a response decision?" A perfect byte copy of an irrelevant file may offer little value. C09 is relevant to the session/client question but still does not link s-77 to API request q-144. C10 is relevant to a reported user-facing symptom but does not establish authoritative slot state.

A defensible practitioner notes all four separately. Poor language collapses them: "Hash matched, therefore data genuine and case proven." Better language is "This payload's bytes match the published fixture digest; source provenance, full export scope and causal claims require other tests." When the baseline digest is missing, write "not tested," not "failed" and not "passed."

4.8 Offline byte-integrity exercise with executed output

The following local Python 3 fixture is V4, not C09. It uses the classroom payload from §4.4 and changes one ASCII byte in a working copy. No file, network, identity account or production log is touched.

import hashlib

original = b"case=CTN-IR-014\nsource=idp-export\n"
modified = original.replace(b"idp-export", b"idp-Export")

print("C4|length", len(original), "SHA256", hashlib.sha256(original).hexdigest())
print("C4|mutated_length", len(modified), "SHA256", hashlib.sha256(modified).hexdigest())
print("C4|equal_digests", hashlib.sha256(original).digest() == hashlib.sha256(modified).digest())

Output executed for this exact fixture:

C4|length 34 SHA256 1407e98f466990ff5aa4eee42cd30291826490e2c910ee57887824e6946136cc
C4|mutated_length 34 SHA256 c4ad3cfb2707356a80767e6555ce8c7ff92f7ef549d8f128468de23a1ce13e61
C4|equal_digests False

The change is lowercase "e" to uppercase "E" inside the source label: the byte count remains 34, yet the digest changes. This demonstrates why the number of bytes alone cannot detect alteration and why a digest comparison is specific to exact bytes. It does not prove that SHA-256 gives a truthful source provenance guarantee; cryptographic integrity and source authenticity remain separate properties.

A reproducing student should explicitly label: input is the 34-byte synthetic payload; method is SHA-256 over byte strings; observed output is the two digests and False comparison; inference is that these two byte strings differ; non-inference is that any CTN IdP source was verified. If a student writes the V4 digest into C09's missing object-digest field, the evidence record becomes false. This is a critical grading error despite the correct hash arithmetic.

For an additional negative control, compute the original digest twice without mutation: the values should match. Keep original and modified bytes separate, never "fix" an original artifact in place. If source bytes later become available, the correct workflow is to take an authorized read-only copy and record the actual digest and source identifiers of that object, not substitute the fixture.

4.9 Preserve image context and time semantics

A screenshot can corroborate what a user or tester saw on a display. It generally cannot prove which backend version produced the display unless the system also supplies validated request, response, cache and data records. A screenshot may show cached HTML, a delayed client state, a localization offset or a UI error without demonstrating a database mutation. These alternatives are hypotheses, not counterproof of the reported symptom.

For C10, calculate 11:21 − 02:00 = 09:21 UTC, but retain the condition that the displayed offset is correct. The capture timestamp is not independently established. The 09:22 support receipt is a separate fact about the case workflow. Ask support to preserve the original image bytes rather than a cropped or re-encoded derivative, to retain the ticket text, and—if permitted—to document the device time settings and URL context. Do not request screenshots of real learner records for this classroom exercise.

A peer reviewer should be able to challenge a caption. "Screenshot proves S42 inaccessible at 09:21 UTC" overclaims both time and authoritative state. "Support provided a screenshot at 09:22 that displays S42 as unavailable, with clock reading 11:21 UTC+02:00 (conditional conversion 09:21 UTC), while cache and capture clock remain unverified" is traceable and honest.

4.10 Make a preservation queue based on reversible loss and decision value

At 09:22, C08's stated 10:00 expiry is the concrete time-sensitive issue. A high-value first follow-up is to have the already authorized identity custodian clarify C09's collection source, query/method, object version, byte count and digest if available, and preserve a documented narrow copy before the source window is lost. This addresses whether the detailed IdP data can support subsequent analysis. It does not prove that a complete copy exists now.

A second high-value request is an owner-approved read-only authoritative S42 state and last-change check, minimized to slot status, version/request ID and necessary timestamps. This can discriminate whether the reported display matches current backend state. An application or service custodian should select the safe permitted method; students should not query production directly. The two requests can proceed in parallel when separate custodians are available, but each needs its own approval and receipt.

Preservation priority should not be confused with action severity. Data may expire while the probability of a malicious actor remains low. Nor does an impending deadline authorize sharing protected raw records with any available analyst. The escalation may instead be "request supervisor and data-owner decision now; method unavailable until proper approval," which accurately documents a governance gap.

4.E1 Five objects in an evidence workflow

Incident records are often described as a “chain of custody,” but that phrase is too easily reduced to recording a checksum. The supervised practitioner should separate at least five identifiable objects.

1. Producer record set. The events still held by an application, identity service or storage system, under its actual retention and deletion semantics. A custodian may be able to query a subset without showing that all expected events were generated.
2. Selection and authorization. A case-specific decision naming the permitted producer, account/object selectors, event interval, sensitive fields, collecting role and purpose. An approved plan does not automatically stop source deletion or deliver any bytes.
3. Collection event. An operator actually retrieves defined data, records method, query, source, creation/retrieval time, object identity and destination, and reports omissions or errors.
4. Preserved copy and check. Identified bytes are kept under appropriate restricted access, with a digest computed and compared as defined. Equality supports consistency of the checked bytes under its trust assumptions; it cannot establish truth or completeness of the producer.
5. Analytical derivative. A projected CSV, redacted screenshot, normalized timeline or chart derived from preserved records. It needs source pointers, selection/transformation method and a separate copy identity; it is not the original source simply because it looks clean.

The workflow has different failure conditions. A preservation request may be correctly scoped but never acknowledged. A collector may report success while the export lacks source metadata. A hash may match despite omission of relevant rows in the query. A screenshot may show an accurate image of a cached page but not the authoritative slot state. An analyst who collapses these distinct states into “evidence collected and verified” makes later independent review impossible.

The NIST SP 800-86 guide discusses forensic techniques and source-sensitive acquisition in response, while SP 800-92 addresses log-management concerns. Both publications date from 2006. Their concepts support asking about provenance and records but do not determine CTN's specific legal duties, cloud retention implementation or real collection privileges. The method below is an original teaching contract, not legal evidence-handling advice.

4.E2 What the C09 and C10 cards really establish

At 09:14, C08 reports that detailed identity events in the relevant synthetic window expire at 10:00. The analyst can request a narrow svc-enroll 08:50–09:05 UTC collection from the identity custodian. At 09:16, C09 subsequently supplies a reported approval; at 09:18 it supplies a case-copy receipt describing two events at 08:58/08:59. The material is richer than the earlier summary, but object identity, byte count and digest are not supplied. A conscientious record says: copy received according to case card; source completeness unknown; byte-integrity comparison not possible with the supplied fields. It does not retroactively mark the 09:14 request “received.”

C10 is a different source: a support screenshot displaying “11:21 UTC+02:00,” received at 09:22. Subtracting two hours yields a conditional displayed UTC value of 09:21. The arithmetic does not authenticate the screenshot's capture-device clock, timezone-label correctness, page cache freshness or current authoritative S42 state. Keep the raw display string, claimed offset, conversion, receipt time and confidence in the time source in different columns. If the screenshot shows “unavailable,” that is evidence that an image displayed the symptom under its asserted capture conditions—not that the backend was unavailable at 09:21.

The original V4 byte string is a separate laboratory artifact, with its published 34-byte length and SHA-256. It cannot be repurposed as C09's missing digest. A training participant may compute the correct V4 checksum and still have absolutely no basis for saying the C09 export was complete or unmodified. The byte layer and source-provenance layer are different evidence classes.

4.E3 A source-hold request cannot be substituted for a retained case copy

Suppose the identity custodian can preserve records at their original source but cannot yet release a selected export. That may reduce immediate loss risk, but the investigator still lacks a case copy and cannot report an integrity check. Conversely, a one-time copy may be retained while the producer continues deleting source rows under its ordinary policy. The case therefore needs two separate ledgers: source-preservation control and collected-item custody. Do not infer the first from the second.

A hold ledger should name the exact source namespace and objects/interval, approved decision, reported mechanism, effective/expiry or review terms, application receipt, non-destructive effect observation, and current residual limitations. A copy ledger should name the item/source, collection authority, actual time, selector, transfer, byte count, digest/check, restricted destination and handling history. A positive digest is not a hold-effect receipt. If a source never supported a hold, state that limitation and seek an authorized alternative rather than inventing a feature.

The strongest next request concerning C09 is therefore narrow, not “send all IdP records”: obtain the particular source object identifier, query envelope including interval semantics, collector details, byte-count/digest record if they exist and any source-health limitation. If an item is unavailable, document the unanswered field. C08's 10:00 source-expiry claim changes scheduling urgency; it does not authorize the analyst to bypass restricted access.

4.E4 Construct a reviewable collection manifest

For a supervised, authorized collection, an independent reviewer should be able to reconstruct the following chain:

Lesson table; scroll horizontally to read all columns →

A manifest with missing fields is not automatically dishonest; it is incomplete for the claims those fields would support. That is a useful result. The custodian may supplement it later, maintaining original timestamps and versions. The learner should never backfill today's digest into a historical receipt as if it were recorded at the time.

4.E5 Controlled contrast: byte integrity, source authenticity and data meaning

Take three hypothetical submissions. In A, a known local file has two matching SHA-256 checks but no originating source or approved selection: byte consistency is supported, source authenticity and completeness remain unknown. In B, a log export has a detailed query manifest and custodian signature, but its stored bytes no longer match the recorded digest: do not rely on the disputed copy until the discrepancy is investigated, even though the query metadata are plausible. In C, both copy identity and bytes are checked, but the application field labelled actor contains a shared automation account: producer provenance may be stronger, yet human attribution remains unproved.

These are different axes. There is no “overall evidence verified” state that follows from any one positive check. A reviewer should score each axis and name the next bounded question: source health/completeness, exact bytes and transfer, or identifier semantics. Neither a screenshot nor a copied text transcription can answer all three.

4.E6 Offline laboratory C4X — detect which preservation receipt is missing

Environment: Python 3 standard library, entirely in memory. The following tuples are invented receipt-state illustrations and not C09/C10 replacements. No source export or hashing occurs. The model deliberately refuses a claim of checked bytes when approval or a received item is absent.

from datetime import datetime, timedelta

def status(card):
    if not card["approved"]:
        return "REQUEST_ONLY"
    if card["received_at"] is None:
        return "APPROVED_NOT_RECEIVED"
    if card["object_id"] is None or card["digest"] is None:
        return "COPY_RECEIVED_INTEGRITY_UNVERIFIED"
    if card["checked"] is not True:
        return "DIGEST_RECORDED_NOT_CHECKED"
    return "COPY_BYTES_CHECKED_SOURCE_COMPLETENESS_UNKNOWN"

cases = [
    ("REQUEST", False, None, None, None, None),
    ("APPROVAL", True, None, None, None, None),
    ("CTN_C09_LIMIT", True, "09:18", None, None, None),
    ("UNRECHECKED", True, "09:18", "toy-1", "sha256:toy", False),
    ("CHECKED_FIXTURE", True, "09:18", "toy-1", "sha256:toy", True),
]
for name, approved, received_at, object_id, digest, checked in cases:
    print(name, status(dict(approved=approved, received_at=received_at,
                            object_id=object_id, digest=digest, checked=checked)))
raw = datetime(2026, 10, 12, 11, 21)
print("C10_UTC_CONDITIONAL", (raw - timedelta(hours=2)).strftime("%H:%M"))

Executed output:

REQUEST REQUEST_ONLY
APPROVAL APPROVED_NOT_RECEIVED
CTN_C09_LIMIT COPY_RECEIVED_INTEGRITY_UNVERIFIED
UNRECHECKED DIGEST_RECORDED_NOT_CHECKED
CHECKED_FIXTURE COPY_BYTES_CHECKED_SOURCE_COMPLETENESS_UNKNOWN
C10_UTC_CONDITIONAL 09:21

The fifth scenario uses invented sha256:toy text, not an actual digest or verified byte sequence. Its flag tests only how to label a declaration; it does not authenticate a sample. Adversarial control: set checked=True while removing the digest; the result remains COPY_RECEIVED_INTEGRITY_UNVERIFIED. Set approved=False on a purported received copy; the first gate says REQUEST_ONLY, demonstrating that the tuple is inconsistent rather than evidence of valid authority. An actual receipt system should flag contradictory states explicitly instead of treating this toy gate as comprehensive.

Required learner artifacts: Six output lines; one missing-evidence table for C09 and C10; a source-versus-copy ledger; a least-privilege two-request preservation queue; one sentence explaining why the C10 normalized time is conditional. Rubric, six local points: exact transcript (two), proper C09 status and V4 separation (one), C10 clock/cache limit (one), bounded custodian/approval/provenance requests (one), and safe negative-control explanation (one). No real contact or collection is part of the exercise.

4.E7 Build the Chapter 5 handoff from retained gaps

A professional handoff should identify what is missing in a way that changes the next investigation. For C09, unresolved source-object ID and digest affect confidence in the retained export's provenance and integrity. For C10, unknown capture clock/cache affect conclusions about the apparent time and service state. The C03/C09 session field might suggest an identity relationship; C05's blank application session still prevents a direct link from s-77 to q-144. These are three different gaps with three different custodians/tests. A single sentence “more evidence needed” does not instruct the next analyst.

Do not discard the raw C10 display once it has been normalized; retain both times and the conversion method. Do not modify C09 to add a byte count not supplied. When the Chapter 5 investigation starts, source pointers should survive exactly as recorded, while competing hypotheses and derived timelines may change with each new card.

Chapter synthesis: The evidence workflow is not completed by approval, file existence or a hash alone. C09 supplies a reported received copy but lacks key provenance/integrity fields; C10 is a limited screenshot observation. Both are useful if their uncertainties remain visible. Chapter 5 will compare their clues against other source records without converting a missing session join into proof.

Common mistakes and limits

• Calling a checksum a signature or proof of authenticity. A digest detects changed bytes only when a trustworthy baseline and object identity exist.
• Writing “UTC 11:21” for a display labelled UTC+02:00. Subtract two hours, and keep the source clock's verification status.
• Treating a screenshot as an authoritative database state or a CSV summary as a complete export. Preserve both and request the source-specific discriminator.
• Backfilling missing C09 collection fields with guesses. A gap is itself a finding about evidence quality.
• Changing an original file to make analysis easier. Work from a documented copy and keep transformation steps reproducible.

Practice: peer evidence review

One learner prepares a C09/C10 package with a request, receipt, limitation note and proposed follow-up. A second learner, given only that package, must reconstruct what was actually available at 09:22 and ask a question that would discriminate display-only failure from a changed slot. The first learner scores the answer against the source and time fields, then revises the package. No real logs, accounts or screenshots are necessary; the classroom cards are sufficient.

Exercises — subject 4

EX016 — Bounded collection request. Input: C08 at 09:14, C03 and C05. Write the IdP source, 08:50–09:05 UTC range, selectors, minimum fields, purpose, custodian, approval gate and requested result. A 2-point result does not demand a tenant-wide export or claim execution.

EX017 — Two receipts. Input: C09 and C10. Create separate receipt lines with source, event/display time, receipt time, approval where known, object integrity state and one explicit limitation each. A 2-point result distinguishes C09's missing digest from a verified hash of V4.

EX018 — Hash verification. Input: the V4 bytes and published SHA-256 above. Run the local snippet or independently recompute the digest, state the 34-byte count and digest, then explain one thing it establishes and two things it does not. A 2-point result gives the exact digest and refuses to authenticate C09 from V4. Also change one ASCII byte in a copy as in §4.8; explain why equal byte counts do not establish identical bytes.

EX019 — Timezone annotation. Input: C10. Calculate the apparent UTC display time, record the 09:22 receipt separately and write a caveat about the unverified capture clock and cached page. A 2-point result gives 09:21 UTC as conditional.

EX020 — Preservation queue. Input: C08–C10 and the S42 question. Rank two authorized follow-ups by imminent loss and decision value; identify owner, bounded scope and expected discriminator. A 2-point result asks for C09 collection metadata before expiry and an authoritative S42 state comparison without declaring either result received.

Subject synthesis

C09 and C10 add detail, but the case remains open: an export has an incomplete provenance record and a screenshot is not the service's source of truth. Chapter 5 will use these bounded observations to build a timeline and test multiple explanations. The analyst must carry the missing fields into the hypothesis table rather than fill them with a story.