判断構造 (Decision Structure、post-#1330 リネーム後の artifact) を industry 既存 vocabulary でどう位置付け、外部に対してどう説明するか。ADR (Architecture Decision Record) と呼べるか、別 framing を採用すべきか。

判断構造は ARCHITECTURE.md (matklad 2021) 哲学を decision domain に graph 構造として拡張し、time-axis を書き込み面から読み出し面に移管した hybrid 形 として位置付ける。ADR variant としては説明しない。

外部向け推奨説明文 (canonical form):

Decision Structure は ARCHITECTURE.md 哲学 (state-form / living document / refactor-friendly) を、system structure ではなく decision domain に適用したものである。単一 doc ではなく、判断ノードと supersede / depend / conflict edge から成る graph として構造化する。

ただし「state-form のみ」ではなく、time-axis を書き込み面 (entry body) から読み出し面 (evolution-judgment-learning skill + git log + supersede graph) に移管した hybrid である。entry body は state-form で読みやすさを優先し、過去判断の歩みは git history と edge taxonomy で完全に保持される。

ADR (Architecture Decision Record) の派生としては説明しない。両者は decision-focus surface を共有するが、time-axis を扱う場所が異なる (ADR は書き込み面 / 判断構造は読み出し面) ため、ADR の name で呼ぶと読み手の期待値 (numeric prefix、status lifecycle、append-only な entry 列) が mismatch する。

• depends on: decision-structure-rename-rationale - リネーム + state 形 / refactor framing 採用を前提とする判断
• clarifies: decision-structure-rename-rationale - 同 entry が確立した state-form framing を industry vocabulary 上に locate する補完軸 (forward-link で graph 一貫性維持)

Master との対話で「判断構造を ADR と呼べるか」という問いが surface した。industry 既存 vocabulary との対応を整理することで以下が達成される:

• 外部 (OSS contributor / 他プロジェクト読み手 / 将来の Li+AI セッション) に対する説明 cost 削減
• 判断構造を isolated novelty ではなく既存 stream の継承として locate (孤立した発明として誤読されることの防止)
• ADR convention を期待する読み手の mismatch 回避

整理の結果、判断構造は ADR とも ARCHITECTURE.md とも完全一致しないが、ARCHITECTURE.md 哲学に対しては domain shift + 構造 shift + time-axis relocation の 3 軸で連続的に拡張できることが判明した。

純粋な state-form (現在の判断基準のみを保持し過去の歩みを捨てる形) は self-defeating である。理由:

• 将来の評価者が「Y は X より良いか」を判定するには、X が選ばれた理由・代替案・制約 (= 履歴) を知る必要がある
• 履歴を捨てると基線が失われ、変更提案の評価そのものができなくなる
• 結果として「現在 state 固定 = 変更不可」に陥り、refactor-friendly という設計目標と矛盾する

したがって判断構造は履歴を捨てない。書き込み面 (entry body) の見た目を state-form で軽くしつつ、time-axis 自体は読み出し面 (evolution-judgment-learning skill、git history、supersede edge) で完全に保持する hybrid 設計を採る。

• 判断構造の運用方針 (state-form entry / refactor-as-normal / time-axis を読み出し面に移管) は既に #1330 で確定済であり、industry positioning 判断は本仕様を変更しない (forward guidance としての説明軸追加のみ)
• ADR community の既存規約を流用しない方針は意図的。流用すると ADR 期待値 (例: 0001-foo.md の numeric prefix、status: proposed/accepted/deprecated/superseded のような lifecycle 語彙、append-only entry 列) を読み手が想定し、現行 spec と衝突する
• ARCHITECTURE.md とも完全一致しない (single doc vs graph 構造の差、および time-axis を明示 edge taxonomy で扱うかどうかの差) ため、「ARCHITECTURE.md そのもの」とも呼ばない。「ARCHITECTURE.md philosophy applied to decision domain, with time-axis relocated from write surface to read surface」が最も literal な説明
• time-axis を「否定」しているわけではない。書き込み面から読み出し面へ relocate しているだけであり、履歴の保持自体は将来の変更を評価する土台として必須である

採用案: ARCHITECTURE.md-derived framing + time-axis relocation hybrid (上記 Current resolution)

却下案 + 理由:

ADR との一致軸: decision を artifact として記録する surface、設計判断を明示する目的、cross-session 再利用性、履歴を保持するという目標。

却下理由 (3 軸の衝突):

1. history in write surface vs history relocated to read surface: ADR は time-axis を書き込み面に置く (numeric prefix 0001-foo.md による chronological ordering + immutable entry + status lifecycle が書き手の負担として直接乗る)。判断構造は time-axis を読み出し面に relocate する (entry body は state-form で軽く、過去判断は git log + supersede edge + evolution-judgment-learning skill が読み出し時に再構成する)。両者とも履歴を保持するが mechanism が異なる: ADR は heavy ceremony / 判断構造は lighter mechanism。AI / Wiki authoring 文脈では heavy ceremony が割に合わない
2. append-only vs refactor: ADR は append-only / immutable-history を default とする (superseded ADR も削除せず status 変更で残す習慣)。判断構造は refactor as normal operation を採用し supersede via link を positive default とする
3. status lifecycle vocabulary vs edge taxonomy: ADR は status (proposed / accepted / deprecated / superseded) を entry attribute として扱う。判断構造は state-form entry に edge taxonomy (supersedes / depends on / conflicts with) を declare する graph 構造

ADR name を借用すると読み手は上記 convention (特に書き込み面の numeric prefix と immutable history) を期待し、運用実態との mismatch が説明 cost を増やす。

ARCHITECTURE.md (matklad 2021, https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html) との一致軸: state-form / living document / refactor-friendly (= 判断構造の哲学的 core と共有)。

却下理由 (3 軸の差分):

1. domain shift: ARCHITECTURE.md は system structure / component map を扱う surface。判断構造は decision structure / judgment graph を扱う surface。哲学は共有するが domain は別
2. 構造 shift: ARCHITECTURE.md は single doc 形式 (1 ファイルに system 全体の地図)。判断構造は kebab-case <topic>.md の集合 + edge taxonomy による graph 構造。volume scaling と refactor 単位が異なる
3. time-axis treatment: ARCHITECTURE.md は純粋 state-form で十分機能する (system structure の記述は largely additive で contradictions / supersessions が稀。git log だけで履歴が事足りる)。判断構造は decision history が contradictions / supersessions を頻繁に含むため、git log に加えて explicit edge taxonomy (supersedes / conflicts with) を読み出し面に置く必要がある。ゆえに同じ「履歴保持」目標でも mechanism が異なる

そのため「ARCHITECTURE.md philosophy applied to decision domain, structured as a graph rather than a single doc, with time-axis relocated to the read surface via edge taxonomy」が literal に最も近い説明となる。

却下理由:

• 既存 stream への connect を放棄することは説明 cost を増やす (isolated novelty 化、読み手は文脈を持たない)
• vocabulary churn を増やす方向は evolution-decision-structure-write skill が evolution-judgment-graph-* 系を意図的に却下した方針 (#1329 / decision-structure-rename-rationale entry) と整合しない
• 既存 framing (ARCHITECTURE.md) で文脈が成立するため、新語の導入 cost を払う動機がない

本判断は外部説明 layer (industry vocabulary に対する位置取り) のみを扱い、判断構造の内部運用仕様には触れない。docs/Decision-Structure.md (運用 index) と skills/evolution-decision-structure-write/SKILL.md (writer skill) は spec literal を維持する。本 entry の役割は「既に確定した spec を、industry vocabulary でどう外部に説明するか」の軸を追加することに限定される。

本 entry 自体の歩みも 判断構造 の「refactor as normal operation」原則の dogfood である。初版 (PR #1336、SHA c539638) は ARCHITECTURE.md 派生 framing を確立したが「time-axis 否定 / chronological framing 否定」という absolute な表現を採っていた。Master との対話でこれが too strong と判明し (純粋 state-form は将来の変更評価の基線を失い self-defeating になる)、time-axis を「否定」ではなく「書き込み面から読み出し面に relocate」する hybrid framing に refactor した。この journey は git history (PR #1336 → 本 refactor PR) と本セクションの記述で保持される。append-only な version 列ではなく、entry body を直接 refactor し、過去 state を git log で参照する形が 判断構造 の標準運用である。

• Issue: #1335 (初版) / #1337 (本 refactor)
• PR: #1336 (初版マージ) / 本 refactor PR
• depends-on Wiki entry: decision-structure-rename-rationale (リネーム + state 形採用の前提)
• 過去判断: #1011 (a-z prefix 採用、後に supersede) / #1323 / #1324 (a-z prefix drop、時間順構造の relocate) / #1329 / #1330 (Decision Structure リネーム + state 形 shift)
• 哲学的源流 (外部参照): matklad "ARCHITECTURE.md" (2021)