Verification model

Countegrity never trusts the checkpoint from memory: every count, catch-up and audit pass re-derives state from the channel log, so drift and offline tampering surface instead of silently persisting.

Live check

Every new message is validated on arrival against the checkpoint; anything that breaks the sequence is deleted with a short notice naming the author. Cleanup keeps running for every other violation, and auto-enforcement never deletes a message whose count stays recorded: a violating new message is never in the ledger, an edited tip is rolled out of it first, and every other recorded count is removed only by the admin-confirmed repair below.

Catch-up

A bounded replay of the recent log runs after every new addition, so a message counted before the checkpoint is never trusted blindly. The audit also drains the tail, so a channel that fell behind while the bot was down catches up even if nobody counts again for a while.

Audit

The whole log is re-derived in bounded sections on a rolling daily rotation, so a count deleted or edited while the bot was offline surfaces no matter how long the channel is. The log is split into fixed chunks of a few thousand counts and swept newest-first; each chunk replays against the recorded ledger prefix and the result is compared with the checkpoint.

Any downtime — a gateway gap or a restart — marks every chunk stale, so the whole log is re-derived again as the sweep reaches it. Between reconnects, chunks verified after the last gap are skipped to stay inside Discord's rate limits, and a skip never renews a chunk's freshness stamp, so every chunk is re-derived again within a day either way; channels longer than the per-day read budget simply finish their rotation over the following days, older sections last. Per channel, the audit keeps its last full-rotation timestamp, its walk position and per-section freshness timestamps (see Data and privacy).

Clean channel

Rejection notices delete themselves after 30 seconds. Any other bot message — a command reply, or a notice replaced before its timer ran — is swept by the next catch-up or audit pass instead, so over time the channel holds only the clean count sequence.

Repair

A deleted count below the newest accepted count is a permanent hole. The cog posts a notice with a Confirm repair button; an admin (checked on the click) confirms, and everything after the last intact count is deleted so the sequence resumes there. The notice is not pinned: while it is pending every other message is blocked, so the count is frozen at the hole until an admin resolves it.

Deleting the newest count instead leaves no hole: the ledger below it is still provable, so Countegrity drops it and rolls the count back, letting the same number be counted again with no recovery involved.

Edits

Editing a count message below the newest count breaks the sequence the same way, but reversibly. The repair notice names the author and clears itself the moment the message reads as its count again; nothing is deleted along the way, and the Confirm repair button stays as the admin fallback. If the author deletes the message instead, it becomes a deleted count and the repair flow above takes over.

Editing the newest count is auto-enforced instead: the broken message is deleted and the count rolls back, with a short notice naming the editor (like any other automatic enforcement), and the number can simply be counted again.