データモデルリファレンス

完全な詳細 (正確なフィールド型と状態遷移図を含む) は specs/001-datacore-knowledge-warehouse/data-model.md にあります。

エンティティ

• Resource — id, name, source_type, source_uri, type, status, is_enabled, failure_reason, pipeline_id, artifacts[]。 status: PENDING → PROCESSING → (COMPLETED | FAILED)。is_enabled (デフォルト true) は、MCPサーバーが このリソースの成果物をLLMに公開するかどうかを制御します — このフラグはパイプライン処理には一切影響せず、 処理は変わらず実行されます。
• Pipeline — id, name, trigger_type (unique), steps[]。trigger_type ごとに最大1つのパイプライン。
• PipelineStep — position, plugin_id, max_attempts, backoff_seconds, timeout_seconds。
• Plugin — id, name, description, author, version, is_active。
• Artifact — id, resource_id, type, producing_plugin_id, external_ref。(resource_id, type) ごとに一意 — 再処理はバージョン管理ではなく、その場での上書きです。

ストレージの分離

Postgresは上記のテーブルのみを保持します — 生のファイル内容やベクトルの浮動小数点値は決して保持 しません。Artifact.external_ref は、実際に内容を保持している外部システムへのポインタ (s3://bucket/key または qdrant://collection/point) です。リソースを削除するとカスケードが 発生します: コアは各成果物の external_ref を読み取り、そのストアから対応するオブジェクトを削除 してから、行を削除します。

リソースが独自のステップスナップショットを持つ理由

Resource.step_snapshot は、実行が開始される瞬間に取得されるパイプラインのステップの非正規化された コピーです。これが、パイプラインを編集したり削除したりしても、既にそのパイプラインの下で PROCESSING 中のリソースには一切影響しない理由です — 実行中になった時点で、リソースはライブの Pipeline/PipelineStep の行を再読み込みすることは一切ありません。