diff --git a/docs/decisions/2026-09-07-unique-model-variation-resolution.md b/docs/decisions/2026-09-07-unique-model-variation-resolution.md
index e04007030f..9ddcbdebae 100644
--- a/docs/decisions/2026-09-07-unique-model-variation-resolution.md
+++ b/docs/decisions/2026-09-07-unique-model-variation-resolution.md
@@ -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