vllm-project/semantic-router

feature: unify projection contract across Go, DSL, CLI, and dashboard surfaces

Open

#1,761 opened on Apr 10, 2026

View on GitHub
 (2 comments) (0 reactions) (1 assignee)Go (699 forks)github user discovery
area/coreenhancementhelp wantedpriority/P2

Repository metrics

Stars
 (4,293 stars)
PR merge metrics
 (PR metrics pending)

Description

Describe the feature

Unify the projection contract across Go config, DSL compile and decompile, Python CLI schema, and dashboard editing surfaces so richer projection semantics do not drift between authoring and runtime.

Primary layer

global level

Why this layer?

Projection is one logical contract, but the repo expresses it across multiple authoring and validation surfaces. This issue is about keeping those surfaces aligned as the projection layer evolves.

Why do you need this feature?

The projection layer already spans:

  • Go runtime config and validators
  • DSL parse, compile, decompile, and validator semantics
  • Python CLI schema and validation
  • dashboard config editing and insights affordances
  • docs and maintained recipes

As projection semantics widen, cross-surface drift becomes one of the main risks. A capability that exists only in one layer is operationally expensive and confusing for contributors and users.

Additional context

Affected repo surfaces

  • src/semantic-router/pkg/config/{projection_config.go,validator_projection.go}
  • src/semantic-router/pkg/dsl/{ast.go,parser.go,compiler.go,decompiler.go,validator_conflicts.go,routing_contract.go}
  • src/vllm-sr/cli/{models.py,config_contract.py,validator.py}
  • dashboard/frontend/src/pages/{ConfigPageProjectionsSection.tsx,configPageSupport.ts}
  • website/docs/tutorials/projection/{overview.md,scores.md,mappings.md}
  • maintained recipes such as deploy/recipes/balance.yaml

Suggested starting points

  • Start by inventorying the current projection fields and authoring semantics by surface.
  • Close at least one concrete mismatch in the same change instead of leaving this issue purely diagnostic.
  • Add parity enforcement where the repo can keep it maintained, such as contract tests or maintained-surface checks.

Validation commands

make agent-report ENV=cpu CHANGED_FILES="src/semantic-router/pkg/classification/classifier_projections.go,src/semantic-router/pkg/config/projection_config.go,src/semantic-router/pkg/config/validator_projection.go,src/semantic-router/pkg/dsl/ast.go,src/semantic-router/pkg/dsl/parser.go,src/semantic-router/pkg/dsl/compiler.go,src/semantic-router/pkg/dsl/decompiler.go,src/semantic-router/pkg/dsl/validator_conflicts.go,src/vllm-sr/cli/models.py,src/vllm-sr/cli/validator.py,dashboard/frontend/src/pages/ConfigPageProjectionsSection.tsx,dashboard/frontend/src/pages/configPageSupport.ts"
make vllm-sr-test
make test-semantic-router
make dashboard-check

Acceptance criteria

  • The repo has an explicit parity plan or enforcement path for projection fields across maintained surfaces.
  • At least one current projection-surface mismatch is closed.
  • Maintained docs or tests make it harder for future projection changes to drift across surfaces.
  • The issue leaves a clear contract inventory that follow-on projection issues can rely on.

Non-goals

  • adding new projection semantics by itself
  • replacing existing authoring surfaces
  • making dashboard editing the source of truth

Related

  • Child of #1711.
  • Related to #1757 because richer projection inputs increase the need for cross-surface parity.

Contributor guide