Technical
Citation resolution.
Every supporting-evidence citation in a Loupe brief resolves to one of three explicit kinds. The popover labels which kind so reviewers always know what they are reading. This page documents the resolution priority, when each kind fires, and what survives a case close-and-reopen.
Tier 1
Captured raw bytes
capturedSnippet
Bytes captured from the source file at brief-build time and stored inside the encrypted case. The default for every new brief. Identical bytes travel with the case across close/reopen, so reviewers see the same evidence months later — even on a workstation that never held the original log.
- When it fires
- Used whenever the narrator runs against a case that has its source file(s) attached. ≈99% of the time on a fresh investigation.
- Survives close+reopen?
- Yes — bytes travel with the case file.
Tier 2
Live raw bytes
liveBytes
Bytes read fresh from the source file in this session. Used as a verification path: when both the captured snippet and the live file agree, the citation popover surfaces a green-check badge so the reviewer knows the bytes still match what was captured at brief time.
- When it fires
- Triggered on demand when the source file is still attached and the byte range is still valid. A quiet reassurance that nothing has drifted.
- Survives close+reopen?
- No — requires the source file to still be attached.
Tier 3
Parser-normalized source
parsedMessage
The parser's normalized line. Used as a fallback when raw bytes are not available: legacy cases predating snippet capture, sources detached after the brief was generated, malformed citations, or binary-source events (pcap) where byte ranges into binary aren't human-readable. The popover badge explicitly says "source bytes not retained" so reviewers cannot mistake this for a raw-byte citation.
- When it fires
- Always used for pcap citations (binary; chain-of-custody preserved by the original file's SHA-256 instead). Otherwise: a deliberate, labelled fallback.
- Survives close+reopen?
- Yes for the parsed message; raw bytes not retained.
Why three tiers and not just one
A forensic tool cannot promise raw bytes for every citation without lying. Pcap captures are binary — byte ranges into a pcap aren't human-readable. Cases get reopened on workstations that no longer have the source files. Files get rotated, truncated, or moved between when a citation was captured and when an auditor reads the report.
The honest design is to capture bytes when possible, surface them at audit time, and clearly label the rare cases when only the parser's normalized line is available. The popover badge does the labelling so reviewers never have to guess.
Chain-of-custody is preserved across all three tiers by the original file's SHA-256 hash, recorded in the case'sFILEStable at attach time and shipped in the export bundle. Whether you see captured bytes, live bytes, or a parsed-message fallback, the file the bytes came from is provably the file you ingested.
What this looks like in the UI
Every supporting-evidence chip in the brief opens a popover with three things: the file display name + SHA-256 prefix + byte offset and length, a kind badge identifying which of the three tiers produced this citation, and the bytes themselves. If the badge says source bytes not retained, you are reading the parser's rendering, not raw bytes — investigate accordingly.
Reproducibility
The resolution logic is in CitationResolver.swift. Tests at Tests/LoupeTests/AdversarialCitationTests.swift,BinarySourceCitationTests.swift, and CitationHallucinationTests.swift assert each tier's fallback contract — including that tier-3 citations always carry the kind label and never silently present parsed messages as raw bytes.