Verification & Reports

Creation is not verification

Lazarus closes the image and reopens it from scratch. Verification requires FINALIZED, rejects INCOMPLETE, parses metadata and the complete chunk map, bounds-checks stored ranges, verifies every stored hash, reconstructs compressed and zero chunks, and verifies every logical source hash.

The logical stream is then used to reconstruct partition information, validate primary and backup GPT structures and CRC values, reopen supported filesystem boot sectors, and read the first NTFS master file table record where possible.

Two different questions

• Image integrity: did Lazarus preserve and reconstruct the captured byte stream correctly?
• Source health: were the structures and data on the original device already damaged?
• A verified raw image may contain faithfully preserved corruption
• A structurally healthy filesystem does not prove every customer file is intact
• The report must preserve these distinctions instead of collapsing them into one green checkmark

Completion or escalation

Successful preset verification can produce a completion report. If the raw stream verifies but the source layout is corrupt, a filesystem cannot be reopened, or unreadable ranges exist, Lazarus produces an escalation report instead.

Escalation does not erase the value of the image. It tells the technician to preserve the artifact and hand the case to data recovery or forensics without attempting repair against the source.

Reports serve the next technician

Reports include job identity, source identity, imaging mode, bytes read and stored, retry and unreadable-range facts, verification stages, structural findings, and the final evidence-based result. Restore produces a separate report.

Support bundles contain diagnostics, hashes, hardware facts, profiles, and logs while excluding customer file contents. The record should help someone else understand the case without relying on memory or folklore.

Why the order of a check matters as much as the check

GPT CRC validation and NTFS master file table parsing are specific to disk images. The sequencing decision underneath ClassifyVerification, checking the byte stream before anything else can soften that result, is a far more general principle about building any function that turns raw evidence into a claim.

The same discipline shows up in test suites that must fail loudly on the first broken assertion rather than let a later passing test mask it, in monitoring that distinguishes a service responding from a service responding correctly, and in any audit process where checking your own output the same way an outsider would is the only check that counts.

• Never let a later, better-looking signal override an earlier failure. ClassifyVerification checks StoredHashesOk and LogicalHashesOk first and returns IMAGE FAILED immediately; a healthy-looking partition table found afterward is never allowed to overrule that.
• Keep genuinely different questions genuinely separate in the result. The page insists image integrity and source health are not interchangeable, because a verified image can faithfully contain corruption, and a healthy filesystem does not prove every file inside it is intact.
• Reopen and recheck from the artifact itself, not from the process that produced it. Verification closes the image and starts over from FINALIZED, parsing metadata and rehashing everything fresh, instead of trusting the state the imaging job ended in.
• Design the failure path to be as useful as the success path. An escalation report exists specifically so a failed verification still hands the next technician something actionable, instead of a bare error.