review-graph: reevaluate future Jev revisions before reconsidering adoption #75

Objective

Retain a dormant, opt-in experiment for evaluating a future pinned Jev revision before reconsidering TypeSafe routing adoption. #73 concluded that the tested model and policy did not justify adoption; #74 is closed as not planned. This issue replaces the original maintenance proposal for an adopted provider with a bounded future reevaluation.

When to revisit

Begin only when a concrete candidate model or question revision gives a reason to expect improved applicability judgments. Preserve the completed reports and original records. Routine reviews and ordinary offline CI remain independent of service availability; this issue does not schedule monitoring or authorize live calls.

Scope

• Retain the explicit opt-in shadow harness, recorded responses, replay, request accounting, and bounded credential launcher independently of the upstream TypeSafe agent skill.
• Select a pinned candidate model and freeze question definitions, thresholds, request/token/retry/cost limits, and a comparative success rule before observing evaluation results.
• Treat the completed review-graph: evaluate TypeSafe/Jev routing in shadow mode before integration #73 cases as development and historical regression data. Obtain fresh source scopes and independently reviewed applicability labels for a new held-out evaluation; retain ambiguous ownership as unresolved rather than rewriting labels after seeing predictions.
• Freeze ordinary coordinator decisions before candidate inference. Compare both methods on the same captured source and catalog, and disclose any differences in instruction context.
• Report missed applicable concerns, unnecessary selections, unresolved judgments, risk categories, fallback behavior, adapter latency, exposed token usage, and estimated or measured incremental cost. Leave unavailable coordinator and downstream costs unknown.
• Preserve exact source, catalog, model, questions, policy, responses, and replay bindings. Failed, incomplete, or stale results remain unknown, and all ordinary routing and proof requirements remain authoritative.
• Record a go/no-go outcome. A favorable routing result may justify a separately scoped adoption proposal; changing dispatched work still requires a controlled downstream review comparison before rollout.

Acceptance criteria

• Identify the candidate and freeze the evaluation policy and success rule prospectively.
• Retain fresh held-out cases, independent labels and their provenance, and blinded ordinary coordinator decisions.
• Produce a reproducible baseline/candidate comparison with misses, unnecessary selections, unresolved judgments, and explicit measurement limits. Additional missed applicability or unresolved required coverage blocks a positive adoption recommendation regardless of adapter cost or speed gains.
• Replay recorded responses without credentials or live calls, and reject stale or incompatible bindings.
• Preserve required graph coverage and evidence acceptance on every experiment failure path.
• Document the decision, limitations, and exact implementation/model revisions needed to reproduce it.

The existing routing result does not establish TypeSafe's performance at semantic evidence acceptance. Any evidence-checking experiment needs its own task definition and evaluation of false acceptance before it can influence review decisions.