# Project Bindings

## Operational evidence

M6 links the ExampleRAG `rag.embedding@1` binding to scoped service authentication, isolated embedding
migrations and evaluation suites. A binding still does not select a concrete model or node.

Projects bind to versioned capabilities, never deployments, model names, runtime engines or paths.
M11 permits a service identity to reference exactly one real binding and records its integration
environment and purpose. Authentication revalidates that the binding is not deprecated and that its
contract still equals the client's sole scope. Background and interactive work use separate identities
so callers cannot self-promote priority. See ADR-0030.

Deployment promotion, placement and embedding-space migration remain control-plane concerns. A
project binding may pin a capability version and embedding-space expectation, but cannot override
the stable route or address a worker directly.

ExampleVision has separate operational bindings/clients for background vision indexing, interactive
vision queries and interactive speech transcription. OCR remains planning-only until a safe model and
project evidence exist.

M12 treats a project production binding as an independent lifecycle subject. A platform capability
may remain stable while the project request is blocked. The default project-production policy needs
eligible fit and satisfied external validation; ExampleVision Vision therefore remains blocked and ASR
remains LAB without mutating their engineering integration evidence.