The log is append-only and written as actions happen, rather than assembled on request. That distinction matters: a report generated after the fact can only describe current state, while a log written at the time captures the sequence, including things that were later undone.
What is recorded. Application launch. Every apply attempt, whether it succeeded, partly succeeded, or failed, with counts of what was changed and what Windows refused. Snapshot creation and restore, including whether a restore was complete, partial, or blocked pending approval. Undo and redo, both directions. Setting changes, with the specific setting that changed. The result is that the log covers the actions you took and the outcomes you got, not a filtered view of successes.
What is deliberately not recorded. Entry details are summarised as counts and outcomes rather than written out as full personal paths. Details that do get written pass through a scrubbing step before being stored. This is a real trade-off and worth naming: it means the log tells you that eleven entries were removed in a given apply and how many were refused, rather than reproducing eleven full filesystem paths. For accountability that is the right balance — you can establish what happened and when, and the log does not itself become a file full of personal information sitting on disk. For recovering a specific entry, the undo history and snapshots are the right tools, and they are precise about individual entries.
Where it lives and how it grows. The log is a local file. It makes no network requests, is never transmitted, and has no cloud component — consistent with the app requesting no networking permission from Windows at all. It rotates when it reaches a size threshold, keeping a number of archives, so it neither grows without limit nor discards history the moment it fills. Notably, "clearing" the log rotates it to an archive rather than destroying it, which means a clear action does not erase the record it was clearing.
Diagnostics export. When you need to give the information to someone else, an export produces a report on demand containing application and version details, host OS and architecture, the relevant paths, registry summary counts, and the log integrity status. Personal folder names are replaced before export. It is generated when you ask and not otherwise.
The log is also verifiable rather than merely present — each entry is hash-chained to the one before it, which is a separate topic covered on its own page.
