Skip to content

decision structure industry positioning

Jump to bottom
Claude Lin & Lay edited this page May 21, 2026 · 2 revisions

判断構造の industry 既存 vocabulary 上の位置取り — ARCHITECTURE.md-derived framing

Question

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

Current resolution

判断構造は ARCHITECTURE.md (matklad 2021) 哲学を decision domain に graph 構造として拡張した形 として位置付ける。ADR variant としては説明しない。

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

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

ADR (Architecture Decision Record) の派生としては説明しない。両者は decision-focus surface を共有するが、ADR の convention (chronological / append-only / immutable-history) と判断構造の運用方針が衝突し、ADR の name で呼ぶと読み手の期待値が mismatch する。

Edges

背景

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 のみで連続的に拡張できることが判明した。

制約

  • 判断構造の運用方針 (state-form / 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) を読み手が想定し、現行 spec と衝突する
  • ARCHITECTURE.md とも完全一致しない (single doc vs graph 構造の差) ため、「ARCHITECTURE.md そのもの」とも呼ばない。「ARCHITECTURE.md philosophy applied to decision domain」が最も literal な説明

結論

採用案: ARCHITECTURE.md-derived framing (上記 Current resolution)

却下案 + 理由:

却下案 A: ADR (Architecture Decision Record) variant として説明

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

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

  1. chronological vs state-form: ADR は時間順 ordering + numeric prefix を convention とする。判断構造は #1324 で a-z prefix を drop し時間軸を否定し、現在 state を主語とする
  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 を期待し、運用実態との mismatch が説明 cost を増やす。

却下案 B: ARCHITECTURE.md そのものとして説明

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

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

  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 単位が異なる

そのため「ARCHITECTURE.md philosophy applied to decision domain, structured as a graph rather than a single doc」が literal に最も近い説明となる。

却下案 C: 第三 vocabulary を新規導入 (例: "Judgment Graph" "Decision Map" のような造語)

却下理由:

  • 既存 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 でどう外部に説明するか」の軸を追加することに限定される。

関連

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

Li+ Wiki

この Wiki は、Li+ に基づく開発・運用を支えるための情報整理空間です。

ページ構成について

要求仕様書（数字：1–9）

数字で始まるページは、 Li+プログラムの各レイヤーの仕様を定義するページです。

  • 要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する
  • 実装前に作成または更新する
  • issue群から採用された要件を集約する

これらのページは 安定性と一貫性を重視して管理されます。

参考文書（アルファベット：A–）

アルファベットで始まるページは、 Li+の構想・設定・導入手順などの参照用ページです。

  • 設計思想・背景
  • 設定リファレンス・インストール手順

これらのページは 必要に応じて更新・拡張されます。

rules/, skills/, adapter / update 各ファイル

リポジトリ内の rules/**/*.md（L1–L4 の常時ロード分、subdir 含む）、skills/**/SKILL.md（トリガー起動分）、adapter/claude/CLAUDE.md、adapter/claude/hooks-settings.md、adapter/claude/hooks/*.sh、adapter/codex/AGENTS.md、およびルート直下の Li+config.md、Li+update.md は、 AIやランタイムが直接読む実行用プログラム / 定義ファイルです。

  • docs/ は人間向けの仕様書・要求仕様・手順書
  • rules/, skills/ および adapter / update は実行時に読み込まれる本体

両者は対応しているが、役割は同じではない。

Home | 1. Model | 2. Evolution | 3. Task | 4. Operations | A. Concept

要求仕様書 (1-6)

参考文書 (A-K)

判断構造

Clone this wiki locally