docs(agents): archive rejected variation policy

This commit is contained in:
ayattara
2026-09-07 19:51:19 +00:00
parent 0b3f0de114
commit 4986df52df
@@ -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