# Fastmod Audit and Backfill Step 1 Solution Assessment

## Problem

Operators need to measure unscored historical content and its estimated Fastmod
cost before deliberately deciding whether to backfill it.

## Option A — Separate audit and backfill commands

- Add a read-only audit command that reports historical candidate counts,
  existing states, and a cost range based on the configured model and observed
  Fastmod usage.
- Add a separate, explicitly confirmed, bounded backfill command.
- Pros: clear no-write preview; deliberate policy reversal; supports spend and
  volume limits.
- Cons: two commands and associated operator documentation.

## Option B — Extend the existing status and enqueue commands

- Add historical auditing to status and an opt-in historical mode to the
  existing enqueue command.
- Pros: fewer commands; familiar workflow.
- Cons: blurs normal new-content processing with an exceptional corpus-wide
  action; makes accidental backfill easier.

## Option C — Document manual SQLite queries and one-off queue writes

- Keep the product unchanged and provide operator instructions only.
- Pros: no feature work.
- Cons: error-prone; no standardized estimate, guardrails, or audit trail.

## Recommendation

Choose **Option A**. A read-only audit followed by a separately confirmed,
bounded backfill preserves the current new-content-only default while making a
historical run measurable, intentional, and recoverable.

## Next

If this assessment is accepted, reply **Approved Step 1**. I will then create
the Step 2 feature description.