recipes: tune out-of-box presets for balance, cost, accuracy, speed, privacy, and grounding

Summary

Tune and maintain a small set of out-of-the-box routing recipes that users can copy, run, evaluate, and adapt with minimal custom work:

• balance
• cost-first
• accuracy-first
• speed-first
• privacy-first
• grounding-first

Parent roadmap: #2287 Related: #2331, #2334, #2341, #2333, #2358, #2376, #2338, #2339 Related code and assets: deploy/recipes, deploy/recipes/README.md, config, src/semantic-router/pkg/dsl, src/semantic-router/pkg/config, src/semantic-router/pkg/selection, src/semantic-router/pkg/looper, src/vllm-sr/cli/commands/eval.py, website/docs, dashboard/backend/handlers/presets.go

Motivation

The router has powerful routing primitives, but new users need clear, maintained presets that express common product choices without having to design a full recipe from scratch.

The repo already has maintained recipes such as deploy/recipes/balance.yaml and deploy/recipes/privacy/privacy-router.yaml. H2 should turn this into a coherent preset suite with tuned behavior, probe coverage, and documentation. These presets should be good enough to demonstrate the router's value immediately and structured enough for production teams to customize.

Recipe goals

• balance: default general-purpose recipe that trades off capability, cost, latency, and safety. This should remain the recommended starting point.
• cost-first: prefer cheap/local/small models unless confidence, safety, or task complexity justifies escalation.
• accuracy-first: prefer stronger models, verification, reranking, or multi-model strategies when correctness matters more than cost/latency.
• speed-first: prefer low-latency/local/small models and short decision paths, with explicit escalation only for hard or unsafe tasks.
• privacy-first: keep sensitive, proprietary, PII, or local-only requests on private/local backends, with clear fail-closed/fail-open choices.
• grounding-first: prefer RAG/KB/grounded-generation paths, hallucination protection, grounding-aware Fusion/Looper settings, and citation/evidence-oriented routing.

Scope

For each preset:

• provide a maintained recipe YAML and, where useful, a DSL authoring source;
• define expected virtual model names / entrypoints once multi-recipe support lands;
• define the provider/model capability assumptions needed by the preset;
• include eval probes that exercise positive, negative, and boundary cases;
• include expected routing behavior and acceptance thresholds;
• document how to run the recipe locally and how to adapt model bindings;
• ensure dashboard preset metadata can show the recipe purpose, tradeoff, and required capabilities;
• keep shared/global assets separate from recipe-owned routing policy.

Non-goals

• Do not make every preset depend on live gated model credentials.
• Do not hide missing runtime features in documentation-only examples.
• Do not add provider-specific secrets or private deployment assumptions to maintained recipes.
• Do not make the presets a replacement for user-specific evals; they are starter policies with probes.

Acceptance criteria

• Maintained presets exist for balance, cost-first, accuracy-first, speed-first, privacy-first, and grounding-first under the repo's recipe surface.
• Each preset has a README or docs section explaining intent, model/provider assumptions, example requests, expected routing behavior, and customization points.
• Each preset has executable probes or an explicit receipt explaining why probes cannot yet run.
• Existing balance and privacy recipes are reviewed and tuned rather than duplicated under inconsistent names.
• Presets use stable canonical config concepts, including providers.models[].backend_refs[], routing signals/projections/decisions, and clear model-selection strategy fields.
• Presets are compatible with the planned multi-recipe/entrypoint work in #2331, including clear virtual model names once that contract lands.
• Dashboard preset metadata is updated or a focused follow-up issue is created if dashboard support cannot land in the same PR.
• Docs clearly distinguish these presets from lower-level examples and experimental recipes.
• Validation covers config parsing, DSL round-trip where applicable, probe execution, and docs/reference links.

Validation

Use the repo harness to scope follow-up PRs:

make agent-report ENV=cpu CHANGED_FILES="deploy/recipes config src/semantic-router/pkg/dsl src/semantic-router/pkg/config src/semantic-router/pkg/selection src/semantic-router/pkg/looper src/vllm-sr/cli website/docs dashboard/backend/handlers/presets.go"
make agent-lint CHANGED_FILES="deploy/recipes config src/semantic-router/pkg/dsl src/semantic-router/pkg/config src/semantic-router/pkg/selection src/semantic-router/pkg/looper src/vllm-sr/cli website/docs dashboard/backend/handlers/presets.go"
make agent-ci-gate CHANGED_FILES="deploy/recipes config src/semantic-router/pkg/dsl src/semantic-router/pkg/config src/semantic-router/pkg/selection src/semantic-router/pkg/looper src/vllm-sr/cli website/docs dashboard/backend/handlers/presets.go"

Add targeted recipe/probe tests so maintained presets cannot silently drift away from runnable defaults.