Lens: scale targets prefer authored diversity, route reachability, and dashboard proof over raw volume

Design intent

This lens revises the old scale-targets check. Storyteller scale must not be judged by a hard demand for 2000+ rites and 1000+ cards. That kind of numeric oracle rewards filler and conflicts with the worker rule against bulk content batches.

Scale now means that the game has enough authored variety to act like a management + RPG narrative engine: players can reach routes, assign cards, see state changes, and read dashboard proof for why the source passes.

Scope

This lens observes the Storyteller source as a whole, not one isolated rite.

Affected systems:

  • authored cards, characters, rites, events, storylines, questlines, counters, endings, and lenses under wiki/content/;
  • public manifests under public/data/storyteller*;
  • the local lens evaluator and dashboard report;
  • game CLI replay/session evidence within a bounded horizon.

Affected current playable proof:

Oracle assertions

No raw-volume failure

The evaluator must not fail solely because Storyteller has fewer than 2000 rites or fewer than 1000 cards. Those numbers may remain as long-term aspirations, not a pass/fail gate.

Authored diversity floor

The manifest must prove at least six distinct authored play-relevant content families. No single family may provide more than 55% of the counted authored pages.

Required families: route container (storyline or questline), playable rite, assignable card or character, visible counter or state key, ending/failure/miss/branch outcome, and executable lens.

Route reachability floor

Within a 30 turn horizon, CLI/session evidence must show at least three distinct route families reachable from normal play or from the active turn fixture:

  • security or baseline-combat management;
  • archive, continuity, memorial, or custody;
  • character-facing encounter, recruit, miss, trust, refusal, or conversion.

A route counts only when evidence includes offered choices, assigned cards or operators, and visible state, card, tag, or counter outcomes.

Non-filler quality gate

A counted page must include at least one playable anchor: named affected content, explicit slots or prerequisites, costs or risks, failure states, replay evidence shape, executable oracle language, or Obsidian links to what it observes and how it is observed.

Title stubs, duplicated reskins, pure mood paragraphs, and unbound numeric padding are excluded from the score.

Dashboard proof

The public dashboard or lens report must expose enough data to explain the result without private worker logs: type histogram, reachable route families, replay/session id, quality exclusions or zero-exclusion statement, and this lens id.

Regression guard

If new pages increase raw counts while route reachability, current-hand playability, or dashboard evidence disappear, this lens must fail.

Progress metric

scale_targets_revision_score = weighted_passed_assertions / 100.

Suggested weights:

  • 20: raw-volume gate removed or demoted to aspiration;
  • 20: authored diversity floor passes;
  • 25: three route families are reachable within 30 turns;
  • 15: counted pages pass the non-filler quality gate;
  • 15: dashboard/lens report exposes proof fields;
  • 5: regression guard fails correctly when reachability or evidence disappears.

Passing threshold: 85/100, with no hard failure in route reachability or dashboard proof.

Game CLI replay/session evidence shape

Evidence should include: lensId, source id, seed, start turn, turn horizon, content type histogram, quality exclusions, reachable route families, offered choices, assigned cards, visible outcomes, dashboard manifest path, lens report path, score, pass flag, and hard failure list.

The implementation should fill counts from the current manifest. Placeholder zero counts are not passing values.

Replacement note

The old scale-targets evaluator check should bind to this page or adopt equivalent assertions. It should stop measuring scale as bulk authoring and instead measure authored diversity, route reachability, replay visibility, and dashboard proof.