Decision needed: should Grid ever support prefix-cache-driven routing?

[jordigilh]

Context

@nerdalert — raising this as a decision, not an implementation ticket. Not urgent, no action needed before any near-term demo.

docs/demos-2026.md specifies a prefix-cache/KV-cache affinity demo scenario. prefix_cache_score() (in scoring/src/scoring.rs) is fully implemented and unit-tested — the scoring math itself was never in doubt.

The conflict

GridNetwork.spec.scoringPolicy.strategy (operator/src/crd/grid_network.rs) is a hardcoded 3-value enum: noMetrics | queueDepth | kvCachePressure. Every one of the three hardcodes the prefix_cache weight to 0.0 in ScoringStrategy::weights(). There's no fourth variant, and this isn't an oversight — docs/architecture/scoring.md documents it as deliberate:

Grid therefore does not offer a prefixAware scoring strategy... Prefix affinity belongs in EPP.

So even wiring a real prefix-cache metric end-to-end would never reach live routing through any real GridNetwork CR today. The demo as specified in docs/demos-2026.md conflicts with this documented architecture decision.

Cost, if the decision is "yes, support it"

Actually implemented the 4th ScoringStrategy::PrefixCache variant to measure the real cost rather than guess it (reverted after measuring, nothing committed):

• Compiles clean across the whole workspace, zero other call sites need changes (confirmed via cargo check --workspace --all-targets and a Serena reference search)
• cargo run -p operator --bin generate_crds picks it up automatically, no manual CRD YAML editing
• The prefix_cache_hit_ratio metric pipeline (scrape config, Prometheus parsing, clamping, neutral defaults) is already fully implemented and tested — only grid-mock-providers would need a small (~20-30 line) addition to expose it
• Total: roughly 1 day, including mock-provider wiring

The change is actively guarded, not just documented: a dedicated regression test, scoring_strategy_enum_in_crd_schema, asserts exactly 3 strategies exist, with the message "only the three supported strategies belong in the CRD".

Ask

Given the ~1-day cost is now known precisely, is docs/architecture/scoring.md's "prefix affinity belongs in EPP, not Grid" position still the right call, or is it worth revisiting for a customer-facing demo? Either answer is fine — just needs to come from whoever owns that doc before anyone files an implementation issue.

(Not blocking anything near-term: kvCachePressure — one of the 3 real, already-supported strategies — substitutes for this demo beat today.)