03. ROM Core Spec

1. Purpose

Relation-Oriented Markdown（ROM）の最小文法、正規化、および検証契約を定義する。特に、非決定的な記述順序を排除し、決定論的なハッシュ不変性を担保するための正準化プロセスを確立する。

2. Scope

• YAML front matter（entity identity）
• Headings（scope）
• Bullets（facts/properties）
• [[id]]（relations）

3. Normative Requirements

• RCS-001 ROM 文書は entity.id と entity.type を持たなければならない（MUST）。
• RCS-002 [[id]] は解決可能な参照でなければならない（MUST）。
• RCS-003 事実は bullet 形式で宣言的に記述しなければならない（MUST）。

3.1 Canonicalization-First Hashing（正準化優先ハッシュ）

• RCS-CANON-001 Semantic Hash 計算前に、必ず IRomCanonicalizer を適用しなければならない（MUST）。
• RCS-CANON-002 IRomCanonicalizer は、Entity 群を EntityId または Timestamp の昇順でソートし、記述順序に依存しない構造を生成しなければならない（MUST）。
• RCS-CANON-003 ISemanticHasher は、正準化されたペイロード（CanonicalRomDocument）のみを入力として受け付けなければならない（MUST）。

4. Canonicalization（正規化の詳細定義）

ハッシュ不変性と Git 差分の最小化を担保するため、正規化は以下の手順で実行する。

1. Linguistic Normalization

全角/半角、ID の大文字/小文字、冗長な表現を正規化する。

2. Structural Sorting（Essential）

同一見出しレベル内の Entity および Bullet 集合を EntityId で昇順ソートする。これにより、意味的に同一な変更は Git 差分も最小となり、順序入れ替えのみの変更は差分を発生させない。

3. Reference Anchoring

[[entity.id]] を完全修飾 ID（例: namespace.project.id）へ置換してからハッシュ化する。

補足:

• 見出し番号差異は等価とみなす。
• 空白/改行/インデント差分は無視する。

5. Required Interfaces

正準化とハッシュ計算の責務を物理的に分離する。

public interface IRomCanonicalizer\n{\n    // ROM データを物理的にソート・正規化し、意味的同一性を Git 差分でも保証する\n    CanonicalRomDocument Canonicalize(RomDocument document);\n}\n\npublic interface ISemanticHasher\n{\n    // 正準化済みドキュメントからハッシュを算出する\n    string ComputeHash(CanonicalRomDocument canonicalDocument);\n    bool VerifyHash(CanonicalRomDocument canonicalDocument, string expectedHash);\n}\n\npublic sealed record CanonicalRomDocument(\n    string CanonicalBody,\n    IReadOnlyList<CanonicalEntity> Entities,\n    string CanonicalizationVersion);\n\npublic sealed record CanonicalEntity(\n    string EntityId,\n    DateTime? TimestampUtc,\n    string EntityType,\n    IReadOnlyDictionary<string, string> Properties);

6. Fail-Closed

• RCS-F001 必須 ID 欠落時は ROM 無効。
• RCS-F002 リンク未解決時は推論入力を拒否。
• RCS-F003 ハッシュ不整合（正準化後の計算結果が署名と不一致）時は検証失敗。
• RCS-F004 Type Consistency: entity.type とプロパティ定義が矛盾する場合（必須プロパティ欠落を含む）、入力を拒否する。
• RCS-F005 Circular Reference Guard: 循環参照が推論ループを誘発する恐れがある場合、即時停止する。

7. Relation Syntax（関係性の記述様式）

ROM の関係性は次の 3 形式で記述する。

6.1 Property Relation（属性関係）

エンティティの静的属性を定義する。 形式: * [property_name]: [[target_id]] または value 例: * [author]: [[user.tky]]

6.2 Action Relation（動的関係/イベント）

エンティティ間の動的相互作用を記述する。 形式: * [verb] -> [[target_id]] 例: * [executes] -> [[task.validation]]

6.3 Quantitative Relation（定量的関係）

ModelCapacityVector 等の数値関係を記述する。 形式: * [metric_name]: {numerical_value} 例: * [reasoning_score]: 0.95

8. Integrity Verification（整合性検証）

IPromptVerifier は以下の手順で ROM を検証する。

1. Schema Check

YAML メタデータの必須項目（id, type, version）を確認する。

2. Graph Linkage Check

ISignatureTrustStore および IPromptRepository を参照し、すべての [[id]] が信頼可能なノードを指すことを確認する。

3. Semantic Hash Match

正規化後に算出したハッシュが、署名済み hash フィールドと一致することを確認する。

9. Acceptance Criteria

• AC1: 同義表記ゆれ、および項目の記述順序の入れ替えにおいて同一 Semantic Hash を得る。
• AC2: 孤立リンク、または正準化プロセスに失敗した文書は拒否される。
• AC3: Git diff において、意味的な変更がない限り差分が発生しない。

変更履歴

• v0.0.0 / v0.0.0.0: 初期ドラフト
• v0.0.1 (2026-05-06): ドキュメント規約に基づくバージョン更新