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

エンティティ

• 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, config。config はプラグインが自分自身の ために定義・参照する任意のJSONオブジェクトです — 下記の「プラグインとしてのストレージ」を参照してください。
• Artifact — id, resource_id, type, producing_plugin_id, external_ref。(resource_id, type) ごとに一意 — 再処理はバージョン管理ではなく、その場での上書きです。

ストレージの分離

Postgresは上記のテーブルのみを保持します — 生のファイル内容やベクトルの浮動小数点値は決して保持 しません。Artifact.external_ref は、実際に内容を保持している外部システムへの不透明なポインタ文字列 です (例: s3://bucket/key、qdrant://collection/point、あるいはプラグインが定義する任意の形式)。

プラグインとしてのストレージ

ストレージは処理用プラグインに後付けされた特別な仕組みではなく、単なる別のプラグインを、通常の パイプラインステップとして連結したものです。qdrant-register が実例です: vector-embedder が 埋め込みを計算し、共有オブジェクトストア内の一時的な場所に書き込みます。次のステップである qdrant-register がそれを読み取り、Qdrantに登録し、一時コピーを削除して、最終的な qdrant://... 成果物を報告します。コア側に特別な処理は一切必要ありません — 最終的な成果物は完全に通常の qdrant:// 参照であり、他のものとまったく同じ組み込みの表示/削除ロジックで扱われます。

プラグインの config は、再デプロイせずにそのバックエンドの正しいインスタンスを指す方法です — 例えば qdrant-register は config.qdrant_url を参照します (設定されていない場合は QDRANT_URL 環境変数にフォールバックします) 。これは PUT /plugins/{id}/config、またはWeb UI上のプラグイン カードの設定ボタンから設定できます。完全なパターンと、別のバックエンド向けに自分自身のストレージ プラグインを書く方法については プラグインの作り方 を参照してください。

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

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