ターゲットアーキテクチャ

英語版が原文です。

製品境界

製品は、1 つのデプロイ可能なシステムの中に 2 つの論理ステージを持ちます。

1. plan() は入力を安価に観察し、バージョン管理された機能スナップショットに束縛された、 シリアライズ可能で説明可能なルートを返します。
2. encode() は、受け渡された計画または新規に作成した計画を実行し、 ブロックツリー、埋め込み、使用量、実行トレースを返します。

計画が高価な処理パスを呼び出すことはありません。実行が呼び出し元の計画を黙って 変更することはありません。実行が使えるのは、その計画がすでに宣言している フォールバックだけです。

ワークスペース

indx-interfaces        末端の契約、拡張プロトコル、共有ヘルパー 1 つ
indx-source            上限付きロード、ダイジェスト、メディアタイプ検出
├── indx-router        事前観察、シグネチャ、レジストリビュー、計画
├── indx-executor      機能の呼び出し、フォールバック、ブロック、埋め込み
└── indx               ルーターとエグゼキューターの公開ファサード
    ├── indx-app-server  FastAPI トランスポート
    └── indx-app-cli     インプロセス CLI とサーバー起動

矢印は、上にあるパッケージへ向かう依存方向を表します。

• indx-interfaces はワークスペース依存を持ちません。契約とプロトコルであり、柵つきの例外が 1 つだけあります。標準ライブラリのみで、状態を持たず、I/O をせず、INDX_* を読まない ヘルパーはここに置けます。それは実装ではなく、下のパッケージたちがすでに共有している規則 だからです（ADR-0034）。
• indx-source は indx-interfaces のみに依存します。ルーターのモジュールではなく パッケージとして存在するのは、両ステージが同じバイト列を必要とするからです。 ルーターはそれを観察し、エグゼキューターは受け渡された計画の source_digest を それと照合してから、コンテンツを機能に渡します。2 か所で 2 回ロードすれば、 呼び出し元が何を送ったかについて両ステージの見解が食い違うことになります。
• indx-router と indx-executor は indx-interfaces と indx-source に依存し、 互いには決して依存しません。
• indx は両者を合成し、サポートされる公開サーフェスだけを再エクスポートします。
• アプリケーションパッケージは indx に依存します。indx がアプリケーションを インポートすることはありません。

これらのレイヤーをつなぐパッケージ横断のポートと、その境界の両側にある責務は、 プロトコルガイドが説明します。

ランタイムフロー

source + constraints
        │
        ▼
cheap preflight ──► capability snapshot ──► RoutePlan
                                                │
                          supplied or generated │
                                                ▼
                                        executor + fallbacks
                                                │
                                                ▼
                           blocks + embedding spaces + trace

ルートは、ドキュメント既定、ページ上書き、任意のリージョン上書きを持ちます。 選択されるすべての機能は、記録されたスナップショットの中に存在します。 計画はソースコンテンツのダイジェスト、ポリシーバージョン、スナップショット ID に 束縛されるため、再実行でき、互換性がない場合は明示的に拒否できます。

機能拡張

拡張の契約は型付きの CapabilityProvider です。インストールされた ディストリビューションは、Python エントリポイントグループ indx.capabilities で プロバイダーを公開します。発見には importlib.metadata.entry_points() を使います。 レジストリは重複 ID を拒否し、決定的に順序付けられたコンテンツアドレス方式の スナップショットを生成します。重い実装は実行まで遅延させなければなりません。

発見は実行時にプロバイダーのディストリビューションをロードします。これは ワークスペース依存ではありません。ファーストパーティのパッケージはどの プロバイダーもインポートせず、境界テストは名指しを禁止しています。そのため、 発見中にプロバイダーモジュールがインポートされても、「ルーターとエグゼキューターは 互いに依存しない」は成り立ったままです。

フックフレームワークは先送りです。最初に必要なのはキー付きの発見と再現可能な スナップショットであり、順序付き 1:N のフック呼び出しではありません。

詳細は CapabilityRegistry と CapabilityProvider のガイドを 参照してください。

最初の実装スライス

• CPU でのネイティブテキスト抽出。
• スキャンページ向けの、CPU での汎用 OCR。
• OCR が品質を満たせない場合の、GPU での汎用 VLM。
• 任意のインボイスシグネチャ 1 つとインボイスパーサー 1 つ。
• 任意の工程系統図シグネチャとパーサー 1 つ。PowerPoint の図形に対してページ単位で働きます。
• 終端フォールバックとしての手動レビューまたは明示的な失敗。

リージョン最適化、幅広いモダリティ対応、RAG エクスポート、永続化、 ルーター/エグゼキューターの分離デプロイは、最初のスライスがベースラインを 計測してからです。

ベンチマークの所有

ベンチマークのデータとラベルは、アクティブなリポジトリの benchmarks/ 契約の 下にあります。indx-everything-bench への依存はありません。採用されるすべての ドキュメントは複数ページを持ち、固定された制約と機能スナップショットの下で、 スコープレベルの要件ラベルと許容ルートラベルを持ちます。