research: learn from typed request and outcome signals without online recipe mutation

Summary

Evaluate whether typed request-time features plus trusted post-response outcomes improve Router Learning model choice. Keep online adaptation inside the current candidate/protection boundary; broader signal, threshold, or recipe changes remain offline proposals.

Audited current-main baseline (2026-07-15)

• Request-side routing already evaluates typed signals and selects a base logical model.
• Router Replay can record route diagnostics, usage/cost, tool traces, and typed outcomes.
• POST /v1/router/outcomes updates model-targeted Router Learning experience when an active runtime and matching replay record are available.
• The public Router Learning contract is global.router.learning with adaptation.strategy: routing_sampling, protection, and per-decision adaptations.
• Current main does not expose the old method-keyed bandit/Elo/session API, and online learning is not allowed to rewrite embedding thresholds, keyword weights, decisions, or recipe priority.

Research hypothesis

A versioned, content-minimized feature projection may improve model choice when request characteristics correlate with model outcomes. This is a hypothesis to benchmark against routing_sampling and static selection, not an assumed production benefit.

Scope

1. Define a typed feature schema using reviewed request signals, candidate set, decision/tier, bounded session aggregates, and feature provenance.
2. Define trusted outcome labels and distinguish task quality, provider failure, latency/cost, user feedback, and missing/censored outcomes.
3. Materialize training/evaluation rows asynchronously from Router Replay; do not read durable storage synchronously on the request path.
4. Establish static and routing_sampling baselines before evaluating contextual strategies such as those tracked in #2308.
5. Calibrate reward/objective definitions per evaluation; do not hard-code unvalidated universal weights.
6. If a strategy graduates, register it through the existing adaptation.strategy seam and keep selection inside the configured candidate set and protection envelope.
7. Route signal/threshold/decision changes through the offline proposal, evaluation, approval, activation, and rollback work in #2340/#2366/#2367/#2393.

Boundaries

• HTTP success, silence, or “no complaint” is not sufficient evidence of answer quality.
• Raw prompts or full response bodies are not required in the derived learning projection by default; existing Router Replay content retention is configured separately.
• Identity, authorization, safety, residency, context compatibility, and explicit decision bypass remain hard constraints.
• No hidden hot reload or request-time mutation of recipe structure.

Acceptance criteria

• Feature and outcome schemas are typed, versioned, privacy-reviewed, and leakage-tested.
• Missing, delayed, duplicated, and adversarial feedback semantics are covered.
• Static and routing_sampling baselines accompany uncertainty and coverage reports.
• A proposed online strategy stays inside candidate/protection boundaries and emits deterministic diagnostics.
• Broader recipe changes are emitted only as reviewable offline artifacts.
• Hot-path latency, allocation, and state bounds are measured.

Related

#2238, #2308, #2340, #2346, #2393.

Validation entrypoint

make agent-report ENV=cpu CHANGED_FILES="<space-separated changed files>"

Use the reported Router Learning, replay, config, benchmark, and E2E gates.