diff --git a/docs/v3-adoption-gates.md b/docs/v3-adoption-gates.md
index b246351..724e335 100644
--- a/docs/v3-adoption-gates.md
+++ b/docs/v3-adoption-gates.md
@@ -58,6 +58,13 @@ raw byte-bigram試作、SequenceModel形式契約、training仕様の精緻化
 2つのvalidation corpusでcategory 0が減少し、positive側の内部スコアが高い範囲になった。
 ただしpaired分離件数は旧モデルと同じで、encoding accuracy改善・標準採用の根拠にはしない。
 
+[候補競合を含めた評価](v3-full-engine-model-comparison.md)まで進めた結果、Paris validation
+のcp1252 16入力でdecode-equivalentがlegacy 16件に対しidentity 5件、filtered 7件だった。
+したがって、この固定モデルの標準採用は推奨しない。単に接続が未完了なのではなく、
+限定的ながら実際の識別品質に反証が得られた状態である。
+他言語・別domain・大入力・incremental全体については、この結果から推測しない。
+generator基盤と非デフォルト観測targetは維持し、内部選抜の分析を次の課題にする。
+
 ## 互換性とmigration
 
 v3では必要な破壊的変更を許容する方針だが、現段階で具体的な公開API変更を決めたわけではない。
diff --git a/docs/v3-cxx20-distribution.md b/docs/v3-cxx20-distribution.md
index 9063358..7925855 100644
--- a/docs/v3-cxx20-distribution.md
+++ b/docs/v3-cxx20-distribution.md
@@ -120,8 +120,9 @@ native compiler matrixでspan / bit_cast / ranges等を確認した。
 上記30 wheelは追加probeを組み込んだartifactの検証ではなく、最低runtime gateも残る。
 
 さらに[glibc 2.24での限定的な実行確認](v3-minimum-runtime.md)で、保存済みの
-CPython 3.11〜3.14 / 3.14tのx86_64全5 wheelのinstalled smokeが成功した。ARM64と
-最低macOS/Windowsは未確認であり、全体gateは維持する。
+CPython 3.11〜3.14 / 3.14tのx86_64全5 wheelのinstalled smokeが成功した。
+後続の[ARM64 runtime検証](v3-arm64-runtime.md)でもQEMU上で全5 ABIが成功している。
+ARM64実機と最低macOS/Windowsは未確認であり、全体gateは維持する。
 
 [sdist build要件と独立再build](v3-sdist-build.md)も記録した。tar.gzからC++20 wheelを
 再構築し独立uv環境のsmokeが成功したが、他platformの最低runtime保証とは別である。
diff --git a/docs/v3-full-engine-model-comparison.md b/docs/v3-full-engine-model-comparison.md
index 343ab07..44e4c94 100644
--- a/docs/v3-full-engine-model-comparison.md
+++ b/docs/v3-full-engine-model-comparison.md
@@ -68,3 +68,45 @@ file SHA-256: `79654809fe9985af4e89eac06aeb9d54af20001dc01301b70c4ceb7a6435a4ca`
 次は既存French ISO系modelとの競合過程を確認し、model coverageの問題と較正の問題を
 分離する。このvalidationを調整用へ転用せず、調整する場合は別のtuning splitを用意する。
 今回の結果だけからthresholdを動かしたり、他の候補を削除したりしない。
+
+## 小規模1入力の内部観測
+
+後続の原因調査として、既存`benchmark/uchardet-trace.cpp`をfiltered実験libraryへ
+linkし、上記validationの先頭cp1252文書だけを10秒上限で観測した。
+入力は2,473 bytes、SHA-256は
+`272f13d8f2d9bb83f61c91b1dd698ff35182f3480e9005b5f45c5768822c4ea9`。
+全失敗の原因をこの1件で代表させない。
+
+feed後・end後ともSBCS groupは`detecting`だった。Frenchの3 modelはいずれも
+306文字・246 frequent文字・193 sequenceを観測していた。
+
+| model | category 0/1/2/3 | control文字 |
+| --- | --- | ---: |
+| 既存ISO-8859-1 | 0 / 0 / 6 / 187 | 5 |
+| 既存ISO-8859-15 | 0 / 0 / 6 / 187 | 5 |
+| 生成cp1252 (filtered) | 20 / 5 / 7 / 161 | 0 |
+
+raw reportのISO-8859-1/frのconfidence bitsは`3f45eb28`で、保存済みC API観測の
+先頭候補と一致した。ただしtraceのraw reportはC APIのsort/dedup後一覧ではない。
+この照合を全候補の一致試験とは扱わない。
+
+現行`nsSingleByteCharSetProber::GetConfidence()`のpositive approachは
+`(positive + probable / 4 - negative * 4) / sequences / typical_ratio`を基礎とし、
+さらにcontrol/out文字とfrequent文字の比率を掛ける。
+今回の生成modelではnegative 20件の寄与がある一方、既存ISO系にはない。
+encoding上のcontrol文字ペナルティだけでは、誤ったISO系候補を排除できていない。
+これは次の較正分析の具体的な根拠であり、係数変更の正当化ではない。
+
+観測source SHA-256は
+`20099148d16425a079cc4bef795b50a8fdd5a0bbfa011c47122c71634ad19a84`、
+観測実行file SHA-256は
+`e9eb443b9cf1ea8fe5fdf8fb0aa713ca4e26499a729163de9329cb3d12f472fe`。
+compileは`c++ -std=c++11 -O2 -Isrc/ext/uchardet/src`で、
+`archives/v3-corpus/engine-paris-filtered-v1/build/src/liblibuchardet_experimental.a`
+をlinkした。traceの引数は`0 INPUT_FILE`（one-shot）。model・入力を変更していない。
+
+同じtraceと実験conformance実行fileを`UCHARDET_TRACE` / `UCHARDET_CONFORMANCE`に
+指定し、`uv run --locked --offline --no-sync pytest -q tests/test_report_attribution.py`も
+実行した（28 passed）。空入力・ASCII・既存の短い日本語fixtureを0/1/7-byte scheduleで
+照合する9試験を含む。最終候補の値がraw reportに存在すること等の確認であり、内部rankingの
+因果証明・全corpusの観測非干渉・精度向上の証明ではない。