radar-self-evallisted

# Self-evaluation The radar must measure whether it is winning, not assume it. Three parts: metrics (every week), retrospective (monthly), curator proposals (every week). ## 1. Weekly metrics Compute from the week's daily reports (primary source — they list ledger changes) and, where needed, `git log -p -- TRENDS.md` since the previous weekly commit: - **queue funnel**: items added / promoted to trend / dropped / older than 14 days and still unverified (stale) - **ledger**: evidence items added, stage moves (up and down) - **exploration compliance**: daily runs whose `source_rotation` line contains a venue-exploration entry ÷ daily runs executed - **off-axis rate**: share of new queue items that do NOT match any axis in `strategy_notes` (judgment call — name them) - **discovery lag**: for each evidence item added this week, the days between its evidence-line date and the date it entered the ledger (commit date via `git log -p -- TRENDS.md`, or the daily reports). Report the median, split by channel — exploration finds vs queue promotions (backfill) — plus the backfill share of all new evidence. This is the daily-ness KPI. Append ONE dated line to `## calibration` in TRENDS.md: `- YYYY-MM-DD — W<nn>: queue +a/→p/−d/stale s · evidence +e · moves m · exploration c/r · off-axis o/a · lag expl Xd / backfill Yd (Z%)` and include the same numbers, readable, in the weekly report. Interpretation thresholds (act, don't just log): - exploration compliance < 100% → ca