activate review log and freeze benchmark gate

Author: OpusNano

docs/benchmarking-plan.md

@@ -2,6 +2,10 @@
 
 This repository intentionally does not publish benchmark numbers yet.
 
+## Checklist version
+
+This document now serves as benchmark-readiness checklist v1 for the repository. Future changes should update this version deliberately rather than letting benchmark prerequisites drift implicitly.
+
 ## Hard gate: do not benchmark until all items below are true
 
 - public configuration fields are all semantically implemented or intentionally removed,

docs/literature-review-log.md

@@ -0,0 +1,82 @@
+# Literature Review Log
+
+This file turns the positioning checklist into concrete source-backed review tasks.
+
+Each task should end with at least one real citation and a short note about whether the source changes AdicFlux wording or comparisons.
+
+## Active review tasks
+
+### Task 1: Odd-even transposition / brick sort baseline
+
+Status: active
+
+Questions:
+
+- What standard references are appropriate for the exact cleanup stage?
+- What stability and worst-case guarantees are standard for that family?
+- Which parts of AdicFlux exactness reduce directly to this background?
+
+Capture:
+
+- citation:
+- result/theorem:
+- overlap with AdicFlux:
+- wording impact:
+
+### Task 2: Local-exchange or cellular sorting processes
+
+Status: active
+
+Questions:
+
+- Are there prior sorting schemes driven by neighborhood interactions or local drift?
+- Do those methods define an explicit energy or acceptance criterion?
+- Are they exact by themselves or paired with a fallback stage?
+
+Capture:
+
+- citation:
+- family/category:
+- strongest similarity:
+- strongest difference:
+- wording impact:
+
+### Task 3: Bit-structured integer sorting outside radix framing
+
+Status: active
+
+Questions:
+
+- Which methods inspect bit structure without following classic radix passes?
+- Are any of them comparison-based or energy-based rather than counting-based?
+- Do any use valuation-like or bit-closeness ideas relevant to AdicFlux wording?
+
+Capture:
+
+- citation:
+- bit-structure role:
+- overlap with AdicFlux:
+- wording impact:
+
+### Task 4: Stability proof techniques for local permutations
+
+Status: active
+
+Questions:
+
+- What proof patterns exist for stable local movement or stable transposition systems?
+- Can any of them transfer to AdicFlux transport acceptance?
+- Do they suggest stronger or narrower wording for current stability claims?
+
+Capture:
+
+- citation:
+- proof technique:
+- possible transfer to AdicFlux:
+- wording impact:
+
+## Exit criteria for stronger positioning language
+
+- every active task above has at least one concrete source recorded,
+- any novelty-sensitive wording in `README.md` or `docs/positioning.md` has been reviewed against those notes,
+- unresolved overlap questions are explicitly listed instead of silently ignored.

docs/positioning.md

@@ -114,4 +114,6 @@ Preferred phrasing remains:
 
 Avoid stronger novelty phrasing until the checklist above has been worked through with actual sources.
 
+See `docs/literature-review-log.md` for the active source-backed task log derived from this checklist.
+
 Until that review is done, "experimental algorithm proposal" is the right framing.

docs/stability.md

@@ -2,11 +2,11 @@
 
 ## Current status
 
-AdicFlux should currently be described as stability-aware, not stability-proved.
+AdicFlux should currently be described as test-supported for stability, not stability-proved.
 
-The repository does not claim a complete end-to-end proof that equal integer keys always preserve their original relative order under every accepted transport move.
+The repository still does not claim a complete end-to-end proof that equal integer keys always preserve their original relative order under every accepted transport move.
 
-The test suite now includes tagged-identity checks that simulate stable ordering obligations explicitly rather than relying on plain integer duplicates alone. Those tests have not found a counterexample in the current small exhaustive search and randomized stress coverage, but that remains evidence, not proof.
+The test suite now includes tagged-identity checks that simulate stable ordering obligations explicitly rather than relying on plain integer duplicates alone. Those tests have not found a counterexample in the current small exhaustive search and randomized stress coverage. That is stronger than a design intention alone, but it is still evidence rather than proof.
 
 ## What is stability-friendly today
 
@@ -23,9 +23,9 @@ That means the current target-resolution argument is not enough to prove full st
 
 ## Repository wording standard
 
-Until a stronger argument or stronger testing harness exists, the project should use language like:
+Until a stronger argument or significantly broader evidence exists, the project should use language like:
 
-- "intended stability property",
+- "test-supported stability behavior",
 - "stability-friendly implementation choices",
 - "not yet formally proved end-to-end".
 
@@ -37,7 +37,7 @@ It should avoid claiming simply "the algorithm is stable" as an unconditional th
 - tagged-identity tests compare AdicFlux-style behavior against a stable reference ordering,
 - small exhaustive searches over short arrays and randomized duplicate-heavy tests have not exposed an equal-key reorder so far.
 
-That strengthens confidence in the current implementation, but it still falls short of a proof obligation.
+That strengthens confidence in the current implementation and justifies slightly stronger wording than a bare design intention, but it still falls short of a proof obligation.
 
 ## What would justify stronger language later