Our extension prototype uses revision tags to store the result of a revision check so that we can tell at a glance if a revision is still in place because it passed the check or because a successful check has not yet occurred. This is not desirable in production because of scaling (we would be tagging nearly every non-revert revision on an enabled project) and the user experience (we would be adding tag noise with what is effectively diagnostic information). We need to determine the method for keeping track of this information to allow us to recheck revisions in which an error occurred and to allow a future job-based implementation to check scores from a queue (the prototype currently uses a simple hook implementation).

Findings
We'll need to use a database table to track our activities based off of recent changes. We would need to store rc change id/rev id, status (checked,retry count, merge failure, score, etc) We will need to prune this data, which isn't an option for logs. ORES uses a maintenance script to prune its tables, though there are weak guarantees around that. Recent changes prunes itself on save by firing a pruning job in ~1/10 save calls. We should use that same method to prune our tracking table. We can drop rows with change id's lower than the lowest change in the rc table. We can additionally use Logs to track failures in a publicly visible way that persists.