Accuracy and limits

The suite is 809 passing and 18 skipped, with mypy --strict and ruff clean on Python 3.11 and newer. The skips need a real NTFS environment, a live Windows volume with admin or the Linux ntfsprogs toolchain, and are skipped automatically where that is absent.

The headline 0.000 is the confirmed false-positive rate measured over a controlled-corpus of 42 benign real-Windows images, 21 dirty-shutdown and 21 partial-rollover volumes. No timestamping tool was ever run on them, so any confirmed verdict would be a false positive. Zero confirmed verdicts occurred across all 42 images.

It is also the confirmed rate, not zero flags. 3 of the 21 dirty-shutdown images raised a single provisional-tier signal on MFT record 24, where a hard power-off left a torn write that the reverse replay correctly disagreed with. All three carry evil confirmed false and the demo key class. The guarantee is never-false-confirm, not never-any-flag.

The per-family false-positive rate is a structural zero: every shipped family has an empty pattern_hex, so the empty-pattern guard precludes any byte match. It is zero because no pattern exists to match, not because the fingerprints are perfectly precise.

The $LogFile and $UsnJrnl rollover blind window, roughly 4 to 12 hours on active volumes, is the primary coverage limit. Events older than the live journal window yield INCONCLUSIVE, not clean. logflip can only reconstruct events still inside the live journal; anything older is beyond its reach by construction.

SetMACE writes raw sectors after dismounting the volume, bypassing the NTFS log entirely. It emits no $LogFile transactions and no new $UsnJrnl flags for the target record, and it overwrites both the $SI and $FN timestamps with the same value, deliberately erasing the SI-vs-FN delta the pipeline relies on. On a real image a SetMACE-stomped file is indistinct from a legitimately old file unless out-of-band context is observed.

So logflip detects journal-leaving stomps that preserve a delta, such as the PowerShell SI-only stomp in the canonical run. It does not detect, and cannot attribute, a log-bypassing dismount raw-write. That is a documented limit, not a gap to paper over.

The tool operates exclusively on NTFS $LogFile, $MFT, and $UsnJrnl structures. No other filesystem is in scope, and the reverse-replay engine only does work when $LogFile is populated, which is the case on real Windows captures.