db-specialized-fit

db-specialized-fit（M20）— ベクトル・時系列・グラフ・検索

M20 では、汎用的なリレーショナル監査では見落とされるパラメーターが正確性を左右する、目的特化型エンジンを扱います。サブモジュールには文字が付きます（M20a～M20d）。スコアラーは、パラダイムプロファイル内の親 M20（references/scoring-model.md のベクトル／時系列／グラフカテゴリ）にマッピングします。

M20a — ベクトル（pgvector、Qdrant、Pinecone、Weaviate）

対象： 設計（メトリクスと次元、モデルバージョン、メタデータ／フィルター）＋パフォーマンス（インデックスとパラメーター、フィルター付き検索、再現率とレイテンシー）。

• 次元の一致 — 列／コレクションの次元が、埋め込みモデルの出力次元と一致していること（例：text-embedding-3-small の場合は vector(1536)）。不一致は重大なバグです（設計、重大度5）。
• 距離メトリックの一致 — インデックスのメトリック（コサイン／L2／内積）が、モデルの学習方法と一致していること。不一致があると、気付かないうちに再現率が大きく損なわれます。重大度5とするのは、モデルがリポジトリ内で宣言されている場合のみです。それ以外は directional とし、上限を設けません（スコアリングモデルの誠実性ルールに従います）。
• インデックスの存在と調整 — HNSW（m、ef_construction、ef_search）または IVFFlat（lists／probes）が宣言されており、大規模なテーブルで総当たりのシーケンシャルスキャンを行っていないこと（パフォーマンス）。
• モデルバージョンの記録 — 再埋め込みができるよう、埋め込みがモデルバージョンに紐付いていること（設計）。
• フィルター付き検索 — 事前／事後フィルタリングに使用するメタデータ自体にインデックスが付与されていること（パフォーマンス）。

M20b — 時系列／OLAP（TimescaleDB、InfluxDB、ClickHouse）

対象： 設計（ハイパーテーブル適合性、保持、時刻精度とタイムゾーン）＋パフォーマンス（チャンク／保持、継続的集計、圧縮、クエリー）。

• ハイパーテーブル／パーティションの適合性 — 大量の追記専用時系列データがハイパーテーブル、または時間によるパーティション分割を使用しており、チャンク間隔が適切であること（巨大なチャンクが1つだけでも、極小のチャンクが何百万個でもないこと）。
• ダッシュボードクエリーで生データ行をスキャンする代わりに、継続的集計／ロールアップが宣言されていること。
• コールドチャンクに対する圧縮／TTL 保持ポリシーがあり、生データの保持期間に上限があること。
• タイムスタンプの精度とタイムゾーン — 素朴なローカル時刻ではなく、timestamptz／UTC を使用していること（M4 のルールと共通）。

M20c — グラフ（Neo4j）

対象： 設計（エッジのモデリング、ノード／トラバーサル）＋パフォーマンス（インデックス検索、トラバーサル、スーパーノード）。

• エッジのモデリング — リレーションシップに適切な方向／種類があり、トラバーサルで必要となる場合はリレーションシッププロパティが存在すること。また、グラフエンジンの利点を損なうノードペアテーブルとしてリレーションシップをモデリングしていないこと。
• インデックスを利用した検索 — トラバーサルの開始点として使用するエントリーポイントノードのプロパティに、インデックス／制約（CREATE CONSTRAINT ... IS UNIQUE）が設定されており、ラベル全体のスキャンからトラバーサルが始まらないこと。
• スーパーノードのリスク — リレーションシップの次数が非常に高く、トラバーサルコストを支配するノード（パフォーマンス）。重大度の引き上げには、実際の次数を示す証拠が必要です。それ以外は directional とします。

M20d — 検索（Elasticsearch、OpenSearch）

対象： 設計（マッピング／アナライザーの正確性）＋パフォーマンス（クエリー／シャード構成）。

• マッピングとアナライザー — フィールドに明示的なマッピングがあり、解析対象のテキストで動的マッピングに依存していないこと。アナライザーが言語に適合し、keyword と text が意図的に選択されていること。
• マッピングの増殖／上限のない動的フィールドがないこと。インデックスサイズに対してシャード数が適切であること。

Tier-0 静的チェック

宣言されたスキーマ／設定を解析します：pgvector の vector(N) 列と CREATE INDEX ... USING hnsw/ivfflat、Qdrant／Pinecone のコレクション設定（size、distance）、Timescale の create_hypertable／add_*_policy、ClickHouse の ENGINE = MergeTree ... ORDER BY、Neo4j の制約／インデックス DDL、ES の mappings／settings JSON。宣言された埋め込みモデルの次元／メトリックを、リポジトリ内のコードで参照されているモデル ID と照合します。

Tier-1 検証クエリ

• pgvector：SELECT indexdef FROM pg_indexes WHERE indexdef ILIKE '%hnsw%' OR indexdef ILIKE '%ivfflat%'; および \d <table> で vector(N) の次元を確認します。
• Timescale：SELECT * FROM timescaledb_information.hypertables; および ...continuous_aggregates;。
• Neo4j：SHOW INDEXES; SHOW CONSTRAINTS; およびスーパーノードごとの次数（MATCH (n) RETURN ...）。
• ES：GET /<index>/_mapping、GET /<index>/_settings。エンジンに接続できない場合は needs_api です。

検出結果

schema/finding.schema.json に従って出力します。ID の例：

• M20a.embeddings.dim_mismatch — vector(768) ですが、モデルは 1536 を出力します（失敗、重大度 5、軸 design、 モデル ID がリポジトリ内にある場合は確信度 established）。
• M20a.embeddings.metric_mismatch — インデックスは L2 を使用していますが、モデルはコサイン類似度用にトレーニングされています（失敗、モデルが宣言されている場合のみ 重大度 5。それ以外は警告／方向性あり、軸 both）。
• M20a.embeddings.no_ann_index — ベクトル検索がシーケンシャルスキャンです（警告、重大度 4、軸 performance）。
• M20b.metrics.no_hypertable — 大規模な時系列テーブルがハイパーテーブルではありません（警告、重大度 4、軸 both）。
• M20c.users.unindexed_traversal_root — トラバーサルの開始プロパティにインデックスがありません（警告、重大度 3、軸 performance）。 各検出結果では、evidence.observed に実際の DDL／コレクション設定をそのまま引用します（シークレットは編集済み）。 verification.reproduce は上記の $DATABASE_URL を使用する、実行可能なコマンドです。verification.method は schema_introspect、index_check、ddl_parse、explain_plan のいずれかです。expected_impact には {axis, confidence, magnitude, rationale} を格納します。影響度は区分で示し、単独の％値にはしません。

誠実性

• インデックス設定の再現率やレイテンシの数値を断定しないでください。影響度は区分でのみ示します。
• 指標／次元の不一致による上限設定は、埋め込みモデルがリポジトリ内で宣言されている場合のみ適用します（永続的な事実）。 推定された不一致は directional とし、上限設定には決して使用しません。スーパーノード／ホットパーティションの重大度 5 には、 実稼働環境での次数の証拠が必要です。証拠がない場合は directional または needs_api とし、黙って合格にしないでください。