clarity-gate

Clarity Gate v2.1

目的： ドキュメントが RAG ナレッジベースに取り込まれる前に、認識上の品質を確保する事前取り込み検証システムです。Clarity Gate Format Specification v2.1 に準拠した Clarity-Gated Documents（CGD）を生成します。

中心となる問い：「別の LLM がこのドキュメントを読んだとき、仮定を事実と誤認するでしょうか？」

基本原則： 「検出は現状を見つけ、強制はあるべき姿を確実にします。実際には、欠けている不確実性マーカーを、確信に満ちた幻覚になる前に見つけます。」

---

v2.1 の新機能

機能	説明
主張の完了ステータス	フィールドの有無によって PENDING/VERIFIED を判定します（明示的なステータスフィールドなし）
Source フィールドの意味	対応が必要な情報源（PENDING）と、見つかった内容（VERIFIED）
Claim ID 形式のガイダンス	ハッシュベースの ID を推奨し、大規模利用時の衝突を分析
本文構造の要件	主張がある場合、HITL Verification Record セクションが必須
新しい検証コード	E-ST10、W-ST11、W-HC01、W-HC02、E-SC06（FORMAT_SPEC）；E-TB01-07（SOT 検証）
バンドル済みスクリプト	決定論的な計算を行う claim_id.py と document_hash.py

---

仕様

このスキルは、以下を実装し、参照します。

仕様	バージョン	場所
Clarity Gate Format（統合版）	v2.1	docs/CLARITY_GATE_FORMAT_SPEC.md

注： v2.0 では CGD と SOT が単一の .cgd.md 形式に統合されています。SOT は tier: ブロックを任意で含められる CGD になりました。

---

検証コード

Clarity Gate は、FORMAT_SPEC v2.1 に基づく構造および意味のチェック用に検証コードを定義しています。

HITL Claim の検証（§1.3.2-1.3.3）

コード	チェック項目	重大度
W-HC01	confirmed-by / confirmed-date フィールドが一部のみ存在する	警告
W-HC02	情報源が曖昧（例：「industry reports」、「TBD」）	警告
E-SC06	hitl-claims 構造のスキーマエラー	エラー

本文構造（§1.2.1）

コード	チェック項目	重大度
E-ST10	主張がある場合に ## HITL Verification Record がない	エラー
W-ST11	表の行数が hitl-claims の件数と一致しない	警告

SOT 表の検証（§3.1）

コード	チェック項目	重大度
E-TB01	## Verified Claims セクションがない	エラー
E-TB02	表にデータ行がない	エラー
E-TB03	必須の列がない	エラー
E-TB04	列の順序が誤っている	エラー
E-TB05	必須列のセルが空である	エラー
E-TB06	Verified 列の日付形式が無効	エラー
E-TB07	Verified の日付が未来の日付（24 時間の猶予を超過）	エラー

注： RFC-001（明確化文書）で追加の検証コードが定義される場合がありますが、規範的な FORMAT_SPEC には含まれません。

---

バンドル済みスクリプト

このスキルには、FORMAT_SPEC に基づく決定論的な計算を行う Python スクリプトが含まれています。

scripts/claim_id.py

HITL の追跡用に、安定したハッシュベースの claim ID を計算します（§1.3.4 に準拠）。

# Generate claim ID
python scripts/claim_id.py "Base price is $99/mo" "api-pricing/1"
# Output: claim-75fb137a

# Run test vectors
python scripts/claim_id.py --test

アルゴリズム：

1. テキストを正規化します（前後の空白を削除し、連続する空白をまとめる）
2. パイプ区切り文字を使って、テキストと場所を連結します
3. SHA-256 ハッシュを計算し、先頭の 8 桁の 16 進数文字を取得します
4. "claim-" を先頭に付けます

テストベクトル：

• claim_id("Base price is $99/mo", "api-pricing/1") → claim-75fb137a
• claim_id("The API supports GraphQL", "features/1") → claim-eb357742

scripts/document_hash.py

完全な正規化を行い、FORMAT_SPEC §2.2-2.4に従ってドキュメントのSHA-256ハッシュを計算します。

# Compute hash
python scripts/document_hash.py my-doc.cgd.md
# Output: 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730

# Verify existing hash
python scripts/document_hash.py --verify my-doc.cgd.md
# Output: PASS: Hash verified: 7d865e...

# Run normalization tests
python scripts/document_hash.py --test

アルゴリズム（§2.2-2.4に準拠）：

1. 開始 ---\n と ``
2. YAMLフロントマターから document-sha256 行のみを削除します（複数行の継続行にも対応）。
3. 正規化します。
   • 各行末の空白を削除します。
   • 3つ以上連続する改行を2つにまとめます。
   • 最終改行を正規化します（LFをちょうど1つ）。
   • UTF-8 NFC正規化を行います。
4. SHA-256を計算します。

クロスプラットフォームでの正規化：

• BOMがあれば削除します。
• CRLFをLFに変換します（Windows）。
• CRをLFに変換します（旧Mac）。
• 境界を検出します（CGD構造外のコンテンツに対するハッシュ計算を防止します）。
• 空白の差異があっても同じハッシュになります（プラットフォーム間で決定的です）。

---

重要な違い

UnScientifyやHedgeHunter（CoNLL-2010）などの既存ツールは、テキスト内にすでに存在する不確実性を示す表現を検出します（「不確実性が表現されているか？」）。

Clarity Gateは、認識論的に必要な箇所で不確実性を示す表現の使用を強制します（「不確実性を表現すべきなのに、表現されていないか？」）。

ツールの種類	質問	例
検出	「このテキストにはヘッジ表現が含まれていますか？」	UnScientify/HedgeHunterは「may」「possibly」を検出します。
強制	「この主張にはヘッジ表現が必要なのに、使われていませんか？」	Clarity Gateは「収益は5000万ドルになります」にフラグを立てます。

---

重大な制約

Clarity Gateが検証するのは形式であり、真偽ではありません。

このスキルは、主張に不確実性が適切に示されているかを確認します。主張が実際に真であるかは検証できません。

リスク： LLMがドキュメントに事実を幻覚で追加し、その誤った主張に出典マーカーを付けることで、Clarity Gateの検査を「パス」する可能性があります。

解決策： PASSを宣言する前に、HITL（Human-In-The-Loop）による検証が必須です。

---

使用するタイミング

• RAGシステムにドキュメントを取り込む前
• 他のAIシステムとドキュメントを共有する前
• 仕様書、状態ドキュメント、方法論の説明を書いた後
• ドキュメントに予測、推定、仮説が含まれる場合
• 検証されていない主張を公開する前
• LLMのセッション間でドキュメントを引き継ぐ場合

---

9つの検証ポイント

仕様スイートとの関係

9つの検証ポイントは意味的なレビュー、つまり判断（人間またはAI）を必要とするコンテンツ品質のチェックを導きます。「この主張にはヘッジ表現が必要か？」「これらの数値に一貫性があるか？」といった問いに答えます。

レビューが完了したら、CLARITY_GATE_FORMAT_SPEC.mdに準拠するCGDファイルを出力します。CLARITY_GATE_FORMAT_SPEC.mdのC/Sルールが検証するのはファイル構造であり、意味的な内容ではありません。

関連性：

1. 意味的な検出結果（9つのポイント）によって、どのような問題があるかを判断します。
2. 問題はCGDの状態フィールド（clarity-status、hitl-status、hitl-pending-count）に記録します。
3. 状態の一貫性は構造ルール（C7-C10）によって強制されます。

例：ポイント5（データの一貫性）で数値の不一致が見つかった場合、解決するまでclarity-status: UNCLEARとします。するとルールC7により、UNCLEARのままREVIEWEDと宣言できないことが保証されます。

---

認識に関するチェック（主な焦点：ポイント1～4）

1. 仮説と事実のラベル付け すべての主張に、検証済みか仮説かを明確に示す必要があります。

不合格	合格
「当社のアーキテクチャは競合他社を上回ります」	「当社のアーキテクチャは競合他社を上回ります［表3のベンチマークデータ］」
「モデルは40％の改善を達成します」	「モデルは40％の改善を達成します［データセットXで測定］」

修正方法： 「予測：」「仮説：」「未検証：」「（推定）」「～」「？」などのマーカーを追加します。

---

2. 不確実性マーカーの徹底 将来に関する記述には、限定表現が必要です。

不合格	合格
「第4四半期までに売上高は5,000万ドルになります」	「第4四半期までに売上高は5,000万ドルになると予測されています」
「この機能は解約率を下げます」	「この機能は解約率を下げると見込まれています」

修正方法： 「予測される」「推定される」「見込まれる」「～するよう設計されている」「～を目的としている」を追加します。

---

3. 前提条件の明示 解釈に影響する暗黙の前提条件は、明示する必要があります。

不合格	合格
「システムは線形にスケールします」	「システムは線形にスケールします［同時接続ユーザー数が1000人未満の場合］」
「応答時間は50msです」	「応答時間は50msです［標準負荷条件下］」

修正方法： 括弧付きで条件を追加します：「［Xを前提とする］」「［Yの条件下で］」「［Zの場合］」

---

4. 検証されていない、権威があるように見えるデータ 具体的な割合やチェックマークを含む表は、測定済みのデータのように見えます。

危険信号： 出典なしで具体的な数値（89％、95％、100％）を含む表

修正方法： 数値に「（推測）」「（推定）」「？」を追加します。明示的な警告「予測値 — 未測定」を追加します。

---

データ品質チェック（補完的な項目：ポイント5～7）

5. データの一貫性 ドキュメント内で矛盾する数値、日付、事実がないか確認します。

危険信号： あるセクションでは「500人のユーザー」、別のセクションでは「750人のユーザー」と記載されている

修正方法： 矛盾を解消するか、説明を添えて相違点を明示します。

---

6. 暗黙の因果関係 証拠なしに因果関係を示唆する主張です。

危険信号： 「短いプロンプトは応答品質を高めます」（もっともらしいものの、実証されていない）

修正方法： 仮説として言い換えます：「短いプロンプトは応答品質を高める可能性があります（仮説、未検証）」

---

7. 将来の状態を現在の状態として記述 計画中または期待される成果を、すでに達成済みであるかのように記述することです。

危険信号： 「システムは毎秒10,000件のリクエストを処理します」（まだ構築されていない場合）

修正方法： 未来形または条件付きの表現を使います：「システムは～を処理するよう設計されています」または「目標：毎秒10,000リクエスト」

---

検証の振り分け（ポイント8～9）

8. 時系列の整合性 ドキュメントの日付とタイムスタンプは、内部的に一貫し、妥当である必要があります。

不合格	合格
「最終更新日：2024年12月」（現在が2026年の場合）	「最終更新日：2026年1月」
v1.0.0 の日付が2024-12-23、v1.1.0 の日付が2024-12-20	バージョンが時系列順に並んでいる

サブチェック：

1. ドキュメントの日付と現在の日付
2. 内部の時系列（バージョン、イベントの順序）
3. 参照情報の鮮度（「現在」「今」「今日」に関する主張）

修正方法： 日付を更新し、「[日付]時点」の限定表現を追加し、古くなった主張にフラグを付けます。

---

9. 外部から検証可能な主張 ファクトチェック可能な具体的な数値には、検証が必要であることを示します。

種類	例	リスク
価格	「1回の呼び出しにつき約0.005ドルかかります」	API料金は変更される可能性があります
統計	「論文には平均15～30個の数式が含まれます」	大幅に誤っている可能性があります
比率・割合	「研究者の40％がXを使用しています」	引用が必要です
競合に関する主張	「Yを提供する競合他社はいません」	古い情報である可能性があります

修正方法：

1. 日付を添えて出典を追加する
2. 不確実性マーカーを追加する
3. HITL または外部検索に回す
4. 一般化する（「0.005ドル」の代わりに「低コスト」）

---

検証の階層

Claim Extracted --> Does Source of Truth Exist?
                           |
           +---------------+---------------+
           YES                             NO
           |                               |
   Tier 1: Automated              Tier 2: HITL
   Consistency & Verification     Two-Round Verification
           |                               |
   PASS / BLOCK                   Round A → Round B → APPROVE / REJECT

ティア1：自動検証

A. 内部整合性

• 図と本文の矛盾
• 要約と本文の不一致
• 表と文章の矛盾
• 数値の一貫性

B. 外部検証（拡張インターフェース）

• 構造化された情報源への、ユーザー提供のコネクター
• 財務システム、Git コミット、CRM など

Tier 2：2ラウンドのHITL検証 — 必須

ラウンドA：派生データの確認

• セッション内で見つかったソースに基づく主張
• 人間が確認するのは解釈であり、真偽ではありません

ラウンドB：真のHITL検証

• 実際の検証が必要な主張
• ソースが見つからない場合、人間自身のデータ、外挿

---

CGDの出力形式

Clarity-Gated Documentを作成する際は、CLARITY_GATE_FORMAT_SPEC.md v2.1に従い、次の形式を使用してください。

---
clarity-gate-version: 2.1
processed-date: 2026-01-12
processed-by: Claude + Human Review
clarity-status: CLEAR
hitl-status: REVIEWED
hitl-pending-count: 0
points-passed: 1-9
rag-ingestable: true          # computed by validator - do not set manually
document-sha256: 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730
hitl-claims:
  - id: claim-75fb137a
    text: "Revenue projection is $50M"
    value: "$50M"
    source: "Q3 planning doc"
    location: "revenue-projections/1"
    round: B
    confirmed-by: Francesco
    confirmed-date: 2026-01-12
---

# Document Title

[Document body with epistemic markers applied]

Claims like "Revenue will be $50M" become "Revenue is **projected** to be $50M *(unverified projection)*"

---

## HITL Verification Record

### Round A: Derived Data Confirmation
- Claim 1 (source) ✓
- Claim 2 (source) ✓

### Round B: True HITL Verification
| # | Claim | Status | Verified By | Date |
|---|-------|--------|-------------|------|
| 1 | [claim] | ✓ Confirmed | [name] | [date] |


Clarity Gate: CLEAR | REVIEWED

CGDの必須要素（仕様に基づく）：

• すべての必須フィールドを含むYAMLフロントマター：
  • clarity-gate-version — ツールのバージョン（「v」接頭辞なし）
  • processed-date — YYYY-MM-DD形式
  • processed-by — 処理担当者名
  • clarity-status — CLEARまたはUNCLEAR
  • hitl-status — PENDING、REVIEWED、またはREVIEWED_WITH_EXCEPTIONS
  • hitl-pending-count — 0以上の整数
  • points-passed — 例：1-9または1-4,7,9
  • hitl-claims — 検証済みの主張のリスト（空の[]でも可）
• 終了マーカー（HTMLコメント＋ステータス行）：

  
  Clarity Gate: <clarity-status> | <hitl-status>
  

• HITL検証記録（ステータスがREVIEWEDの場合）

任意／計算フィールド：

• rag-ingestable — バリデーターが計算するフィールドで、手動では設定しません。除外ブロックがなく、CLEAR | REVIEWEDの場合にのみtrueになります。
• document-sha256 — 必須。整合性検証用の64文字の小文字16進数ハッシュです。計算ルールについては仕様の§2を参照してください。
• exclusions-coverage — 任意。除外ブロック内にある本文の割合（0.0～1.0）です。

エスケープ方法： *(estimated)*などのマーカーを解析させずに記述するには、バッククォートで囲みます：`*(estimated)*`

主張の完了ステータス（v2.1）

主張の検証ステータスは、明示的なステータスフィールドではなく、フィールドの存在によって決まります。

状態	confirmed-by	confirmed-date	意味
PENDING	なし	なし	人間による検証待ち
VERIFIED	あり	あり	人間による確認済み
(無効)	あり	なし	W-HC01：フィールドが一部のみ
(無効)	なし	あり	W-HC01：フィールドが一部のみ

明示的なステータスフィールドがない理由： フィールドの存在自体が強制力を持つため、誰がいつ確認したかを記載せずに、誤ってステータスを設定することはできません。

ソースフィールドの意味（v2.1）

sourceフィールドの意味は、主張の状態によって変わります。

状態	sourceの内容	例
PENDING	検証先（具体的な行動）	"Check Q3 planning doc"
VERIFIED	見つかった情報（証拠）	"Q3 planning doc, page 12"

曖昧なソースの検出（W-HC02）： "industry reports"、"research"、"TBD"などのソースは警告の対象になります。

主張IDの形式（v2.1）

一般的なパターン： claim-[a-z0-9._-]{1,64}（英数字、ピリオド、アンダースコア、ハイフン）

方式	パターン	例	用途
ハッシュベース（推奨）	claim-[a-f0-9]{8,}	claim-75fb137a	決定論的で、衝突しにくい
連番	claim-[0-9]+	claim-1、claim-2	シンプルなドキュメント
意味ベース	claim-[a-z0-9-]+	claim-revenue-q3	人間が理解しやすい

衝突確率： 8文字の16進数IDを1,000件の主張に使用した場合、約0.012％です。主張が1,000件を超える場合は、12文字以上の16進数を使用してください。

推奨： 一貫性と衝突耐性を高めるため、scripts/claim_id.pyで生成したハッシュベースのIDを使用してください。

---

除外ブロック

内容を解決できない場合（対象分野の専門家がいない、レガシーの文章であるなど）は、曖昧なままにせず、除外としてマークしてください。

Legacy authentication details that require SME review...

ルール：

• IDは次のパターンに一致する必要があります：[A-Za-z0-9][A-Za-z0-9._-]{0,63}
• 入れ子やブロックの重複は禁止
• 各IDは1回のみ使用
• hitl-status: REVIEWED_WITH_EXCEPTIONSが必要
• フロントマターにexceptions-reasonとexceptions-idsを記載する必要があります

重要： 除外ブロックを含むドキュメントは、RAGに取り込み可能ではありません。一部のみ取り込むこともなく、ドキュメント全体が拒否されます。

完全なルールについては、CLARITY_GATE_FORMAT_SPEC.md §4を参照してください。

---

SOT の検証

Source of Truth ファイルを検証する際、このスキルは フォーマット準拠（CLARITY_GATE_FORMAT_SPEC.md に従います）とコンテンツ品質（9 項目）の両方をチェックします。

フォーマット準拠（構造ルール）

SOT ドキュメントは tier: ブロックを含む CGD です。有効なテーブルを含む ## Verified Claims セクションが必要です。

コード	チェック項目	重大度
E-TB01	## Verified Claims セクションがない	ERROR
E-TB02	テーブルにデータ行がない	ERROR
E-TB03	必須列（Claim、Value、Source、Verified）がない	ERROR
E-TB04	列の順序が正しくない（Claim が最初にない、または Verified が最後にない）	ERROR
E-TB05	必須列に空のセルがある	ERROR
E-TB06	Verified 列の日付形式が無効	ERROR
E-TB07	Verified の日付が未来（24 時間の猶予を超過）	ERROR

コンテンツ品質（9 項目）

9 つの検証項目は SOT コンテンツに適用されます。

項目	SOT での適用
1-4	## Verified Claims 内の主張が実際に検証済みかチェックします
5	テーブル間に矛盾する値がないかチェックします
6	主張が裏付けのない因果関係を示唆していないかチェックします
7	テーブルが未来のことを現在の事実として記載していないかチェックします
8	日付に時系列上の整合性があるかチェックします
9	外部チェックが必要な具体的な数値にフラグを付けます

SOT 固有の要件

• Tier ブロックが必須： SOT は level、owner、version、promoted-date、promoted-by を含む tier: ブロックを備えた CGD です
• 構造化された主張テーブル： ## Verified Claims セクションに次の列を含めます：Claim、Value、Source、Verified
• 除外範囲外のテーブル： 検証済みの主張テーブルを除外ブロック内に配置してはいけません
• 鮮度マーカー： コンテンツ内で [STABLE]、[CHECK]、[VOLATILE]、[SNAPSHOT] を使用します
  • [STABLE] — 再確認せずに引用しても安全です
  • [CHECK] — 引用する前に検証してください
  • [VOLATILE] — 頻繁に変化するため、必ず検証してください
  • [SNAPSHOT] — 特定時点のデータです。引用する際は日付を含めてください

---

出力形式

Clarity Gate の実行後、次のように報告します。

## Clarity Gate Results

**Document:** [filename]
**Issues Found:** [number]

### Critical (will cause hallucination)
- [issue + location + fix]

### Warning (could cause equivocation)  
- [issue + location + fix]

### Temporal (date/time issues)
- [issue + location + fix]

### Externally Verifiable Claims
| # | Claim | Type | Suggested Verification |
|---|-------|------|------------------------|
| 1 | [claim] | Pricing | [where to verify] |

---

## Round A: Derived Data Confirmation

- [claim] ([source])

Reply "confirmed" or flag any I misread.

---

## Round B: HITL Verification Required

| # | Claim | Why HITL Needed | Human Confirms |
|---|-------|-----------------|----------------|
| 1 | [claim] | [reason] | [ ] True / [ ] False |

---

**Would you like me to produce an annotated CGD version?**

---

**Verdict:** PENDING CONFIRMATION

---

重大度レベル

レベル	定義	対応
CRITICAL	LLM が仮説を事実として扱う可能性が高い	使用前に必ず修正
WARNING	LLM が誤解する可能性がある	修正を推奨
TEMPORAL	日時の不整合が検出された	検証して更新
VERIFIABLE	ファクトチェック可能な具体的な主張	HITL または外部検索に回す
ROUND A	目撃されたソースから導出	簡易確認
ROUND B	真の検証が必要	確認なしでは合格できません
PASS	明確に記載され、曖昧さがなく、検証済み	対応不要

---

クイックスキャンチェックリスト

パターン	対応
具体的なパーセンテージ（89%、73%）	ソースを追加するか、推定値と明記します
比較テーブル	「PROJECTED」ヘッダーを追加します
「Achieves」、「delivers」、「provides」	検証されていない場合は「designed to」、「intended to」を使用します
チェックマーク	確認済みであることを検証します
「100%」に関する記述	ほぼ必ず条件を明確にする必要があります
「Last Updated: [date]」	現在の日付と照合します
日付を伴うバージョン番号	時系列の順序を検証します
「$X.XX」または「~$X」（価格）	外部検証が必要な項目としてフラグを付けます
「averages」、「typically」	ソース／引用が必要な項目としてフラグを付けます
競合他社の機能に関する主張	外部検証が必要な項目としてフラグを付けます

---

このスキルが行わないこと

• ドキュメントの種類を分類しません（その場合は Stream Coding を使用します）
• ドキュメントを再構成しません
• ディープリンクや参照を追加しません
• 文章の品質を評価しません
• 事実の正確性を自律的にチェックしません（HITL が必要です）

---

関連プロジェクト

プロジェクト	目的	URL
Source of Truth Creator	認識論的に適切なドキュメントを作成	github.com/frmoretto/source-of-truth-creator
Stream Coding	ドキュメントファーストの方法論	github.com/frmoretto/stream-coding
ArXiParse	科学論文の検証	arxiparse.org

---

変更履歴

v2.1.3 (2026-03-02)

• FIXED: document_hash.py が FORMAT_SPEC §2.1-2.4 への完全準拠を実装しました
• FIXED: フェンス対応の終端マーカー検出（§2.3/§8.5 に基づく Quine Protection）
• FIXED: 4 つのデプロイコピーすべてを単一の正規実装に統合
• ADDED: canonicalize() 関数: 末尾空白の除去、改行の集約、NFC 正規化
• ADDED: 複数行継続をサポートする YAML 対応の document-sha256 削除（§2.2）
• ADDED: フェンス追跡のテストベクター（新規 7 テスト、合計 15）
• ADDED: Claim Completion Status のセマンティクス（フィールドの有無による PENDING/VERIFIED）
• ADDED: Source Field Semantics（実行可能な内容 vs. 発見された内容）
• ADDED: 衝突分析を伴う Claim ID 形式のガイダンス
• ADDED: Body Structure Requirements（クレームが存在する場合は HITL Verification Record を必須）
• ADDED: 新しい検証コード: E-ST10、W-ST11、W-HC01、W-HC02、E-SC06（FORMAT_SPEC §1.2-1.3）
• ADDED: 同梱スクリプト: claim_id.py、document_hash.py
• UPDATED: FORMAT_SPEC v2.1 への参照
• UPDATED: CGD 出力例をバージョン 2.1 に更新

v2.0.0 (2026-01-13)

• ADDED: agentskills.io 準拠の YAML フロントマター
• ADDED: Clarity Gate Format Specification v2.0 準拠（CGD/SOT の統合）
• ADDED: E-TB* エラーコードによる SOT 検証サポート
• ADDED: 検証ルールのマッピング（9 ポイント → ルールコード）
• ADDED: `` マーカー付きの CGD 出力形式テンプレート
• ADDED: Quine Protection の注記（§2.3 フェンス対応マーカー検出）
• ADDED: Redacted Export 機能（§8.11）
• UPDATED: hitl-claims 形式を v2.0 スキーマに更新（id、text、value、source、location、round）
• UPDATED: 終端マーカー形式を HTML コメントスタイルに更新
• UPDATED: 統合形式仕様 v2.0（単一の .cgd.md 拡張子）
• RESTRUCTURED: マルチプラットフォームのスキルディスカバリ向けに再構成

v1.6 (2025-12-31)

• 2 ラウンド HITL 検証システムを追加
• ラウンド A: 派生データの確認
• ラウンド B: 真の HITL 検証

v1.5 (2025-12-28)

• ポイント 8 を追加: 時間的整合性
• ポイント 9 を追加: 外部から検証可能なクレーム

v1.4 (2025-12-23)

• CGD アノテーション出力モードを追加

v1.3 (2025-12-21)

• ポイントを Epistemic（1-4）と Data Quality（5-7）に再構成

v1.2 (2025-12-21)

• Source of Truth リクエストステップを追加

v1.1 (2025-12-21)

• HITL Fact Verification（必須）を追加

v1.0 (2025-11)

• 6 ポイント検証を備えた初回リリース

---

Version: 2.1.3 Spec Version: 2.1 Author: Francesco Marinoni Moretto License: CC-BY-4.0