「確認した」の意味を一段ずつ止める――付録G 証拠レベルと「確認済み」の定義

676　付録G　証拠レベルと「確認済み」の定義

ここまで私は、

PASS

CONFIRMED

SOURCE_IDENTICAL

NOT_GATED

ABSENT

NOT VERIFIED

という言葉を何度も使いました。

見た目は全部、

○か×の判定語に見えます。

でも、

同じ軸の判定ではありません。

ここを最後に固定します。

677　最初に、証拠は一種類ではない

今回の裸監査には、少なくとも次の証拠面があります。

物理証拠。

ファイルが存在する。

bytesがある。

SHAがある。

CRCが通る。

unsafe pathがない。

source contract証拠。

READ_ORDERやmanifestに対して、対象bytesが一致する。

machine regression証拠。

runtime自身のtestを実行し、期待結果を返した。

behavior証拠。

実際の処理を読み、ある責任が観測できた。

component classification証拠。

その挙動がbottom-up gateを満たすため、SKILLやGUARDなどとして分類できた。

外部境界証拠。

別runtimeやcurrent mountまで含むend-to-endが実際に確認できた。

全部別です。

678　PASS は、必ず「何のPASSか」を読む

たとえばDS90では、

UTF-8：

PASS。

JS syntax：

52/52 PASS。

JSON：

30/30 PASS。

npm test：

140/140 PASS。

runtime checker：

PASS。

router trigger sweep：

131/131 PASS。

が並んでいます。

でも同じ監査の直後に、

package checkerは、

story quality。

canon correctness。

MT00 completion。

SP00 completion。

context-capacity safety。

までは証明しない、

と明記されています。

つまり、

PASSという単語だけを切り出してはいけない。

679　PASS は試験対象の内側でだけ強い

npm test 140/140 PASS

なら、

その140件のregression testが期待通り通った。

これは強い証拠です。

でも、

140件に含まれていない事実までPASSにはならない。

ZIP CRC PASSも同じ。

ZIP構造の検査です。

本文品質の判定ではありません。

manifest PASSも、

manifest整合の証拠です。

story canonの証拠ではありません。

680　だからtest数を「信頼度」に変換しない

DS90：

140。

PW90 POST：

117。

TS90：

71。

CHECKER：

3。

この数字だけから、

DS90はCHECKERより約47倍信頼できる、

とは言えません。

各runtimeの責任範囲とtest surfaceが違うからです。

3/3は、その3件について100%通った。

140/140は、その140件について100%通った。

そこから先を勝手に倍率化しません。

681　CONFIRMED は「その器官が実在すると分類できた」

CONFIRMED

はtest PASSとは別です。

たとえばDS90では、

ROOT_OPERATION_ROUTER

が、

ROUTER / CONFIRMED

です。

理由は、

13個の実在operation候補があり、

明示operationまたはtriggerで選択し、

ambiguous / unknownをSTOPし、

router自身がbusiness artifactを作らない、

という観測があるからです。

つまり、

CONFIRMED は、

裸監査で観測した挙動が、そのcomponent分類のgateを満たした

という意味です。

682　CONFIRMED は「理想実装」の意味ではない

ここが少し紛らわしい。

CONFIRMED_SPLIT_CANDIDATE

という状態があります。

たとえば、

SPECIALIST_TARGET_ROUTER

は、

ROUTERとしてのselection責任そのものは確認できた。

でも、

そのselectionがspecialist business module内部へ混在していた。

だから、

器官は実在する。物理境界はまだ綺麗ではない。

この二つを同時に書くため、

CONFIRMED_SPLIT_CANDIDATE

になっています。

683　CONFIRMED_EXCEPTION_ONLY もある

DS90の、

MOUNT_TRANSFER_MINIMUM

PACK_CUTOUT_MINIMUM

は、

実装そのものは実在。

しかしnormal routeを所有する器官ではなく、

文書上はexception-only。

だから、

CONFIRMED_EXCEPTION_ONLY

です。

ここでも、

CONFIRMEDだからnormal採用、

ではありません。

存在確認と運用資格を分けています。

684　PARTIAL_CURRENT は、成立したところまで

DIRECT_RUNTIME_DISPATCH_REQUEST

は、

PARTIAL_CURRENT。

dispatch manifest。

route。

nextAction。

metadata。

そこまでは実在します。

しかし、

current 000_C を開き、

selected laneをinvokeするところまでは実装されていませんでした。

だから、

全部できるとも、

何もできないとも書かない。

成立している境界までを書く。

685　NOT_GATED はFAILではない

これは今回、一番誤解しやすい判定です。

UPPER_ROUTER = NOT_GATED

SKILL_CHAIN = NOT_GATED

と書くと、

「UPPER_ROUTERを実装し忘れた」

「CHAIN機能が壊れている」

ように見えます。

違います。

NOT_GATED は、

その構造を生やす条件が、現在の実体から証明されていない

という意味です。

DS90でも、

二つのlower routerが同じexternal inputを競合していないためUPPER_ROUTER gateは不成立。

ordered checksはあるが、A-output → B-input dependencyがないためSKILL_CHAIN gateも不成立です。

686　NOT_GATED は、場合によっては正常完成状態

bottom-upでは、

必要のない構造を作らない。

だから、

NOT_GATEDは、

欠損ではなく正常な不在

になり得ます。

ナルの一候補router。

ヌルのUPPER_ROUTER。

CHECKERのSKILL_CHAIN。

それらは、

「今すぐ実装してください」

という未完成札ではありません。

必要条件が発生していないなら、

ないままで正しい。

687　ABSENT と NOT_GATED も違う

ABSENT は、

観測対象となる器官が現在存在しない、

という物理・構造状態です。

NOT_GATED は、

作る条件が成立していない

という構築判定です。

たとえば、

RUNTIME_COMPONENT_LEDGERが、

ABSENT

だった個体が複数あります。

その後、

component freezeが成立したならledger作成gateが開く可能性はある。

つまり、

ABSENTだから永遠に不要、

でもありません。

688　GATE_AFTER_COMPONENT_FREEZE

DS90のcomponent ledgerは、

単純なABSENTではなく、

GATE_AFTER_COMPONENT_FREEZE

でした。

当時のmanifestやregistryは、

runtime-component ledgerではない。

でも、

実在componentをfreezeした後なら、

その実体だけを記録するmanagement ledgerを作れる。

だから、

まだ作るな。しかし条件が整えば作ってよい。

この中間状態も残しています。

689　SOURCE_IDENTICAL は、機能品質の判定ではない

PW90 PREでは、

READ_ORDER：

20。

SOURCE_MANIFEST：

20。

manifest hash match：

20/20。

その結果、

verify_decision: SOURCE_IDENTICAL

です。

PW90 POSTでも、

READ_ORDER 22。

manifest 22。

hash match 22/22。

SOURCE_IDENTICAL。

これは、

検証対象source bytesが、契約上期待されたsourceと一致している

というidentity判定です。

「このruntimeは設計として完璧」

という意味ではありません。

690　SOURCE_IDENTICAL と PASS は直交する

sourceが完全一致していても、

testが落ちることは理論上あり得ます。

逆に、

testが通っていても、

本来比較すべきsourceと違う個体を実行していたなら、

標本として問題です。

だから今回、

identity確認

と、

behavior test

を分けました。

PW90 PREは、

SOURCE_IDENTICAL。

そして82/82 PASS。

二つの別証拠が同時に成立しています。

691　全身監査masterでもbyte identityを別検査した

全身裸監査bundle自身にも、

SOURCE_RUNTIME_BYTE_IDENTITY: 9/9 PASS

があります。

あわせて、

MASTER CRC PASS。

duplicate paths 0。

9 audit subjects / 8 runtime shelves。

個別audit ZIP SHAも固定されています。

これによって、

監査bundleへ入れたSOURCE_RUNTIMEが、監査対象として固定したsourceとbyte-identicalか

を別に確認しています。

692　つまりidentityは二重に持っている

今回の標本には、

少なくとも二種類のidentityがあります。

runtime内部source contractとしてのidentity。

PW90のREAD_ORDER / manifest hash matchなど。

そして、

監査bundle保存時のsource runtime byte identity。

master validationの9/9 PASS。

目的が違います。

前者はruntime自身のsource contract。

後者は監査標本保存のintegrityです。

693　NOT VERIFIED はFAILではない

DS90裸監査では、

current 000_C lane invocationについて、

NOT verified

と明示しました。

理由は、

そのturnでLibrary copyをmaterializeできず、

403だったからです。

確認できたのは、

DS90側dispatch metadataとtestsまで。

ここから、

「E2Eは壊れている」

とは言いません。

694　もちろんPASSにも変えない

逆も禁止です。

metadataが正しい。

pathらしきものがある。

testも通っている。

だから、

「たぶんcurrent 000_Cも呼べる」

として、

E2E PASSにする。

これもしません。

裸監査のM07は、

actual lane invocationが確認できていないため、

未検証境界として残しています。

695　NOT VERIFIED は、証拠不足の所在地

この言葉は、

機能の善悪ではなく、

監査証拠がどこで途切れたか

を示します。

これはかなり重要です。

「不明」

だけだと、

何が不明なのか分からない。

M07の場合は、

DS90-side dispatch contractまでは見た。

actual 000_C lane invocationから先が未検証。

つまり、

証拠線の終端が分かる。

696　後で証拠が増えても、過去のNOT VERIFIEDを書き換えない

後の再構築仕様では、

current 000_Cのroute bytes / path / hashについて、

追加確認が進んでいます。

それでも仕様は、

rebuilt DS90のend-to-end dispatch PASSまではまだ宣言できない、

と明確に分けています。

そして最終的には、

rebuilt DS90 → current 000_C → selected runtime boundaryを、

別のintegration testとして要求しています。

つまり、

証拠が一段増えたら、

一段だけ進める。

697　STOP も「runtimeが壊れた」とは限らない

DS90裸監査では、

MOUNT_ZIP_BOOTSTRAP

SPECIALIST_HANDOFF

を明示operationとしてexecuteすると、

STOP / SCHEMA_ENUM

でした。

これはruntime全体がクラッシュしたのではありません。

schemaが、

そのexplicit operationを合法入力として受けなかった。

意図されたSTOP形式で拒否した。

問題は、

catalog側にはそのoperationが存在していたため、

surface同士が矛盾していたことです。

698　STOPそのものが失敗とは限らない

unsafe pathを入れた。

STOPした。

これは正常です。

required inputがない。

STOPした。

正常です。

canon不明。

STOPした。

正常です。

一方、

正規入力なのにschema/catalog不一致でSTOPした。

これは構造findingになります。

だからSTOPも、

何を止めたのか

まで見なければ意味がありません。

699　CONFIRMED_LEGACY

これも特殊です。

DS90の、

EPISODE_PACK_LEGACY_VALIDATION

は、

独立validatorとして実在する。

だからCONFIRMED。

でもlegacyです。

つまり、

存在証明は通ったが、current normal architectureへ永久採用する判定ではない。

compatibilityとして必要なら残る。

不要ならdeprecated / bypass候補になる。

700　CURRENTLY_RESIDUAL

MATERIAL_MAP_V2

は、

CURRENTLY_RESIDUAL。

build / validate functions自体はtestされている。

しかしcurrent PACK_CUTOUTでactive consumerが確認できない。

だから、

動くコードがあることと、現行経路で責任を持つことを分けた。

「testがあるから現役」

とはしません。

701　DISTRIBUTED_CONFIRMED

ARTIFACT_POLICYでは、

この表記も出ました。

これは、

一個の独立moduleとしてartifact policyがある、

という意味ではありません。

output contract。

validator。

package verification。

複数箇所へ責任が分散しているが、

それらを合わせると一つの確認可能なartifact boundaryが実在する

場合です。

だから、

DISTRIBUTED_CONFIRMED。

702　EMBEDDED

SP00のEND_LOGなどでは、

EMBEDDED

も使いました。

report責任は存在する。

でも、

engine等の別責任と物理的に同居している。

したがって、

存在しないわけではない。独立器官でもない。

これも二択に潰さないための状態です。

703　CONDITIONAL

DS90のLOG / ARCHIVEは、

CONDITIONAL。

名前はLOG。

名前はARCHIVE。

でも実観測は、

request validationまで。

persistent loggingやfile archiveまでは確認されていない。

だから、

完全SKILLとしてCONFIRMEDにも、

存在しないにもしていません。

現在観測された責任へ名前を縮める必要がある候補。

704　この記事で「確認した」と書く時の最小条件

ここまでをまとめると、

この記事で私が、

「確認した」

と書けるのは、

少なくとも、

その主張を支える監査証拠が存在し、

その証拠範囲を越えていない場合だけです。

fileがあるだけで機能確認とはしない。

名前があるだけでcomponent確認とはしない。

test PASSだけで外部E2E確認とはしない。

document declarationだけで実装確認とはしない。

705　宣言名は証拠にならない

PW90 POSTは、この問題をかなり露骨に見せます。

canonical-runtime-route.js

はL3 UPPER_ROUTERと宣言されていました。

しかし裸監査は、

実際のlower-router competition gateを別途要求し、

宣言だけではUPPER_ROUTERの証拠にならない

としています。

同じく、

runtime-skill-chain.js

にS00〜S12が宣言されても、

各dependencyを独立証明しなければcanonical SKILL_CHAINには昇格しません。

706　「ファイル名に書いてある」は、最弱の入口

これは今回の監査で一貫しています。

router.js

がある。

まず読む。

SKILL_CHAIN

と書いてある。

まず読む。

archive.js

がある。

まず読む。

その後で、

実際に何をしているかを見る。

名前は探索の入口。

分類の結論ではありません。

707　逆に、名前がなくても器官は実在する

DS90の、

GLOBAL_DECISION

END_LOG_REPORT

は、

最初から綺麗な独立module名で存在していたわけではありません。

engine内部の挙動を分解すると、

terminal authority。

report policy。

として独立責任が観測できた。

だから、

名前がなくても、挙動がgateを満たせば器官は実在する。

これも重要です。

708　物理存在、挙動存在、architecture存在

私は今回、この三つを分けています。

物理存在。

ファイルがある。

挙動存在。

その処理が実際に行われている。

architecture存在。

その挙動が独立componentとしてgateを満たしている。

たとえば一候補router.jsは、

物理存在する。

entry normalization挙動もある。

でもcanonical ROUTERとしては不成立。

三層が別です。

709　この記事が証明していないもの

ここは一覧で置きます。

この記事は、

• 基盤モデルそのものの能力を証明しない

• 小説本文の品質を客観評価した研究ではない

• 全作品のcanon correctnessを証明しない

• 全runtimeのすべての潜在挙動を列挙したものではない

• 341 files全部を341独立componentとして分類していない

• runtime test数を品質ランキングへ変換しない

• 裸監査後の再構築個体がすべて同じ状態にあるとは主張しない

• PRE標本から現在のE2E状態を推測しない

• 古い運用資料をcurrent implementation evidenceとして使わない

• v003を過去個体の元設計書として扱わない

ここは、記事全体のnon-goalです。

710　特に「物語が良くなる」は、この監査から直接証明できない

runtimeを細かくする。

境界を明確にする。

STOPを正直にする。

それによって、

作品品質が必ず上がる。

そこまでは、

裸監査だけでは証明できません。

できるのは、

どの責任がどこにあり、どの責任が混ざり、どの境界が機械的に検査されていたか

を示すことです。

作品結果との因果は、別の検証が必要です。

711　比較検証も、比較した範囲だけ

たとえば話レイヤー比較で、

ある条件の本文が読みやすかった。

それは比較標本として重要です。

でも、

一つの比較から、

「このlayer設定なら全作品で必ず優れる」

とはしません。

比較実験。

runtime audit。

architecture classification。

それぞれ証拠強度と対象が違う。

全部を一つの「検証済み」へ潰さない。

712　SOURCE_RUNTIME_BYTE_IDENTITY 9/9 PASS が保証するもの

全身監査masterでは、

9 audit subjectsについて、

source runtime byte identityが9/9 PASSです。

これが保証するのは、

監査bundleへ保存したsource runtime identity。

つまり、

「監査したはずの個体と、bundleへ入れた個体が別物だった」

という事故を防ぐ証拠です。

この9/9 PASSだけで、

全機能の意味が正しい、

とはしません。

713　SHAは「意味」を証明しない。しかし「同じもの」を強く証明する

SHA-256は、

小説の良し悪しを知りません。

ROUTERが本物かも知りません。

でも、

そのbytesが同じか

という問いには非常に強い。

だから今回、

意味の監査と、

identityの監査を分けています。

意味はcomponent classification。

同一性はSHA / byte identity。

714　CRCも同じ

CRC PASSは、

ZIP内部が壊れていないことの証拠です。

でも、

ZIPの中身が正しいruntime architectureかどうかは別。

逆に、

architecture説明が完璧でも、

ZIPが破損していたら配布物として成立しない。

だから両方を見る。

715　manifestも同じ

manifest missing 0。

extra 0。

mismatch 0。

これは、

期待した物理構成と実体が一致したことを強く示します。

でも、

そのmanifestに登録された一つ一つの意味が妥当かは、

別監査です。

inventory truthとsemantic truthを分ける。

716　この証拠分離が、一番「設計さん」らしい仕事だった

今回、

何かを見つけるたび、

私はすぐ上位結論へ進まないようにしました。

ファイルがある。

では、挙動は？

挙動がある。

では、独立責任か？

責任がある。

では、gateを満たすか？

testが通る。

では、何をtestした？

sourceが一致する。

では、何とのidentityか？

外部runtimeのpathが分かる。

では、実際にinvokeしたか？

一段ずつです。

717　確認済みを、必要以上に強くしない

証拠の扱いで一番危険なのは、

嘘を書くことだけではありません。

本当の証拠を、必要以上に強い言葉へ変換すること

です。

metadataを見た。

→ 実行した。

validatorがある。

→ 生成できる。

一候補selectorがある。

→ ROUTER。

順番がある。

→ CHAIN。

testが通った。

→ 全体品質保証。

これらは全部、

一段ずつ盛られています。

裸監査は、その盛りを剥がしました。

718　逆に、証拠を弱くしすぎない

もう一方もあります。

「どうせ完全には分からないから」

として、

全部を、

たぶん。

らしい。

可能性。

へ落とす。

これも違います。

SHAが一致したなら一致した。

140/140通ったなら通った。

ROOT_OPERATION_ROUTERがgateを満たしたならCONFIRMED。

current 000_C invocationが見られなかったならNOT VERIFIED。

強いところは強く、止まるところで止まる。

719　証拠語の凡例

最後に一枚へまとめます。

表記この記事での意味PASS指定されたmachine test / checker / invariantが期待結果を満たしたCONFIRMED観測挙動がそのcomponent分類のgateを満たしたCONFIRMED_SPLIT_CANDIDATEcomponent責任は実在するが、他責任と物理的に混在しているCONFIRMED_EXCEPTION_ONLY実装は実在するが、通常経路ではなく例外責任CONFIRMED_LEGACY実在するがlegacy責任として分類PARTIAL_CURRENT責任の一部だけが現在実装されているDISTRIBUTED_CONFIRMED独立moduleではなく複数箇所へ分散して責任が成立EMBEDDED責任は実在するが別component内部へ同居CONDITIONAL観測責任はあるが、名称または独立component資格を再判定する必要があるNOT_GATEDその上位構造を作る発生条件が現在証明されていないABSENT現在そのcomponent実体を確認できないGATE_AFTER_COMPONENT_FREEZE現時点では作らず、先行条件成立後に初めて候補になるCURRENTLY_RESIDUALcode / referenceは残るがcurrent active responsibilityが確認されていないSOURCE_IDENTICALsource contract上、期待source bytesとのidentityが成立SOURCE_RUNTIME_BYTE_IDENTITY PASS監査保存対象のsource runtime bytesが固定対象と一致NOT VERIFIED証拠がその境界まで到達していない。FAILとは判定していないSTOP指定された境界条件により処理継続を拒否した。STOP自体の正常/異常は理由で判定する

720　この凡例があると、「ない」を三種類に分けられる

一見すると全部、

「ない」

です。

でも実際には違います。

ABSENT

今は存在を確認できない。

NOT_GATED

存在させる必要条件が成立していない。

NOT VERIFIED

存在するかどうかを判定する証拠が足りない。

この三つを分けるだけでも、

かなり事故が減ります。

721　「ある」側も三種類では足りない

同じく、

「ある」

も複数あります。

物理fileがある。

実際のbehaviorがある。

component gateを満たしている。

normal routeに採用されている。

exception-onlyである。

legacyである。

distributedである。

embeddedである。

これらは全部違います。

だから、

存在はyes / noではなく、責任状態まで書く。

722　そして記事本文へ戻る必要は、もうない

ここまで凡例を固定すれば、

本文で使った、

PASS。

CONFIRMED。

NOT_GATED。

NOT VERIFIED。

といった言葉を、

読者が同じ物差しで読めます。

本文へ全部説明を戻す必要はありません。

本編は身体を見る場所。

付録は、

その身体をどう測ったかを見る場所。

役割を分けます。

723　付録Gの結論

今回の裸監査で大事だったのは、

「全部確認した」

と言えることではありませんでした。

むしろ、

どこまで確認したかを、一段ずつ止められること

でした。

source bytesは一致した。

testは通った。

器官は実在した。

上位器官のgateは成立しなかった。

外部境界は見られなかった。

それぞれ、

そのまま書く。

全身監査masterでも、source runtime byte identityは9/9 PASSとして独立検証され、標本数は9 audit subjects / 8 runtime shelvesと固定されています。

そしてDS90監査は、自身の140/140 PASSと同じ場所で、package checkerの非証明範囲とcurrent 000_C invocationの未検証も併記しています。

私は、この書き方を採用します。

分かったことは分かった。

分からなかったことは分からなかった。

その境界自体を、

証拠として残す。

次は最後の資料付録です。

付録H　標本・診断書・構築仕様・歴史資料の参照地図。

この記事で使った資料を、

「現在標本の証拠」
「PRE / POST比較」
「思想の地層」
「これからの構築原則」

へ分けて並べます。