Sorry, I've been in and out during the holidays, but thanks for the question!
So, you're right that when an entry is released by the state machine in Copycat it simply sets a bit in an in-memory bitmap and uses that map for compaction. So, the usage of the bitmap really relies upon the mechanisms of the Raft algorithm. Right now, Copycat only supports in memory state machines, meaning entries are replayed when a server crashes and restarts to rebuild the system's state. Assuming state machines are deterministic, this means entries will be replayed, and entries that no longer contribute to the state machine will simply be released again, thus rebuilding the compaction bitmap as the state machine's state is rebuilt. Nothing about the compaction process is ever stored on disk. It relies entirely on the replay of commands to a deterministic state machine to recover state as is done in the state machine itself.
Obviously, this could cause problems if compaction is not done correctly, particularly as it relates to tombstones. If e.g. in the proverbial map state machine, a remove command is applied which deletes the state of a key, if that remove command is removed from disk before all prior entries for that key, that could result in the key effectively re-appearing when the server crashes and restarts. Copycat accounts for this by only periodically compacting tombstones from the log using a full sequential scan and rewrite of the log to ensure the tombstone and all prior released entries are removed at the same time. This process is described in further detail in the Log Compaction section of the documentation on the website: