DRP データ定義書

役割: DRP の永続データ契約（EDD-002）の正典 — D1 telemetry_records スキーマ（v1〜v8 migration 履歴）・KV キー設計・Durable Object の保持状態・Queue メッセージ封筒。旧 README §12.5-12.6 から抽出（strangler-fig Phase 2 / ADR-0117）。 位置づけ: ここに載るのは外から観測可能なデータ契約（監査クエリ・API レスポンス・運用 SQL が依存する形）。変更は L3（id_conventions.md §3）。

1. D1: telemetry_records（database: decision-pipeline-telemetry）

審査 run 1 件 = 1 行（実行基盤の Cloudflare Workflows 移行 = ADR-0120 後も 1 run = 1 行を維持。retry 発生時に step 名 + 回数を telemetry 列へ記録する拡張は 0120 決定 4。旧 ADR-0116 の chunk 単位拡張案は Superseded で消滅）。全カラムの API 露出形は openapi.yaml の TelemetryRecord と突合できる。

1.1 スキーマバージョン履歴（v1 → v8）

• schema_version カラムが各行の世代を持つ。旧世代行は新カラム NULL の後方互換（バックフィル状況は §1.4）。
• マイグレーション SQL はすべて drp/migrate-*.sql。適用は npx wrangler d1 execute decision-pipeline-telemetry --file=<sql>。

1.2 全カラム定義（現行 v8・56 カラム）

定義の正典 = drp/schema.sql（v1〜v4）+ migrate-v5〜v8.sql（2026-06-05 時点のコード実査）。型・制約は SQL が正で、本表が drift したら SQL に従う。

新規環境構築の注意: schema.sql に含まれるのは v4 カラムまで。新規 DB は schema.sql 適用後に migrate-v5〜migrate-v8 をこの順で追加適用する必要がある。

値の例の出典: 2026-06-05 に実 run（GET /audit/runs・169 件）から採取し、長文は … で短縮。INTEGER 0/1 カラムは D1 格納形が 0/1、API 露出形は true/false（/audit 系 API が boolean に変換して返す）— 本表は格納形で記載。

型と上限の共通規則（桁数・文字数を列ごとに書かない理由）: D1 = SQLite は型アフィニティ方式で、VARCHAR(n) / NUMERIC(p,s) 的な宣言桁数は書いても強制されないため、列単位の桁数・文字数欄は設けない。実際の上限は次の共通規則による:

• INTEGER: 64bit 符号付き（−9,223,372,036,854,775,808 〜 9,223,372,036,854,775,807）/ REAL: IEEE 754 倍精度（8 bytes）/ TEXT: 宣言上限なし
• D1 プラットフォーム上限（D1 Limits・2026-06-05 確認）: 文字列・BLOB・行 = 2,000,000 bytes（2 MB）（adr_body / input_context 等の長文を含む行全体の事実上の上限）/ DB 全体 10 GB（Paid）/ SQL 文 100 KB
• 1 テーブル 100 列 — 本テーブルは現在 56/100。将来 migration の列追加余地の管理指標とする
• 値の範囲・列挙の制約（0/1・enum・50 点満点等）はアプリ層の慣行であり DDL では強制されない —「制約・値域」列の記載がその正典

フラグ列の凡例: PK = PRIMARY KEY / NN = NOT NULL（いずれも SQL 宣言ベース・✓ のみ表示）。FK: 本 DB は単一テーブル構成で SQL 外部キー宣言はゼロ — FK 列の「（論理）」表記は DDL 外の論理参照（D1 → DO / KV）であり、参照整合性は強制されない。デフォルト値: SQL の DEFAULT 宣言ベース。空欄 = 宣言なし（SQLite では未指定 INSERT 時に NULL）。宣言があるのは schema_version の 1 列のみ。 SQLite の既知の仕様: TEXT PRIMARY KEY は NOT NULL を含意しない（INTEGER PK / WITHOUT ROWID を除く）。session_id の NN が空欄なのはこのため — 実際はアプリ層が常に UUID を書き込む。

運用注意: migrate-v5 の SQL 内コメントの適用例は DB 名が旧名（decision-pipeline-db）のまま。正しい適用先は decision-pipeline-telemetry（§1.1 の適用コマンド参照）。

1.4 互換性・バックフィルの現状

• 旧 gate_timings TEXT（JSON）カラムは互換性のため残置（将来の世代で DROP 予定）。/audit/runs API は新旧両カラムを JSON parse して返却。
• per-gate ms は v3 適用時の既存 31 件を json_extract(gate_timings, '$.gate') でバックフィル済。cross_validation_verdicts は実行時のみ生成のため過去レコードは NULL（バックフィル不可）。

1.5 クエリ例

-- Gate 別平均所要時間
SELECT AVG(scoring_ms), AVG(cross_validation_ms) FROM telemetry_records WHERE score IS NOT NULL;
-- 軸別毀損件数 (cross_validation_verdicts JSON 展開)
SELECT axis.value AS axis_name, COUNT(*) FROM telemetry_records, json_each(cross_validation_verdicts) je,
  json_each(je.value) axis WHERE axis.key = 'mustAxis' AND je.value LIKE '%"undermines":true%' GROUP BY axis_name;

2. KV 名前空間

2.1 DRAFTS_KV（起案 draft + キャッシュ）

read-after-write 整合: POST 直後は per-id / 一覧のどちらかが旧値を返しうる。成否判定は POST 201 + mtime で行う（運用知見）。

2.2 PROMPTS_KV（プロンプト・パラメータ管理 / ADR-0042・0085）

ゲート別の読込経路と fallback の対応は プロンプト仕様書 が正典。

3. Durable Objects

4. Queue メッセージ封筒

変更履歴