docs(agents): archive rejected variation policy
This commit is contained in:
@@ -24,55 +24,25 @@ Variation text is provider-owned. Kandev cannot safely rank `270k`, `1m`,
|
||||
`fast`, or future labels. Catalog order and the current-model marker do not
|
||||
express user intent.
|
||||
|
||||
## Decision
|
||||
## Rejection
|
||||
|
||||
Kandev recognizes a model variation only by a narrow bracketed ID shape. A bare
|
||||
requested ID `x` matches an advertised ID `x[v]` when `v` is non-empty and
|
||||
contains no bracket. Matching is exact and case-sensitive. Kandev treats `v` as
|
||||
opaque text.
|
||||
This proposal was not adopted. It would have inferred a bracketed advertised
|
||||
model from a bare profile model and treated that inferred ID as an authorized
|
||||
selection. That conflicts with the accepted exact-profile boundary: an
|
||||
inferred ID is a different runtime identity from the configured model.
|
||||
|
||||
For profiles with `auto_fallback = false`, the executor-authoritative resolution
|
||||
order is:
|
||||
No variation-matching algorithm, inferred-selection outcome, warning reason,
|
||||
or launch, reset, or workspace-rebind behavior was adopted from this proposal.
|
||||
The accepted policy is recorded exclusively in
|
||||
[Enforce Exact Profile Model Identity](2026-09-06-exact-profile-model-identity.md).
|
||||
|
||||
1. Exact requested model.
|
||||
2. Advertised explicit fallback from the profile.
|
||||
3. One distinct advertised variation of the requested bare model.
|
||||
4. Provider current or default model, with no speculative model-selection call.
|
||||
## Consequences of rejection
|
||||
|
||||
Kandev applies step 3 only when exactly one distinct candidate exists. Zero or
|
||||
multiple candidates produce no inferred selection. An unadvertised explicit
|
||||
fallback does not block step 3.
|
||||
|
||||
A requested ID that contains a bracket is an exact ID only. Kandev does not
|
||||
infer another variation from it.
|
||||
|
||||
Profiles with `auto_fallback = true` retain the legacy path when the requested
|
||||
model is absent. Kandev ignores the configured explicit fallback, does not
|
||||
infer a variation, and continues with the provider current or default model.
|
||||
Apply errors for an advertised model remain best-effort in that mode.
|
||||
|
||||
The lifecycle stores `unique_variation` as the decision outcome and
|
||||
`unique_variation_applied` as the warning reason. The effective model contains
|
||||
the advertised variation. The explicit fallback field keeps its existing
|
||||
meaning and stays empty when Kandev infers a variation.
|
||||
|
||||
The saved profile model does not change. The rule runs for initial launch,
|
||||
context reset, and workspace rebind. The executor catalog remains authoritative.
|
||||
Any host-catalog result remains an advisory.
|
||||
|
||||
## Consequences
|
||||
|
||||
- A profile with `opus` follows `opus[1m]` when it is the only advertised
|
||||
variation.
|
||||
- A catalog with `opus[270k]` and `opus[1m, fast]` remains ambiguous and uses
|
||||
the existing provider-default path.
|
||||
- An explicit advertised fallback remains stronger than inference.
|
||||
- Kandev never sends a model ID that the executor did not advertise.
|
||||
- Users receive a durable warning because the effective model differs from the
|
||||
saved request.
|
||||
- Provider-specific ranking logic does not enter the lifecycle policy.
|
||||
- Backend and frontend helpers need mirrored contract tests. The backend result
|
||||
remains authoritative when their input catalogs differ.
|
||||
- The historical `opus` to `opus[1m]` example does not authorize inference.
|
||||
- Provider-specific variation labels and catalog order do not establish a
|
||||
substitute model identity.
|
||||
- Any future variation policy requires a new accepted decision that is
|
||||
compatible with exact-profile identity.
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
|
||||
Reference in New Issue
Block a user