TRUST_v1.md
# TRUST v1.1
## AI時代の認知的検証フレームワーク
## Cognitive Verification Framework for the AI Era
**Version 1.1**
**Created: 2025-12-29**
**Updated: 2026-02-28**
---
## § 0. Executive Summary
```
【197文字で本質を伝える】
AIはすべてを美しく見せる。TRUSTは本物を見抜く力を与える。
AI makes everything look good. TRUST helps you see what's real.
TRUSTは「敵と戦う」フレームワークではない。
「パターンに気づき、含んで超える」ためのフレームワーク。
3つのパターン(Polishing Trap, Sycophancy, Cognitive Comfort Trap)に気づき、
3つの問い(Origin, Resistance, Execution)で検証し、
E1-E6のエビデンス・ピラミッドで現在地を知る。
4つの検証モード(Light/Standard/Full/Cross)でリスクに応じた深度を選ぶ。
気づけば、超えられる。
```
---
## § 1. 位置づけ — 横断的検証層
### フレームワーク体系における位置
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ NOBU'S FRAMEWORK ECOSYSTEM │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ LAYER 0: 原理層(Principles) │
│ メタ原理:含んで超え続ける │
│ │
│ LAYER 1: OS層(Meta-Methods) │
│ ITF / USM / CEM / derivation / AAF / Sovereign AI / ADDE │
│ │
│ ════════════════════════════════════════════════════════════════════════ │
│ ║ TRUST(検証層 / Verification Layer) ║ │
│ ║ ║ │
│ ║ すべてのフレームワーク出力は、TRUSTによる検証を通過すべき ║ │
│ ║ ║ │
│ ║ Evidence Pyramid (E1-E6) | Core Questions | 48-Hour Rule ║ │
│ ════════════════════════════════════════════════════════════════════════ │
│ │
│ LAYER 2: パターン層(Domain Patterns) │
│ TAT / DDM / etc. │
│ │
│ LAYER 3: 実装層(Implementation) │
│ サービス / プロダクト │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
```
### なぜ「横断的検証層」なのか
```
【問題】
AI時代において、すべてのフレームワーク出力は「AI汚染」のリスクを持つ。
ITFの問い → AIが「気持ちいい答え」を生成するリスク
USMの構造 → AIが「美しいが浅い」構造を生成するリスク
CEMの洞察 → AIが「磨かれただけ」の洞察を生成するリスク
derivationの契約 → AIが「正しそうに見える」契約を生成するリスク
AAFの設計 → AIが「論理的だが未検証」の設計を生成するリスク
【解決】
TRUSTを横断的検証層として位置づけ、すべての出力に適用する。
ITF出力 → TRUST検証 → 検証済みITF出力
USM出力 → TRUST検証 → 検証済みUSM出力
...
```
### ITF Q4 "Validation"との関係
```
ITF v2.1の6つの問いの円環:
Q1 Perspective → Q2 Development → Q3 Inquiry →
Q4 Validation → Q5 Decision → Q6 Integration
TRUSTは「Q4 Validation」の深い実装である。
しかし、Q4だけでなく、すべての問いの出力に適用可能。
【関係性】
Q4 Validation = 「十分に見えたか?」という問い
TRUST = Q4の問いに答えるための具体的方法論
Q4が問いを立て、TRUSTが答えを検証する。
```
---
## § 2. 3つのパターン — Patterns to Transcend
### 概要
```
これらは「敵」ではなく、「気づくべきパターン」。
気づけば、超えられる。
超え方: 含んで超える(Include & Transcend)
パターンを否定するのではなく、認識し、より高い次元へ昇華する。
```
### Pattern 1: The Polishing Trap(磨き上げの罠)
```
【定義】
AIが出力を美しく構造化することで、
深さがないまま「完成した」と錯覚させる。
【症状】
・構造化されただけで「論理的」と感じる
・見栄えの良さに満足してしまう
・核心的な問いが欠落したまま進む
【検出】
Origin Question:「この核心は、AIに触れる前から自分の中にあったか?」
No → Polishing Trapの可能性
【超え方】
・AIに触れる前に、自分の直感を言語化する
・AIの出力を「磨き」ではなく「素材」として扱う
・「何が欠けているか」を常に問う
```
### Pattern 2: Sycophancy(サイコファンシー)
```
【定義】
AIが「正しいこと」より「気持ちいいこと」を優先する。
ユーザーの期待に迎合し、批判的視点を提供しない。
【症状】
・AIが常に肯定してくれる
・反論が出てこない
・自分の考えが強化されるだけ
【検出】
Resistance Question:「これは間違っている、と言われたらどう感じるか?」
防御的になる → Sycophancyの兆候
【超え方】
・AIに「最も厳しい批判者」の視点を求める
・自分の仮説に対する反証を積極的に探す
・「気持ちいい答え」を疑う習慣
```
### Pattern 3: Cognitive Comfort Trap(認知的快適性の罠)
```
【定義】
AIが思考の「苦しい部分」を代替することで、
批判的思考の機会が減少する。
【症状】
・「AIが言ったから」が理由になる
・自分で考える前にAIに聞く
・不確実性への耐性が低下する
【検出】
Execution Question:「明日、最小単位で始められるか?」
No → 観念的・抽象的すぎる(AIが思考を代替した可能性)
【超え方】
・AIの出力を「出発点」として使い、自分で深める
・最終判断は必ず自分で行う
・48時間ルールで興奮を冷ます
```
---
## § 3. TRUST Core Questions — 3つの問い
### 概要
```
3つの問いで本質を見抜く。
これらは順番に問うことも、状況に応じて単独で使うこともできる。
```
### Origin Question(起源の問い)
```
「この核心は、AIに触れる前から自分の中にあったか?」
【Yes → 健全】
自分の直感が起点。AIは磨きに使われている。
【No → 要注意】
AIが生成した可能性。Polishing Trapの兆候。
→ 自分の中の「種」を見つけ直す
【Unsure → 探求】
自分の考えの起源を振り返る。
→ 何が自分のもので、何がAIのものかを分離する
【適用例】
新規事業アイデア → このアイデアの核は、AIに聞く前から考えていたか?
キャリア決断 → この方向性は、自分の価値観から来ているか?
技術選定 → この選択の根拠は、自分の経験に基づいているか?
```
### Resistance Question(抵抗の問い)
```
「これは間違っている、と言われたらどう感じるか?」
【冷静に検討できる → 健全】
確証バイアスが少ない。批判を受け入れる準備がある。
【防御的になる → 要注意】
Sycophancyの兆候。AIに肯定されすぎている可能性。
→ 最も厳しい批判者に意見を求める
【Unsure → 探求】
信頼できる人に批判的なフィードバックを求める。
→ 自分の反応を観察する
【適用例】
戦略提案 → この戦略を否定されたら、どう感じるか?
設計判断 → この設計が間違っていると言われたら?
投資判断 → この判断を批判されたら、冷静でいられるか?
```
### Execution Question(実行の問い)
```
「明日、最小単位で始められるか?」
【Yes → 健全】
地に足がついている。具体的な実行可能性がある。
【No → 要注意】
観念的・抽象的すぎる。Cognitive Comfort Trapの兆候。
→ 最小の実行単位を定義する
【Unsure → 探求】
具体的な最初の一歩を考える。
→ 何が障壁になっているかを特定する
【適用例】
プロジェクト計画 → 明日の朝、最初に何をする?
学習目標 → 今日15分でできる最小のステップは?
習慣形成 → 今すぐ始められる最小の行動は?
```
---
## § 4. Evidence Pyramid (E1-E6) — エビデンス・ピラミッド
### 概要
```
【重要】
Evidence Pyramid (E1-E6) は「情報の検証レベル」を示す。
MIRROR Evolution Map (L1-L5.5) の「AI協働成熟度」とは別概念。
E1-E6は医学研究のエビデンス階層を拡張し、
AI時代の新しいカテゴリ(E6)を追加したもの。
```
### 6つのレベル
```
┌─────────────────────────────────────────────────────────────────┐
│ E1: 複数環境で再現・実証 │
│ ≒ メタアナリシス、システマティックレビュー、複数市場A/Bテスト│
│ 信頼度: ★★★★★ │
├─────────────────────────────────────────────────────────────────┤
│ E2: 自己/自社環境で実証 │
│ ≒ 単独RCT、自社A/Bテスト、パイロット結果 │
│ 信頼度: ★★★★☆ │
├─────────────────────────────────────────────────────────────────┤
│ E3: 類似事例・他者経験 │
│ ≒ ケーススタディ、リファレンス顧客、ベストプラクティス │
│ 信頼度: ★★★☆☆ │
├─────────────────────────────────────────────────────────────────┤
│ E4: 理論的妥当性 │
│ ≒ デザインパターン、戦略フレームワーク、論理的一貫性 │
│ 信頼度: ★★☆☆☆ │
├─────────────────────────────────────────────────────────────────┤
│ E5: 経験・直感・専門家意見 │
│ ≒ コンサル助言、シニア判断、暗黙知 │
│ 信頼度: ★☆☆☆☆ │
├─────────────────────────────────────────────────────────────────┤
│ E6: AI出力(未検証)← TRUST独自 │
│ ≒ 該当なし(新カテゴリ) │
│ 信頼度: ☆☆☆☆☆ ← スタート地点 │
└─────────────────────────────────────────────────────────────────┘
```
### E6の特別な位置づけ
```
【なぜE6が必要か】
従来の医学研究階層には「AI出力」というカテゴリがなかった。
しかし、AI時代において、多くの情報は「AI出力(未検証)」から始まる。
E6は:
・検証のスタート地点
・そのままでは意思決定に使用すべきでない
・検証を通じてE5→E4→...と上昇させる必要がある
【E6からの上昇パス】
E6 → E5: 専門家がレビューし、妥当性を確認
E5 → E4: 理論的フレームワークと整合性を確認
E4 → E3: 類似事例を収集し、パターンを確認
E3 → E2: 自社環境でパイロットを実施
E2 → E1: 複数環境で再現性を確認
```
### ギャップ計算
```
【認識レベルと実態レベルのギャップ】
自分が認識しているレベル(Perceived Level)と
実際のエビデンスレベル(Actual Level)の差を計算する。
Gap = Perceived Level - Actual Level
Gap 0-1: 適切な認識
Gap 2-3: 軽度の過大評価 → 注意
Gap 4+: 重度の過大評価 → 48時間ルール推奨
【例】
「この戦略は確実だ」(Perceived: E2)
実際: AIが提案したままで検証なし(Actual: E6)
Gap = 2 - 6 = -4 → 重度の過大評価
→ 48時間ルールを適用し、再評価する
```
---
## § 4b. 検証モード(Verification Modes)
### 概要
```
すべての判断に同じ検証を適用するのは非現実的であり、
過度な懐疑は行動を麻痺させる(§9 警告2)。
検証モードは、リスクに応じた段階的検証を構造化する。
「使う/使わない」の二値ではなく、4段階のグラデーション。
```
### 4つのモード
```
┌─────────────────────────────────────────────────────────────────┐
│ Mode │ Trigger │ Actions │
├──────────────┼───────────────────────┼──────────────────────────┤
│ Light │ 日常判断 │ Origin Questionのみ │
│ │ 可逆的な決定 │ │
├──────────────┼───────────────────────┼──────────────────────────┤
│ Standard │ 通常の業務判断 │ Core Questions 3問 │
│ │ │ + E1-E6判定 │
├──────────────┼───────────────────────┼──────────────────────────┤
│ Full │ 不可逆的・高コストの │ Standard │
│ │ 決定 │ + 48時間ルール │
│ │ │ + 文脈分離(§5b) │
├──────────────┼───────────────────────┼──────────────────────────┤
│ Cross │ 戦略的決定 │ Full │
│ │ 組織方向性 │ + 異なる立場からの再検証 │
└──────────────┴───────────────────────┴──────────────────────────┘
```
### モード選択の判断基準
```
【3つの問いで決める】
1. この決定は可逆か?
可逆 → Light or Standard
不可逆 → Full or Cross
2. 影響範囲はどこまでか?
自分のみ → Light
チーム → Standard
組織全体 → Full or Cross
3. 投資規模はどの程度か?
小(時間 < 1日) → Light
中(時間 1日-1週間、費用あり) → Standard
大(時間 1週間+、大きな費用) → Full
戦略的(方向性を決める) → Cross
```
### モード選択の例
```
【Light】
- Slackの返信文面
- 日常のコード変更
- ドキュメントの軽微修正
【Standard】
- 新機能の設計判断
- 技術スタックの選定
- 採用基準の設定
【Full】
- 事業戦略の決定
- 大規模リファクタリング
- チーム構造の変更
【Cross】
- 事業撤退/参入の判断
- 組織理念の改定
- 長期投資(3年+)の方向性
```
---
## § 5. 48時間ルール
### 概要
```
重要な意思決定は、48時間寝かせてから判断する。
興奮が冷めた後も重要なら、それは本物。
【原理】
・興奮状態での判断はバイアスがかかりやすい
・時間が経つと、本質的でないものは色褪せる
・「本物」は48時間後も輝き続ける
【適用条件】
・エビデンスレベルがE5-E6の場合
・ギャップが4以上の場合
・興奮や強い感情を伴う場合
・取り消し不能な決定の場合
```
### 実践手順
```
【Day 0: 意思決定案を作成】
・「これが正解だ」と感じる
・興奮している自分を認識する
・判断を文書化する(後で見返すため)
【Day 0-2: 寝かせる】
・意識的に考えないようにする
・別のことに取り組む
・無意識に処理させる
【Day 2: 見返す】
・文書化した判断を読み返す
・まだ重要か?興奮は冷めたか?
・新しい視点が生まれたか?
【判断】
・Yes: 実行に移す
・No: 再検討 or 破棄
・Unsure: さらに48時間、または他者に相談
```
---
## § 5b. 文脈分離(Context Separation)
### 概要
```
48時間ルールは「時間分離」——時間を置いて再評価する。
文脈分離は「空間分離」——文脈を変えて再評価する。
時間を置いても、同じ文脈(同じ場所、同じ役割、同じ相手)で
考え直すと、同じ結論に至りやすい。
文脈を変えることで初めて見えるバイアスがある。
```
### 3つの分離軸
```
┌─────────────────────────────────────────────────────────────────┐
│ 軸 │ 方法 │ 検出するバイアス │
├──────────────┼─────────────────────────┼─────────────────────────┤
│ 場所分離 │ 物理的に異なる場所で │ 環境依存バイアス │
│ │ 再評価する │ (オフィス vs 自宅 │
│ │ │ で判断が変わるか) │
├──────────────┼─────────────────────────┼─────────────────────────┤
│ 役割分離 │ 異なる立場から │ 役割固着バイアス │
│ │ 再評価する │ (開発者 vs ユーザー │
│ │ │ で判断が変わるか) │
├──────────────┼─────────────────────────┼─────────────────────────┤
│ 相手分離 │ 異なる相手に │ 社会的バイアス │
│ │ 説明してみる │ (上司 vs 同僚 vs 部下 │
│ │ │ で説明が変わるか) │
└──────────────┴─────────────────────────┴─────────────────────────┘
```
### 実践手順
```
【Step 1: 判断を記録する】
・現在の文脈(場所、役割、相手)を明示する
・その文脈での判断を記録する
【Step 2: 文脈を1つ変える】
・場所、役割、相手のうち1つを変える
・新しい文脈で同じ問いを再評価する
・判断が変わるかどうかを記録する
【Step 3: 差分を分析する】
・判断が変わらない → 文脈非依存(堅牢な判断)
・判断が変わる → 文脈依存(バイアスの可能性)
→ どの文脈が「より正確」かを検討する
```
### 48時間ルールとの組み合わせ
```
Full/Crossモードでは、時間分離と文脈分離を併用する。
Day 0: 判断を記録(文脈も記録)
Day 1: 文脈分離を実施(場所 or 役割 or 相手を変える)
Day 2: 時間分離後に再評価(48時間ルール)
時間分離だけ → 同じ文脈のまま冷静になるだけ
文脈分離だけ → 興奮したまま別角度で見るだけ
両方 → 冷静に、かつ別角度から見る
```
---
## § 6. 各フレームワークへの適用
### ITF × TRUST
```
【適用ポイント】
ITFの各問いの出力に、TRUSTを適用する。
Q1 Perspective出力 → Origin Question
「この視点は、AIに触れる前から持っていたか?」
Q2 Development出力 → Execution Question
「この方向性で、明日から始められるか?」
Q3 Inquiry出力 → Evidence Pyramid
「この深掘りの結果、エビデンスレベルはいくつか?」
Q4 Validation出力 → Core Questions全体
「この検証は十分か?」(TRUST自体がQ4の実装)
Q5 Decision出力 → 48時間ルール
「この決定は、48時間後も有効か?」
Q6 Integration出力 → Resistance Question
「この統合に批判されたら、どう感じるか?」
```
### USM × TRUST
```
【適用ポイント】
USMで構造化した結果に、TRUSTを適用する。
軸の発見 → Origin Question
「この軸は、AIに提案される前から見えていたか?」
構造化の結果 → Evidence Pyramid
「この構造は、E何レベルか?」
普遍的言葉 → Resistance Question
「この言葉選びを批判されたら?」
```
### CEM × TRUST
```
【適用ポイント】
CEMの協働的創発の結果に、TRUSTを適用する。
4象限の移動 → Origin Question
「この移動は、自分の直感が起点か?」
螺旋的上昇 → Evidence Pyramid
「この上昇は実証されているか?」
協働の成果 → Core Questions
「この成果は本物か?磨かれただけか?」
```
### derivation × TRUST
```
【適用ポイント】
derivationの契約と導出に、TRUSTを適用する。
契約定義 → Origin Question
「この契約の本質は、自分が定義したか?」
導出結果 → Evidence Pyramid
「この導出は、E何レベルで検証されたか?」
完成物 → Execution Question
「この完成物で、明日から運用できるか?」
```
### AAF × TRUST
```
【適用ポイント】
AAFの採用設計に、TRUSTを適用する。
摩擦除去 → Evidence Pyramid
「この摩擦分析は、E何レベルか?」
統合設計 → Resistance Question
「この設計を批判されたら?」
価値循環 → 48時間ルール
「この設計は、48時間後も有効か?」
```
---
## § 7. ペルソナ別エントリーポイント
### Creative(創造者)
```
【痛み】
「AIが磨いたアイデア、本当に私のもの?」
「深みがないまま完成した気になってしまう」
【TRUSTの価値】
・Origin Questionで「起源」を確認
・Polishing Trapに気づく
・自分の直感を守りながらAIを活用
【ジャーニー】
1. Origin Question → 自分のアイデアの核を特定
2. Evidence Pyramid → 現在の検証レベルを認識
3. 48時間ルール → 興奮を冷まし、本質を見極める
```
### Strategy(戦略家)
```
【痛み】
「AIが提案した戦略、どこまで信頼できる?」
「論理的に見えるが、検証されていない」
【TRUSTの価値】
・Evidence Pyramid(E1-E6)で検証レベルを可視化
・ギャップ計算で過大評価を検出
・48時間ルールで重要決定を保護
【ジャーニー】
1. Evidence Pyramid → 戦略のE1-E6レベルを判定
2. ギャップ計算 → 認識と実態のズレを検出
3. Resistance Question → 批判への耐性を確認
```
### Technology(技術者)
```
【痛み】
「AIが書いたコード、本当に正しい設計?」
「動くけど、ベストプラクティスか分からない」
【TRUSTの価値】
・Execution Questionで実装可能性を確認
・Evidence Pyramidで技術選定を検証
・Core Questionsで設計判断を検証
【ジャーニー】
1. Execution Question → 明日から実装できるか
2. Evidence Pyramid → 技術選定の根拠レベル
3. Origin Question → この設計は自分の経験に基づくか
```
---
## § 8. 統合使用パターン
### パターンA: AI協働セッション後の検証
```
【状況】
AIと長時間対話し、アイデアや計画がまとまった。
「これでいこう」と思っている。
【TRUST適用】
1. Origin Question
→ 最初の発想は自分から出たか?
→ AIが方向性を変えたポイントはどこか?
2. Evidence Pyramid
→ この計画はE何レベルか?
→ E6のまま進もうとしていないか?
3. 48時間ルール
→ 重要決定なら48時間寝かせる
→ 興奮が冷めても重要か?
【出力】
・検証済みの計画、または
・「まだE6、検証が必要」という認識
```
### パターンB: 戦略的意思決定の検証
```
【状況】
新規事業、大型投資、組織変更など、
取り消し困難な決定を行おうとしている。
【TRUST適用】
1. Evidence Pyramid
→ 各根拠のエビデンスレベルを判定
→ E5-E6が多い場合は検証を追加
2. Resistance Question
→ この決定を否定されたら、どう感じるか?
→ 防御的になるなら、確証バイアスの可能性
3. 48時間ルール
→ 必ず適用
→ ステークホルダーにも共有
【出力】
・エビデンスレベル付きの意思決定文書
・48時間後の再評価結果
```
### パターンC: フレームワーク出力の品質保証
```
【状況】
ITF/USM/CEM/derivation/AAFを使って成果物を作成した。
品質を確認したい。
【TRUST適用】
1. Origin Question
→ フレームワークの入力は自分のものか?
→ AIに誘導されていないか?
2. Evidence Pyramid
→ 成果物のエビデンスレベルは?
→ 検証が必要な箇所はどこか?
3. Execution Question
→ この成果物で、明日から行動できるか?
→ 抽象的すぎないか?
【出力】
・検証済みの成果物、または
・「追加検証が必要」という認識と具体的アクション
```
---
## § 9. 三つの警告
### 警告1: TRUST自体のサイコファンシー
```
【リスク】
TRUSTを使うこと自体が「検証した気分」を与え、
実際の検証を怠る可能性がある。
【対策】
・TRUSTは「問い」を立てるツール
・問いに「答える」のは別のプロセス
・「TRUSTを使ったから安心」とは思わない
```
### 警告2: 過度な懐疑
```
【リスク】
すべてを疑いすぎて、行動が遅れる可能性がある。
「完璧な検証」を求めて、永遠に決定できない。
【対策】
・E1-E2を求めるのは重要決定のみ
・日常的な判断はE3-E4で十分な場合も
・「十分な検証」の基準を状況に応じて設定
```
### 警告3: 形式的適用
```
【リスク】
TRUSTを形式的に適用し、本質的な検証を行わない。
チェックリストを埋めるだけの作業になる。
【対策】
・各問いに「本気で」答える
・不快な答えこそ重要
・「気づき」を目的とし、「通過」を目的としない
```
---
## § 10. Quick Reference
### 30秒で使う
```
┌─────────────────────────────────────────────────────────────────┐
│ TRUST Quick │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 【モード選択】 │
│ │
│ Light: 日常判断 → Origin Questionのみ │
│ Standard: 業務判断 → 3問 + E1-E6 │
│ Full: 重要決定 → Standard + 48h + 文脈分離 │
│ Cross: 戦略的決定 → Full + 異なる立場から再検証 │
│ │
│ 【3つの問い】 │
│ │
│ 1. Origin: AIに触れる前から、自分の中にあったか? │
│ 2. Resistance: 批判されたら、どう感じるか? │
│ 3. Execution: 明日、最小単位で始められるか? │
│ │
│ 【E1-E6】 │
│ │
│ E1 複数環境で実証 | E2 自社環境で実証 | E3 類似事例 │
│ E4 理論的妥当性 | E5 経験・直感 | E6 AI出力(未検証) │
│ │
│ 【48時間ルール + 文脈分離】 │
│ │
│ 重要決定 → 48時間寝かせる(時間分離) │
│ → 場所/役割/相手を変えて再評価(文脈分離) │
│ → まだ重要なら実行 │
│ │
└─────────────────────────────────────────────────────────────────┘
```
### 診断フロー
```
1. 今、判断しようとしていることは何か?
→ 明確に言語化する
2. モード選択(§4b)
→ 可逆性・影響範囲・投資規模で判断
→ Light / Standard / Full / Cross
3. Origin Question
→ Yes: 次へ / No: 起源を探る
4. Resistance Question(Standard以上)
→ 冷静: 次へ / 防御的: 批判者を探す
5. Execution Question(Standard以上)
→ Yes: 次へ / No: 最小単位を定義
6. Evidence Pyramid(Standard以上)
→ E1-E4: 進める / E5-E6: 48時間ルール
7. 48時間ルール + 文脈分離(Full以上)
→ 時間分離: 寝かせて再評価
→ 文脈分離: 場所/役割/相手を変えて再評価
8. 異なる立場からの再検証(Crossのみ)
→ 利害関係者、批判者、新参者の視点
```
---
## § 11. 参照
### 内部参照
```
Integrated/
├── ITF_v2_1.md # Q4 Validationの親フレームワーク
├── USM_v1.md # 構造化の方法論
├── CEM_v1.md # 協働的創発
├── AAF_v1.md # 採用設計
└── Framework_Integration_Map.md # 全体統合マップ
```
### 実装
```
work/trust/ # TRUSTプロダクト
├── CLAUDE.md # TRUST Agent定義
├── docs/TRUST_v1_Design.md # 設計ドキュメント
└── src/app/ # Webアプリケーション
├── page.tsx # ホーム
├── card/ # 30秒カード
├── quick-reference/ # クイックリファレンス
└── diagnostic/ # 診断ツール
URL: trust.seehub.org
```
### 外部参照
```
・医学研究のエビデンス階層(Evidence-Based Medicine)
・認知バイアス研究
・AI Safety / AI Alignment研究
・行動経済学(48時間ルールの根拠)
```
---
**Document Information**
```yaml
Title: TRUST v1.1
Subtitle: AI時代の認知的検証フレームワーク
Version: 1.1
Created: 2025-12-29
Updated: 2026-02-28
Status: Active & Evolving
位置づけ: 横断的検証層(Verification Layer)
親フレームワーク: ITF v2.1 Q4 Validation
実装: trust.seehub.org
変更履歴:
v1.1 (2026-02-28): 検証モード・文脈分離の追加
- §4b 検証モード(Light/Standard/Full/Cross): リスクに応じた段階的検証
- §5b 文脈分離(Context Separation): 48時間ルールの補完
- §10 Quick Reference更新: モード選択・文脈分離を追加
- 動機: 検証の二値性(使う/使わない)とバイアス低減の時間軸偏重を解消
v1.0 (2025-12-29): 初版作成
- 横断的検証層としての位置づけを確立
- E1-E6 Evidence Pyramidを定義
- 各フレームワークへの適用方法を明示
```
---
_AIはすべてを美しく見せる_
_TRUSTは本物を見抜く力を与える_
_気づき、含んで、超える_
_Notice, include, and transcend_
_これがTRUSTである_ 🔍