26 lines
1.5 KiB
Markdown
26 lines
1.5 KiB
Markdown
# 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.
|