オブザーバビリティ — エンジン自身を表す read-model

オブザーバビリティ（modules/observability）は 32 個のモジュールのひとつであり、 live-ingest と同様に、能力スロットを埋めるというよりもアーキテクチャ上の役割を担う。これはエンジン自身を表す read-model であり、 /v1/m/observability/ 配下の 3 つの読み取り専用サーフェスとして、管理コンソールの System セクションが描画する問いに答える。それも、ストアのエンティティを 1 つも所有することなく行う。

3 つのサーフェス

ルート	答える内容
`GET /ingestion-health`	エンジンに何が流入・流出するかを相互運用標準ごとに ——エンジンがピン留めする標準（OTel GenAI semconv、OCSF、ASIM、統合 SIEM フォーマット群、台帳プッシュ、Prometheus テキスト、W3C Trace Context）を、それぞれの検証済みバージョンとともに
`GET /traces`、`GET /traces/{id}`	あるトレースについて W3C で相関付けされた台帳が語る内容 —— Trace Context で結合された、分散トレースの監査側ビュー
`GET /attestation`	稼働中のバイナリのサプライチェーンについて証明可能に真であること —— リリース検証チェーンが供給するアテステーション・サーフェス

3 つすべてがモジュール単位の権限を持つ読み取りであり、ここでは何も変更しない。

なぜそもそもモジュールなのか

管理コンソールには「このエンジンは実際に何を話し、どのピン留めされたバージョンで話すのか？」という権威ある答えが必要だった —— そしてそれを誠実に提供する方法は、ドリフトしうるドキュメントからではなく、エンジン自身から提供することである。 ingestion-health テーブルは、コネクタやエクスポータがコンパイル対象とするのと同じピンから生成されるため、ピンが動けばサーフェスもそれに追従する。

境界づけられたコンテキスト、率直に述べる

ストアのエンティティを一切所有せず、何も永続化しない —— すでに存在する基盤（ピン、台帳、アテステーション証跡）を対象とした純粋な read-model。
これはモジュール XXII（health/SLA）ではない。あちらは estate のエージェントと MCP サーバーの信頼性に境界づけられている。本モジュールは エンジン に関するものである。
これはメトリクス・エンドポイントでもない。運用上の時系列は /metrics に存在する。本モジュールは時系列ではなく構造化された答えを提供する。

read-model のジャーニーを再現する

新規の使い捨ての Enterprise SQLite Compose インストールで、Python 3.11 以降を使って scripts/qualify-observability.py を実行する。インストール済みのバイナリ、HTTPS アドレス、コンテナ名、完全なソースコミット、新しい証跡ディレクトリを渡す。

python3 scripts/qualify-observability.py /path/to/olivares \
  https://127.0.0.1:8443 olivares <source-sha> /path/to/new-evidence

プローブは Enterprise の組織管理を使って、分離チェックのために 2 番目のテナントをプロビジョニングする。ingestion-health、トレースの read-model、アテステーションのサーフェスは Community でも利用できる。

プローブは API を通じてフィクスチャのアカウントとエージェントを作成し、既存の observability モジュールと security モジュールを有効にし、コンテナを物理的に再起動する。起動した実行ファイルの SHA-256 を渡されたバイナリと比較し、ファーストパーティの検出結果からの取り込みを検証し、テナントの拒否を確認し、再起動とモジュールのオフ/オンをまたいだ台帳のトレース詳細/エクスポートの保持を確認する。また、取り込みカウンターがリセットされること、およびアテステーションが、測定されたバイナリの識別を、宣言されたパイプラインと未公開のリリース状態から分けていることも検証する。 CLI のチェックは JSON 出力を使う。認証情報はメモリまたは子プロセスの環境にのみ置かれ、保持されるエンジンログはセットアップトークンをレダクトする。

README のインストール手順を、明示的に選択した候補イメージで使う。既存のインストールに対してプローブを実行してはならない。Python の最適化はアサーションを無効にするため拒否される。実行後に、使い捨ての Compose スタックとそのボリュームを削除する。プローブはこの後片付けを呼び出し側に任せ、結果とエンジンログを証跡ディレクトリに書き込む。コンソール操作、PostgreSQL、ベンダーコレクター、リリース署名の検証は実行しない。