BDDK MCP Server

Türkçe | English | 英語専用運用ガイド

BDDK MCP Server は、BDDK および mevzuat.gov.tr のトルコ銀行規制データを検索・取得・分析するための、オフラインファーストの Model Context Protocol サーバーです。カタログ検索、文書取得、セクション単位の法規参照、セマンティック検索、ビュレティン分析、文書品質チェック、オペレーターバックフィルワークフローを組み合わせています。

[!IMPORTANT] このリポジトリはエンジニアリングベータ版であり、法的助言や本番環境への準備ができていることを証明するものではありません。まず 現在のステータス と ドキュメント索引 を確認し、デプロイメントの境界 をレビューし、非公開の脆弱性報告には セキュリティポリシー を使用してください。貢献は CONTRIBUTING.md に従います。

Türkçe

何に使うのか？

このプロジェクトは、BDDK の決定および規制のための、安全で監査可能な MCP サーバーを構築することを目的としています。目的は、モデルが自身の知識から回答を生成するのではなく、ローカルデータストア内の BDDK ソースに基づいて回答することです。現在の本番環境のセキュリティ境界については、デプロイメントドキュメント を参照してください。

主な使用分野:

• BDDK 規制カタログの検索

• 文書本文におけるセマンティック検索と全文検索

• 特定の文書ページを Markdown として取得

• Madde、İlke、Paragraf、Ek などのセクションを直接取得

• 週次および月次の銀行業務ビュレティンデータの照会

• 規制変更、発表、トレンドに関するサマリーの生成

• 文書品質、OCR/数式リスク、抽出エラーの監視

主な特徴

• MCP SDK ベースのツール: stdio および Streamable HTTP 用の Claude/Codex 設定例があります。これらはリリース固有のクライアント互換性認証ではありません。

• オフラインファーストの文書取得: 規制テキストとセクションは PostgreSQL/pgvector 経由で提供されます。機関、発表、ビュレティンツールは上流へのアクセスを必要とする場合があります。

• カタログ検索と本文検索の分離: search_bddk_regulations はタイトル/メタデータのみを検索します。search_document_store は文書本文内をセマンティック検索します。

• セクション単位のアクセス: get_document_section と search_document_sections を使用すると、943 İlke 5 や mevzuat_22599 Madde 9 などの参照が直接見つかります。

• 正確な法規参照の保護: Madde 9 のような語彙的一致は、セマンティックスコアが低くても保持されます。

• 品質ラベル: 文書出力には clean、warning、fail シグナルと品質フラグが付けられます。

• 文書コンテキストのサニタイズ: get_bddk_document は、Data URI、生の HTML/OCR アーティファクト、および長い行をモデルコンテキストに渡す前にクリーンアップします。

• オペレータースクリプト: 品質スキャン、品質バックフィル、document_sections のインデックス再作成フローを利用できます。

• PostgreSQL + pgvector: 文書、セクション、FTS、ベクトル検索は単一のデータベース上で動作します。

ツールサーフェス

デフォルトの public プロセスプロファイル（BDDK_TOOL_PROFILE=public または bddk-mcp serve --profile public）は、17 個の public ツールのみを公開します。

別の operator プロセスプロファイル（BDDK_TOOL_PROFILE=operator または bddk-mcp serve --profile operator）は、17 の public ツールに 14 のオペレーターツールを追加し、合計 31 のツールを公開します。このプロファイルは、書き込み権限を持つ別の BDDK_OPERATOR_DATABASE_URL を必要とし、public DSN にはフォールバックしません。

• check_bddk_updates

• document_store_stats

• bddk_cache_status

• refresh_bddk_cache

• sync_bddk_documents

• trigger_startup_sync

• get_operator_job

• list_operator_jobs

• cancel_operator_job

• document_health

• health_check

• bddk_metrics

• backfill_degraded_documents

• document_quality_report

現在のランタイムの正規オペレーターレジストリは、17 の public ツールと 14 のオペレーターツール、つまり合計 31 の MCP ツールを含みます。ミューテーティングなオペレーターツールは、すぐにジョブレシートを返します。状態は get_operator_job、list_operator_jobs、cancel_operator_job で監視されます。ジョブレコードは、ハッシュ化された冪等性キー、数値進捗、限定的な結果メトリクスとともに、PostgreSQL の bddk_operator.operator_jobs テーブルに永続的に保持されます。セッションレベルのジョブ受付リースにより、同じランナーがプロセス間でジョブを同時に所有することを防ぎます。また、トランザクションレベルのコーパス変更ロックにより、公認ライターのトランザクションとリリースパブリッシャーを直列化します。ランナータスクは依然としてオペレータープロセス内にあります。古い queued ジョブは自動的に推定されず、マルチレプリカのフェイルオーバーを行う銀行環境では検証されていません。このため、OpenShift starter は単一の Recreate レプリカを使用し、システムは銀行グレードのワークフローキューとして提供されるべきではありません。ベンチマークスキーマは同じ正規オペレーターレジストリから生成されます。ベンチマーク実行は、使用する正確なツールリストとプロファイルを記録する必要があります。参照: benchmark/README.md。

クイックスタート

要件:

• Python 3.12 または 3.13

• uv

• PostgreSQL 17、pgvector、unaccent（このリリースでテストされていないメジャーバージョンはフェイルクローズで拒否されます）

• オプション: Docker Compose

インストール:

git clone https://github.com/omercagatay/bddk-mcp.git
cd bddk-mcp
uv sync

使い捨てローカル PostgreSQL ライフサイクル:

export BDDK_JWT_ISSUER=https://idp.invalid
export BDDK_JWT_RESOURCE=https://localhost:8000/mcp
export BDDK_JWT_JWKS_URL=https://idp.invalid/jwks
export BDDK_JWT_AUDIENCE=bddk-mcp-local
docker compose up --build -d bddk-bootstrap
docker compose wait bddk-bootstrap
export BDDK_DATABASE_URL=postgresql://bddk_local_public:local-only-public@localhost:5432/bddk

Compose は、ループバック開発環境でのみ、DBA ロール/拡張機能の準備 → スキーマ所有者 migrate → DBA グラント → 取り込み bootstrap の順序を実行します。.invalid JWT 値は、Compose が未使用の HTTP サービスの定義をパースするためのものであり、このライフサイクルコマンドは HTTP サーバーを起動しません。また、これらの値はサーバーの実行には有効ではありません。固定パスワードは public テストフィクスチャであり、リモート環境で使用しないでください。本番環境では、bddk-mcp migrate はスキーマのみの作業です。bddk-mcp bootstrap は、事前にマイグレーションされグラントが適用されたスキーマに、レビュー済みのシード、セクション、768 次元の埋め込みを書き込みますが、マイグレーションは実行しません。ID と完全な順序の詳細については、デプロイメントドキュメント を参照してください。

データベース接続を確立せずにコーパスの範囲と 3 つのシードアーティファクトを検査するには、オプションの読み取り専用プレフライトを実行してください:

uv run --frozen bddk-mcp verify-corpus

このコマンドは、チェックサム、サイズ、レコード数、フレッシュネス時刻を検証しますが、後続のプロセスに信頼を引き継ぎません。本番インポートは、同じ厳格なポリシーをミューテーティングな bootstrap 呼び出しで直接再適用する必要があります:

BDDK_INGESTION_DATABASE_URL='postgresql://INGESTION:SECRET@HOST:5432/DATABASE?sslmode=verify-full&sslrootcert=%2FAPPROVED%2Fpostgres-ca.crt' \
  uv run --frozen bddk-mcp bootstrap \
    --seed-dir /APPROVED/CORPUS \
    --reindex-existing \
    --require-quantified-freshness \
    --require-measured-freshness \
    --require-verified-signature \
    --trusted-signing-key /APPROVED/TRUST/corpus-signing-public-key.pem

bootstrap は、DB プールを開く前に、正確な corpus_scope.yml とマニフェストで定義されたアーティファクトのパス/バイト数/ハッシュを検証します。存在するがマニフェストで定義されていない documents.json、chunks.json、または decision_cache.json ファイルは拒否されます。トラストキーは、コーパスとは別の Secret/マウントで提供される必要があります。数値ターゲットの定義は、それ自体では測定になりません。measured 状態では、各文書について、権威ある公開 → ソース検出 → ダウンロード → 抽出 → 取得公開の時間チェーンと、計算された遅延がターゲット内にある必要があります。現在のレビュー済みマニフェスト（bddk-job-corpus-2026-08-14）は Ed25519 で署名されており、数値ターゲット（検出 7 日、公開 14 日、マニフェスト期間 180 日）を含みます。--require-quantified-freshness と --require-verified-signature を使用して、本番 bootstrap は通過します。ライブ監視パイプラインがないため、slo_evidence_status: not_measured のままであり、--require-measured-freshness を要求する検証ステージングは、この単一のゲートで意図的に拒否します。bootstrap が成功すると、オペレーターエビデンス用のパスなしマニフェスト ID と SHA-256 を返し、また、別途公開が必要であることを通知します。本番ライフサイクルの順序は、migrate → bootstrap → verify-and-stage-corpus-release → activate-corpus-release です（DBA 02_grants.sql は、マイグレーションと bootstrap の間に適用されます）。Verifier は、BDDK_RELEASE_VERIFIER_DATABASE_URL を使用して別の bddk_release_verifier アイデンティティを使用します。コーパスとトラストキーを再検証し、正確な DB メンバーシップ/状態/エポックをチェックし、短命のリクエスト ID を返します。トラストキーは別途マウントする必要があり、指定されたパスと解決されたパスの両方がコーパスルートの外側にある必要があります。BDDK_RELEASE_VERIFIER_REVISION_SHA256 は 64 文字の小文字 hex リビジョン、BDDK_RELEASE_VERIFIER_IMAGE_DIGEST は sha256: ダイジェスト、BDDK_RELEASE_VERIFICATION_VALIDITY_SECONDS は 60〜3,600 秒（デフォルト 900）でなければなりません。Publisher は、このリクエスト ID と BDDK_RELEASE_PUBLISHER_DATABASE_URL の値のみを受け取ります。コーパス PVC、マニフェスト、署名、トラストキーは受け取りません:

BDDK_RELEASE_VERIFIER_DATABASE_URL='postgresql://VERIFIER:SECRET@HOST:5432/DATABASE?sslmode=verify-full&sslrootcert=%2FAPPROVED%2Fpostgres-ca.crt' \
BDDK_RELEASE_VERIFIER_REVISION_SHA256='REPLACE_64_LOWERCASE_HEX_REVISION' \
BDDK_RELEASE_VERIFIER_IMAGE_DIGEST='sha256:REPLACE_64_LOWERCASE_HEX_IMAGE_DIGEST' \
BDDK_RELEASE_VERIFICATION_VALIDITY_SECONDS=900 \
  uv run --frozen bddk-mcp verify-and-stage-corpus-release \
    --seed-dir /APPROVED/CORPUS \
    --trusted-signing-key /APPROVED/TRUST/corpus-signing-public-key.pem

BDDK_RELEASE_PUBLISHER_DATABASE_URL='postgresql://PUBLISHER:SECRET@HOST:5432/DATABASE?sslmode=verify-full&sslrootcert=%2FAPPROVED%2Fpostgres-ca.crt' \
  uv run --frozen bddk-mcp activate-corpus-release \
    --request-id corpus_release_request_sha256_REPLACE_64_LOWERCASE_HEX

アクティベーションリクエストの有効期限が切れている場合、以前に使用された場合、またはコーパスの状態/エポック/準備状態が変更された場合、フェイルクローズされます。資格情報の分離を維持するために、古い publish-corpus-release エイリアスは無効になっています。

台帳前の古いデータベースは、通常のマイグレーションによってフェイルクローズで拒否されます。--adopt-legacy は、正確にサポートされているシェイプ、検証済みバックアップ、および レガシーアップグレードランブック で使用される明示的なオプトインです。クリーンインストールや一般的な修復フラグではありません。

完全な version-2 データベースでは、マイグレーション 3 も、ブロッキングな取得公開バックフィルと外部キー検証のため、デフォルトで拒否されます。--allow-retrieval-publication-backfill は、ワークロードが停止され、復元可能なバックアップが証明され、同じサイズのリストアでリハーサルが行われた後の、制御されたメンテナンスウィンドウでのみ使用する必要があります。BDDK_EXPECTED_DATABASE_NAME と DBA スクリプトの独立したターゲット設定は、アクティブなデータベースと一致する必要があります。分離されたローカル Compose プロファイルを除き、PostgreSQL DSN は sslmode=verify-full と絶対パスの sslrootcert を使用する必要があります。

テスト:

uv run pytest tests/test_tools_sections.py tests/test_doc_store.py -k section -v
uv run ruff check .

MCP stdio の実行:

BDDK_DATABASE_URL=postgresql://bddk:bddk@localhost:5432/bddk \
uv run --frozen bddk-mcp serve

HTTP トランスポート:

BDDK_DATABASE_URL=postgresql://bddk:bddk@localhost:5432/bddk \
MCP_TRANSPORT=streamable-http \
PORT=8000 \
uv run --frozen bddk-mcp serve

Streamable HTTP MCP エンドポイントは http://localhost:8000/mcp であり、サーバーはステートレス JSON レスポンスモードで動作します。リモートアプリケーションは RFC 9728 protected-resource メタデータを /.well-known/oauth-protected-resource/mcp パスで公開します。401 チャレンジは同じ URL を resource_metadata として通知します。これはアプリケーションレベルの MCP 認可ディスカバリであり、銀行 IdP のクライアント登録/フロー受入の証明ではありません。固定のコンテンツフリーなプローブエンドポイントは GET /health/live と GET /health/ready です。readiness はマイグレーション、重要なカタログオブジェクト、コーパス公開、ワークロード ACL を定期的に再検証します。プローブは認証/Host 制御の対象外ですが、プロセスのレート制限と並行性制限の対象です。ループバック以外のバインドはフェイルクローズドに動作します。厳密な Host/HTTPS Origin 許可リストと完全な JWT/JWKS 設定が必須です。パブリックプロファイルは bddk.read スコープを、オペレータープロファイルは bddk.operator スコープを要求します。リモートオペレーターはさらに、BDDK_OPERATOR_REMOTE_ENABLED=true による明示的なオプトインを要求します。BDDK_HTTP_ALLOW_UNAUTHENTICATED は、ベアラー認証なしでループバック以外のパブリック読み取り専用バインドを提供するための、サポートされている明示的なオプトインです。デフォルトでは設定されておらず、設定されていない場合でもフェイルクローズドのデフォルトは変わりません。設定された場合、BDDK_JWT_ プレフィックス付きの設定とは組み合わせられません。起動時に拒否され、設定された変数を名前付きでリストします。また、ループバック以外のオペレータープロファイルでは、BDDK_OPERATOR_REMOTE_ENABLED の値に関係なく拒否されます。オペレーターツールは認証済みまたはループバック専用のままです。認証なしサーバーは OAuth ディスカバリを公開しません。WWW-Authenticate チャレンジは存在せず、2 つの well-known OAuth ルートは両方とも 404 を返します。Host/Origin 許可リスト、ボディサイズ、並行性、レート制限は引き続き適用されます。このモードでは、レートリミッターが主要な不正使用対策です。レートリミッターのクライアントキーは BDDK_HTTP_TRUSTED_PROXY_HOPS（デフォルト 0）によって決まります。0 の場合、キーは ASGI ソケットピアであり、X-Forwarded-For は完全に無視されます。オペレーターが制御する n 台のリバースプロキシの背後では、実際のホップ数を設定し、結合された forwarded リストの右から n 番目のエントリをキーとして取得します。使用できない値はソケットピアにフォールバックせず、共有の unknown バケットに入ります。誤った値は、リミッターを共有状態またはスプーフィング可能な状態にします。ボディサイズ、並行性、分単位のレート制限はアプリケーションプロセス内で適用されます。レプリカ間でのグローバルなイングレス制限は提供されません。詳細はデプロイメントドキュメントを参照してください。

従来の seed インポート/エクスポートヘルパーコマンドも保持されています。新しいデプロイメントでは、検証を含む bddk-mcp bootstrap が推奨されます。

BDDK_INGESTION_DATABASE_URL=postgresql://bddk_local_ingestion:local-only-ingestion@localhost:5432/bddk \
uv run --frozen bddk-seed import

Claude 設定

リポジトリルートにある .mcp.json は、リポジトリルートを作業ディレクトリとして使用する .mcp.json 互換クライアント向けのポータブルな stdio の例です。

{
  "mcpServers": {
    "bddk": {
      "command": "uv",
      "args": ["run", "--frozen", "bddk-mcp"],
      "env": {
        "MCP_TRANSPORT": "stdio",
        "BDDK_DATABASE_URL": "${BDDK_DATABASE_URL}"
      }
    }
  }
}

Codex 設定

Codex CLI と IDE 拡張機能は同じ Codex MCP 設定を使用します。~/.codex/config.toml または信頼されたリポジトリ内の .codex/config.toml に以下を追加してください。cwd の値はご自身のチェックアウトパスに合わせて変更してください。

[mcp_servers.bddk]
command = "uv"
args = ["run", "--frozen", "bddk-mcp"]
cwd = "/absolute/path/to/bddk-mcp"
env_vars = ["BDDK_DATABASE_URL"]
startup_timeout_sec = 30
tool_timeout_sec = 60

codex mcp list または Codex 内の /mcp を使用して接続を確認してください。

Docker、Railway、OpenShift AI の境界については、docs/DEPLOYMENT.md を参照してください。

サンプルクエリ

search_bddk_regulations(keywords="kredilerin sınıflandırılması")
search_document_store(query="TFRS 9 kredi riskinde önemli artış")
get_bddk_document(document_id="mevzuat_22599", page_number=1)
get_document_section(document_id="943", section_type="ilke", section_ref="5")
search_document_sections(query="Karşılık Yönetmeliği Madde 9 TFRS 9")
get_bddk_bulletin(metric_id="1.0.1", currency="TRY", days=90)
analyze_bulletin_trends(metric_id="1.0.1", lookback_weeks=12)
get_regulatory_digest(period="week")

オペレーターワークフロー

品質スキャン:

uv run python scripts/scan_document_quality.py --db --out-dir quality_reports --allow-failures

品質問題のあるドキュメントのドライラン:

uv run python scripts/backfill_quality_failures.py --dry-run

特定の品質失敗ドキュメントを再取得:

uv run python scripts/backfill_quality_failures.py --doc-id mevzuat_21192 --execute

既存のドキュメントから document_sections テーブルを ingestion ID で再作成:

BDDK_INGESTION_DATABASE_URL=postgresql://INGESTION:SECRET@HOST:5432/DB \
  uv run python scripts/reindex_document_sections.py --execute

実行を行う quality backfill、sync、reindex スクリプトも BDDK_INGESTION_DATABASE_URL を必要とし、正確な bddk_ingestion 権限コントラクトを検証します。パブリックまたはオペレーターの DSN で実行してはなりません。

オプションの取得テレメトリー:

BDDK_DATABASE_URL=postgresql://PUBLIC:SECRET@HOST:5432/DB \
BDDK_TELEMETRY_ENABLED=true \
BDDK_TELEMETRY_DATABASE_URL=postgresql://TELEMETRY:SECRET@HOST:5432/DB \
  uv run --frozen bddk-mcp serve --profile public

テレメトリーはデフォルトでオフです。有効にすると、専用の LOGIN は bddk_telemetry_writer ロールのみを継承する必要があります。起動時に列スコープの INSERT 専用権限を検証し、トレースの読み取り/変更や広範なメンバーシップを拒否します。tool_call_traces テーブルには、レイテンシ、結果数、doc ID、品質ラベル、関連性の要約を書き込みます。クエリ/プロンプトテキストはハッシュ/長さの要約として保存されます。生テキストは、BDDK_TELEMETRY_STORE_TEXT=true が明示的に設定されている場合にのみ書き込まれます。

アーキテクチャ

server.py                 Kök shim → bddk_mcp/server.py
seed.py                   Kök shim → bddk_mcp/ingest/seed.py
bddk_mcp/                 Ana paket
  server.py               FastMCP giriş noktası ve lifecycle
  core/                   config, DB identity, outbound HTTP, logging ve modeller
  migrations/             Immutable global PostgreSQL migration ledger
  jobs/                   Durable operator job modelleri ve PostgreSQL repository
  store/                  doc_store, vector_store, section_index, legal_ref
  ingest/                 client, data_sources, doc_sync, html_extractor, backfill, seed
  quality/                markdown_quality, quality_scan
  observability/          analytics, telemetry, metrics
  tools/                  MCP tool modülleri
  ocr/                    base, chandra (pluggable OCR)
scripts/                  Operatör ve backfill scriptleri
benchmark/                Tool schema ve benchmark altyapısı

データ品質とセキュリティに関する注記

• 完全な規制ドキュメントとセクション取得の回答はローカルストアから取得されます。これらの 2 つのフローはランタイム時にドキュメントをライブフェッチしません。

• カタログキャッシュの更新、機関/公告の検索、および公報ツールは、設定とキャッシュ状態に応じて BDDK アップストリームサービスにアクセスする場合があります。

• ライブの規制 HTTP パスは、厳密な BDDK/法令 HTTPS ホスト、リダイレクト/DNS 再検証、およびアーティファクトタイプに応じた code-owned ストリーミング制限を適用します。URL/クエリ/例外テキストはリトライログに書き込まれません。パブリックの機関/公告/公報/更新ツールもライブ BDDK アクセスを行えるため、OpenShift の egress コントラクトは、承認された規制ソースまたはプロキシに対してのみ、パブリックランタイムとオペレーターランタイムの両方に TCP 443 を許可する必要があります。ライフサイクル Job にはこのアクセスを許可しないでください。DNS から接続までの競合があるため、NetworkPolicy または承認済みプロキシ/ファイアウォールが必須です。

• デフォルトの埋め込みモデルは完全なコミット d13f1b27baf31030b7fd040960d60d909913633f にピン留めされ、オプションのデフォルトのリランカーは 1427fd652930e4ba29e8149678df786c240d8825 にピン留めされています。不変スキーマは vector(768) のみを受け入れます。モデル/チャンク設定の変更には、管理された完全な再埋め込みと取得回帰テストが必要です。

• 取得公開レコードは、チャンクの整合性、最新のコンテンツハッシュ、アクティブな取得プロファイルが検証された後にのみ書き込まれます。欠落または古いインデックスが検索結果に暗黙的に混ざることはありません。

• bootstrap は、レビュー済みコーパスをマニフェストの正確なアーティファクトパスにバインドし、予約済み seed ファイル名のバイパスを拒否します。別の verify-corpus の実行は診断用プリフライトにすぎません。本番セキュリティゲートは、同じ bootstrap コマンドと別途マウントされたトラストキーに直接付与する必要があります。deploy/openshift-overlays/bank-bootstrap は、リポジトリのプリフライトで、この正確なコマンド、読み取り専用の approved-corpus PVC、および別の読み取り専用の corpus-trust Secret を検証します。実際の銀行の PVC/Secret プロビジョニングと Job の実行は依然として外部ゲートです。

• v0005 は、追加専用のリリース/アクティベーションと、17 のコーパステーブルをカバーするミューテーションエポックを追加します。厳密なローカルコーパス呼び出しは、呼び出しの前後で同じアクティブリリースを検証します。v0008 は、パブリッシャーから従来の直接公開権限を削除します。bddk_release_verifier はコーパス/トラスト素材を読み取り、厳密なメンバーシップを証明し、検証者のリビジョン/イメージダイジェストと 60〜3,600 秒の TTL にバインドされたリクエストをステージングします。bddk_release_publisher は、単回使用のリクエスト ID でのみアクティベーションを実行できます。アクティベーションは、有効期限、再利用、取得 readiness、コーパスエポック、状態ハッシュをアトミックに再チェックします。同じプリンシパルが両方のロールまたはスキーマ所有者権限にアクセスすると、分離が破壊されます。銀行の Secret/RBAC 管理はこれを防ぐ必要があります。v0007 は、retain-corpus-generation --expected-release-id ... を使用して、正確なアクティブ状態を 17 個の型付き保持リレーションにコピーして封印します。保持された世代は serving でも reactivation でもありません。v7 より前の非正規ハッシュの修復は、変更されていない v5/v6 スキーマ上の正確でレビュー済みの公開専用互換性境界です。v7 に移行した後も、v8 への移行のための直接パスを定常状態として使用しないでください。現在のバイナリの publish-corpus-release CLI は無効になっています。履歴の行/バインディングを生成せず、承認されたアップグレード修復を適用し、v8 マイグレーションと権限付与を完了してください。追跡対象のコーパスは署名されており、現在のプロファイルが生成した 9,675 チャンクを報告します。v0010 は、リリース台帳で正確に 2 つのフレッシュネスポリシーを受け入れます。quantified_measured_signature_verified_pass と、より弱い quantified_unmeasured_signature_verified_pass です。どちらも数値ターゲットと検証済み署名を必要とします。検証者は、マニフェストの証拠からレベルを導出します。--accept-unmeasured-freshness は弱いレベルのみを許可し、それを measured としてラベル付けすることはできません。

• v0004 の 11 個のオーナー制御の法的キュレーションテーブルは、SourceBlob コンテンツ ID を SourceArtifact 取得 ID から分離します。変更権限はオーナーのみにあります。v0008 は、公開証拠を再計算するための正確な読み取り専用例外をリリース検証者に与えます。v0006 は、競合または証拠不十分の場合に棄権するパブリックの resolve_regulation_status 関数/ツールパスを追加します。合成された実 PostgreSQL の証拠は、実際の規制ファミリー/最新性の証明ではありません。

• 評価ゲートは、署名付きの 4 つのレイヤーを要求します。測定済みコーパス、エキスパートデータセット、正確な Citation パックに対する法的キュレーターの attestation、および保持されたソース/取得/ページ/抜粋チェーンをバインドする法的リリースチェックポイントです。正規のコーパス/データセット/キュレーター/リリース署名者のフィンガープリントは別々でなければなりません。現在のプリフライトは、オペレーター提供のアンカーの下でのみ暗号的一貫性を証明します。銀行の承認とモデルスコアの承認は常に false です。追跡対象の 20 ケースデータセットはドラフトであり、キーローテーション、指名レビューアーポリシー、エキスパートケースの実行はまだ存在しません。

• サプライチェーンレーンのコンテナは、Buildx --provenance=false --load でローカルに生成されます。マニフェスト記述子/ダイジェスト、config ダイジェスト、ロード済みイメージ、Syft SBOM は、同じイメージにフェイルクローズドにバインドされます。リポジトリは署名なしの SLSA provenance も生成し、モデルマニフェスト/ランタイム/Dockerfile のピンが整合していることを検証します。保留中の例外を使用した結果はプロモーション対象になることはありません。銀行の署名、admission、レジストリプロモーションは依然として外部ゲートです。

• ランタイムの wheel/sdist には seed_data、ベンチマーク、デプロイメントアセットは含まれません。提供されたコンテナにはレビュー済みシードが明示的に含まれます。wheel インストールでは、承認済みコーパスをマウントし、bootstrap に --seed-dir または BDDK_SEED_DIR を指定する必要があります。

• 低品質の抽出出力は warning または fail としてマークされます。

• 数式が多い、または OCR が破損したドキュメントでは、ソース PDF の検査が必要になる場合があります。

• get_bddk_document の回答では、データ URI、raw HTML、一部の OCR アーティファクトがクリーンアップされます。

• モデルはツール出力のみに基づいて回答する必要があります。決定番号、日付、法的結論を捏造してはなりません。

• 既知の抽出問題、失敗ドキュメントリスト、バックフィルコマンドについては、docs/DOCUMENT_QUALITY.md を参照してください。

• 銀行の OpenShift AI クラスター、バックアップ/リストアフロー、および Claude/Codex/GPT/GPT-OSS/LM Studio/ローカルモデルのクライアントマトリックスは、このリポジトリでの acceptance テストをまだ通過していません。

Related MCP server: tr-eli-mcp

英語

これは何か

BDDK MCP Server は、トルコの銀行規制データに対する安全で監査可能な Model Context Protocol インターフェースを提供することを目的としています。モデルの事前知識に頼るのではなく、LLM の回答をローカルの BDDK データに基づかせるように設計されています。現在の本番セキュリティ境界については、デプロイメントガイド を参照してください。

一般的なユースケース:

• BDDK 規制カタログを検索する

• セマンティック検索と全文検索を使用してドキュメント本文内を検索する

• ページ分割された Markdown ドキュメントを取得する

• Madde、Ilke、Paragraf、Ek などの正確な法的セクションを取得する

• 週次および月次の銀行公報データをクエリする

• 規制ダイジェストとトレンドサマリーを作成する

• ドキュメント品質、OCR/数式リスク、抽出失敗を監視する

ハイライト

• MCP SDK ツールサーフェス: Claude/Codex 向けに stdio と Streamable HTTP の例が提供されています。これらの例は、リリース固有の互換性認定ではありません。

• オフラインファーストの文書検索: 規制テキストとセクションは PostgreSQL/pgvector から提供されます。機関、公告、および公報ツールはアップストリームへのアクセスを必要とする場合があります。

• カタログ/本文の分離: search_bddk_regulations はメタデータを検索し、search_document_store は文書本文を検索します。

• セクションレベルの取得: get_document_section と search_document_sections は 943 Ilke 5 や mevzuat_22599 Madde 9 のような参照をサポートします。

• 法的参照の厳密な保存: Madde 9 のような字句ヒットは、高密度関連性フィルタリングを通過して残ります。

• 品質ラベル: 文書出力には clean、warning、fail のメタデータと品質フラグが含まれます。

• 文書コンテキストのサニタイズ: get_bddk_document は、モデルコンテキストに入れる前に、データ URI、生の HTML/OCR アーティファクト、および異常に長い行を削除します。

• オペレータースクリプト: 品質スキャン、品質バックフィル、および document_sections の再インデックスワークフローが含まれます。

• PostgreSQL + pgvector: 文書、セクション、FTS、ベクトル検索は単一のデータベースを共有します。

ツールサーフェス

デフォルトの public プロセスポロファイル（BDDK_TOOL_PROFILE=public または bddk-mcp serve --profile public）は、17 の公開ツールのみを公開します。

別の operator プロセスポロファイル（BDDK_TOOL_PROFILE=operator または bddk-mcp serve --profile operator）は、17 の公開ツールに 14 のオペレーターツールを追加し、合計 31 ツールを公開します。これは、書き込み可能な別の BDDK_OPERATOR_DATABASE_URL を必要とし、公開 DSN にフォールバックすることはありません。

• check_bddk_updates

• document_store_stats

• bddk_cache_status

• refresh_bddk_cache

• sync_bddk_documents

• trigger_startup_sync

• get_operator_job

• list_operator_jobs

• cancel_operator_job

• document_health

• health_check

• bddk_metrics

• backfill_degraded_documents

• document_quality_report

正規のオペレーターレジストリには、17 の公開ツールと 14 のオペレーターツール、つまり合計 31 の MCP ツールが含まれます。変更を伴うオペレーターツールは、即時のジョブ受領票を返します。それらを確認するには、get_operator_job、list_operator_jobs、cancel_operator_job を使用してください。ジョブレコード、ハッシュ化された冪等性キー、数値の進行状況、制限付きの結果メトリクスは、PostgreSQL のテーブル bddk_operator.operator_jobs に永続化されます。セッションスコープのジョブ受付リースは、プロセス間で同じランナーの同時所有を防ぎます。トランザクションスコープの別個のコーパス変更ロックは、承認されたライタートランザクションとリリースパブリッシャーを直列化します。ランナータスクは依然としてオペレータープロセス内に存在し、古くなった queued ワークが自動的に推測されることはありません。また、マルチレプリカフェイルオーバーは、銀行環境では受け入れられていません。したがって、OpenShift スターターは 1 つの Recreate レプリカを使用し、これはバンクグレードのワークフローキューとしては表現されません。ベンチマークスキーマは同じ正規のオペレーターレジストリからエクスポートされます。ベンチマーク実行では、使用した正確なツールリストとプロファイルを記録する必要があります。benchmark/README.md を参照してください。

クイックスタート

要件:

• Python 3.12 または 3.13

• uv

• PostgreSQL 17（pgvector と unaccent 付き。このリリースは未テストのメジャーバージョンではフェイルクローズします）

• オプション: Docker Compose

インストール:

git clone https://github.com/omercagatay/bddk-mcp.git
cd bddk-mcp
uv sync

使い捨てのローカル PostgreSQL ライフサイクル:

export BDDK_JWT_ISSUER=https://idp.invalid
export BDDK_JWT_RESOURCE=https://localhost:8000/mcp
export BDDK_JWT_JWKS_URL=https://idp.invalid/jwks
export BDDK_JWT_AUDIENCE=bddk-mcp-local
docker compose up --build -d bddk-bootstrap
docker compose wait bddk-bootstrap
export BDDK_DATABASE_URL=postgresql://bddk_local_public:local-only-public@localhost:5432/bddk

ループバック開発専用に、Compose は DBA ロール/拡張機能のセットアップ → スキーマ所有者 migrate → DBA による権限付与 → 取り込み bootstrap を実行します。予約された .invalid JWT 値は、Compose が未使用の HTTP サービス定義を解析できるようにするためだけのものであり、このライフサイクルターゲットは HTTP サーバーを起動せず、それらの値は有効なサーバー構成ではありません。その固定パスワードは公開テストフィクスチャであり、リモートにコピーしてはなりません。本番環境では、bddk-mcp migrate はスキーマ作業のみを実行します。bddk-mcp bootstrap は、移行済みかつ権限付与済みのスキーマを必要とし、レビュー済みのシード、セクション、768 次元の埋め込みをインポートします。マイグレーションは実行しません。完全な ID と適用順序については、デプロイメントガイド を参照してください。

オプションの読み取り専用プリフライトを使用すると、データベース接続を開かずに、コーパス宣言と 3 つすべてのシードアーティファクトを検査できます:

uv run --frozen bddk-mcp verify-corpus

このコマンドはチェックサム、サイズ、レコード数、鮮度タイムスタンプを確認しますが、後続のプロセスに信頼を引き継ぐことはありません。本番インポートは、変更を伴う bootstrap の呼び出しで厳格なポリシーを直接再適用する必要があります:

BDDK_INGESTION_DATABASE_URL='postgresql://INGESTION:SECRET@HOST:5432/DATABASE?sslmode=verify-full&sslrootcert=%2FAPPROVED%2Fpostgres-ca.crt' \
  uv run --frozen bddk-mcp bootstrap \
    --seed-dir /APPROVED/CORPUS \
    --reindex-existing \
    --require-quantified-freshness \
    --require-measured-freshness \
    --require-verified-signature \
    --trusted-signing-key /APPROVED/TRUST/corpus-signing-public-key.pem

bootstrap は、データベースプールを開く前に、正確な corpus_scope.yml と、マニフェストで宣言されたアーティファクトのパス、バイト数、ハッシュを検証します。存在するが宣言されていない documents.json、chunks.json、decision_cache.json は拒否します。信頼キーは、コーパスとは別の Secret/マウントから提供してください。数値目標を宣言することは測定ではありません。measured ステータスには、文書ごとの権威ある公開 → ソース検出 → ダウンロード → 抽出 → 検索公開のタイムラインと、それらの目標内で算出された遅延が必要です。現在のレビュー済みマニフェストは未署名であり、数値目標がなく、slo_evidence_status: not_measured として扱われます。そのため、この本番ブートストラップは意図的に失敗します。ブートストラップが成功した場合の出力には、オペレーターの証跡用にパスを含まないマニフェスト ID と SHA-256 が含まれ、公開が必要であるとマークされます。候補は永続化されません。本番ライフサイクルは、migrate → bootstrap → verify-and-stage-corpus-release → activate-corpus-release です（DBA はマイグレーションとブートストラップの間に 02_grants.sql を適用します）。検証者は、専用の bddk_release_verifier アイデンティティと BDDK_RELEASE_VERIFIER_DATABASE_URL を使用します。コーパスと信頼キーを再検証し、データベースの正確なメンバーシップ/状態/エポックを確認し、短命のリクエスト ID を返します。信頼キーは、指定されたパスと解決されたパスの両方がコーパスルートの外側に留まる、別のマウントでなければなりません。BDDK_RELEASE_VERIFIER_REVISION_SHA256 は 64 文字の小文字 16 進数でなければならず、BDDK_RELEASE_VERIFIER_IMAGE_DIGEST は sha256: ダイジェストでなければならず、BDDK_RELEASE_VERIFICATION_VALIDITY_SECONDS は 60–3,600 秒（デフォルト 900）に制限されます。パブリッシャーは、そのリクエスト ID と BDDK_RELEASE_PUBLISHER_DATABASE_URL のみを受け取ります。コーパス PVC、マニフェスト、署名、信頼キーは受け取りません:

BDDK_RELEASE_VERIFIER_DATABASE_URL='postgresql://VERIFIER:SECRET@HOST:5432/DATABASE?sslmode=verify-full&sslrootcert=%2FAPPROVED%2Fpostgres-ca.crt' \
BDDK_RELEASE_VERIFIER_REVISION_SHA256='REPLACE_64_LOWERCASE_HEX_REVISION' \
BDDK_RELEASE_VERIFIER_IMAGE_DIGEST='sha256:REPLACE_64_LOWERCASE_HEX_IMAGE_DIGEST' \
BDDK_RELEASE_VERIFICATION_VALIDITY_SECONDS=900 \
  uv run --frozen bddk-mcp verify-and-stage-corpus-release \
    --seed-dir /APPROVED/CORPUS \
    --trusted-signing-key /APPROVED/TRUST/corpus-signing-public-key.pem

BDDK_RELEASE_PUBLISHER_DATABASE_URL='postgresql://PUBLISHER:SECRET@HOST:5432/DATABASE?sslmode=verify-full&sslrootcert=%2FAPPROVED%2Fpostgres-ca.crt' \
  uv run --frozen bddk-mcp activate-corpus-release \
    --request-id corpus_release_request_sha256_REPLACE_64_LOWERCASE_HEX

アクティベーションは、リクエストが期限切れの場合、既に使用されている場合、またはコーパスの状態、エポック、準備状態が変更された場合にフェイルクローズします。資格情報の分離を維持するため、以前の publish-corpus-release エイリアスは無効化されています。

通常のマイグレーションは、台帳化前の未管理データベースではフェイルクローズします。--adopt-legacy は、実証済みのバックアップと レガシーアップグレードランブック の後の、正確にサポートされた構成のみを対象とする明示的なオプションです。クリーンインストールや一般的な修復フラグではありません。

データが投入されたバージョン 2 データベースも、デフォルトではマイグレーション 3 を拒否します。これは、検索公開バックフィルがブロッキングロックを取得し、外部キーを検証するためです。--allow-retrieval-publication-backfill は、ワークロードを停止し、復元可能なバックアップを証明し、サイズが一致した復元をリハーサルした後、管理されたメンテナンスウィンドウでのみ使用してください。BDDK_EXPECTED_DATABASE_NAME と独立した DBA スクリプトのターゲットは、アクティブなデータベースと一致している必要があります。分離されたローカル Compose 以外では、PostgreSQL DSN は sslmode=verify-full と絶対パスの sslrootcert を使用する必要があります。

テスト:

uv run pytest tests/test_tools_sections.py tests/test_doc_store.py -k section -v
uv run ruff check .

stdio 経由で MCP を実行:

BDDK_DATABASE_URL=postgresql://bddk:bddk@localhost:5432/bddk \
uv run --frozen bddk-mcp serve

Streamable HTTP を実行:

BDDK_DATABASE_URL=postgresql://bddk:bddk@localhost:5432/bddk \
MCP_TRANSPORT=streamable-http \
PORT=8000 \
uv run --frozen bddk-mcp serve

Streamable HTTP MCP エンドポイントは http://localhost:8000/mcp で、ステートレスな JSON 応答用に構成されています。リモートアプリケーションは、/.well-known/oauth-protected-resource/mcp で RFC 9728 の保護リソースメタデータを公開し、その 401 チャレンジは resource_metadata を通じて同じ URL を識別します。これはアプリケーションレベルの MCP 認可ディスカバリであり、銀行 IdP のクライアント登録やフロー受け入れの証明ではありません。固定されたコンテンツなしのプローブエンドポイントは、GET /health/live と GET /health/ready です。準備状態チェックは、マイグレーション、重要なカタログオブジェクト、コーパス公開、ワークロード ACL を定期的に再証明します。プローブは認証/ホストチェックをバイパスしますが、プロセスのレート制限と並行性受付の対象のままです。非ループバックバインドは、正確な Host/HTTPS Origin 許可リストと完全な JWT/JWKS 構成が提供されない限り、フェイルクローズします。パブリックプロファイルは bddk.read を必要とし、オペレータープロファイルは bddk.operator を必要とします。リモートオペレーター HTTP も、明示的な BDDK_OPERATOR_REMOTE_ENABLED=true のオプトインを必要とします。BDDK_HTTP_ALLOW_UNAUTHENTICATED は、ベアラー認証なしで非ループバックの公開読み取り専用バインドを提供する、サポートされている明示的なオプトインです。デフォルトでは未設定であり、未設定の間はフェイルクローズのデフォルトは変わりません。設定されている場合、BDDK_JWT_ プレフィックスが付いた設定とは組み合わせることができません。起動時に拒否され、問題のある変数が列挙されます。また、BDDK_OPERATOR_REMOTE_ENABLED に関係なく、非ループバックのオペレータープロファイルでは完全に拒否されます。オペレーターツールは認証付きかループバック専用のままです。認証なしのサーバーは OAuth ディスカバリをアドバタイズしません。WWW-Authenticate チャレンジはなく、well-known の OAuth ルートは両方とも 404 を返します。Host/Origin 許可リストに加えて、ボディ、並行性、レート制限は引き続き適用され、レートリミッターが主要な悪用対策になります。そのクライアントキーは BDDK_HTTP_TRUSTED_PROXY_HOPS（デフォルト 0）によって管理されます。0 の場合、リミッターは ASGI ソケットピアをキーとし、X-Forwarded-For を完全に無視します。オペレーター管理のリバースプロキシが n 台ある場合は、実際のホップ数を設定し、キーが結合された転送リストの右から n 番目のエントリになるようにします。使用できないものはすべて、ソケットピアにフォールバックするのではなく、共有の unknown バケットに縮退します。誤った値があると、リミッターは共有またはスプーフィング可能な状態になります。ボディ、並行性、および 1 分あたりのレート制御は、単一のアプリケーションプロセスに限定され、レプリカ間で共有される入り口レート制限ではありません。完全な仕様については、デプロイメントガイド を参照してください。

レガシーシードのインポート/エクスポートヘルパーは引き続き利用できます。新しいデプロイメントでは、準備状態の検証が含まれるため、bddk-mcp bootstrap を優先してください:

BDDK_INGESTION_DATABASE_URL=postgresql://bddk_local_ingestion:local-only-ingestion@localhost:5432/bddk \
uv run --frozen bddk-seed import

Claude 設定

リポジトリの .mcp.json は、リポジトリルートを作業ディレクトリとして起動する .mcp.json 互換クライアント向けの移植可能な stdio の例です:

{
  "mcpServers": {
    "bddk": {
      "command": "uv",
      "args": ["run", "--frozen", "bddk-mcp"],
      "env": {
        "MCP_TRANSPORT": "stdio",
        "BDDK_DATABASE_URL": "${BDDK_DATABASE_URL}"
      }
    }
  }
}

Codex 設定

Codex CLI と IDE 拡張機能は Codex MCP 構成を共有します。信頼できるリポジトリ内の ~/.codex/config.toml または .codex/config.toml に以下を追加し、cwd をチェックアウトパスに置き換えてください:

[mcp_servers.bddk]
command = "uv"
args = ["run", "--frozen", "bddk-mcp"]
cwd = "/absolute/path/to/bddk-mcp"
env_vars = ["BDDK_DATABASE_URL"]
startup_timeout_sec = 30
tool_timeout_sec = 60

Codex 内で codex mcp list または /mcp を使用して接続を確認してください。

Docker、Railway、OpenShift AI の境界については、docs/DEPLOYMENT.md を参照してください。

クエリ例

search_bddk_regulations(keywords="kredilerin siniflandirilmasi")
search_document_store(query="TFRS 9 kredi riskinde onemli artis")
get_bddk_document(document_id="mevzuat_22599", page_number=1)
get_document_section(document_id="943", section_type="ilke", section_ref="5")
search_document_sections(query="Karsilik Yonetmeligi Madde 9 TFRS 9")
get_bddk_bulletin(metric_id="1.0.1", currency="TRY", days=90)
analyze_bulletin_trends(metric_id="1.0.1", lookback_weeks=12)
get_regulatory_digest(period="week")

オペレーターワークフロー

文書品質スキャンを実行:

uv run python scripts/scan_document_quality.py --db --out-dir quality_reports --allow-failures

既知の品質障害を対象としたドライランのバックフィル:

uv run python scripts/backfill_quality_failures.py --dry-run

既知の失敗文書を 1 件再抽出:

uv run python scripts/backfill_quality_failures.py --doc-id mevzuat_21192 --execute

取り込みアイデンティティを使用して、既存の保存済み文書の document_sections を再構築:

BDDK_INGESTION_DATABASE_URL=postgresql://INGESTION:SECRET@HOST:5432/DB \
  uv run python scripts/reindex_document_sections.py --execute

同様に、品質バックフィル、同期、および再インデックススクリプトの実行には、BDDK_INGESTION_DATABASE_URL が必要であり、正確な bddk_ingestion 特権契約を検証します。これらをパブリックまたはオペレーターのDSNで実行しないでください。

オプションの取得テレメトリ:

BDDK_DATABASE_URL=postgresql://PUBLIC:SECRET@HOST:5432/DB \
BDDK_TELEMETRY_ENABLED=true \
BDDK_TELEMETRY_DATABASE_URL=postgresql://TELEMETRY:SECRET@HOST:5432/DB \
  uv run --frozen bddk-mcp serve --profile public

テレメトリはデフォルトで無効です。有効にした場合、その専用のLOGINは bddk_telemetry_writer のみを継承しなければなりません。起動時は、正確な列スコープのINSERTのみの契約を検証し、トレースの読み取り/変更やより広いメンバーシップを拒否します。サーバーは、レイテンシ、結果数、ドキュメントID、品質ラベル、関連性サマリーを tool_call_traces に書き込みます。クエリ/プロンプトテキストは、ハッシュと長さサマリーとして保存されます。生テキストは、BDDK_TELEMETRY_STORE_TEXT=true が明示的に設定されている場合にのみ保存されます。

アーキテクチャ

server.py                 Root shim → bddk_mcp/server.py
seed.py                   Root shim → bddk_mcp/ingest/seed.py
bddk_mcp/                 Main package
  server.py               FastMCP entry point and lifecycle
  core/                   configuration, DB identity, outbound HTTP, logging, models
  migrations/             Immutable global PostgreSQL migration ledger
  jobs/                   Durable operator-job models and PostgreSQL repository
  store/                  doc_store, vector_store, section_index, legal_ref
  ingest/                 client, data_sources, doc_sync, html_extractor, backfill, seed
  quality/                markdown_quality, quality_scan
  observability/          analytics, telemetry, metrics
  tools/                  MCP tool modules
  ocr/                    base, chandra (pluggable OCR)
scripts/                  Operator and backfill scripts
benchmark/                Tool schemas and benchmark infrastructure

データ品質と安全性に関する注意事項

• 規制文書とセクションの完全な取得レスポンスはローカルストアから提供されます。これらのパスは実行時にドキュメントをライブフェッチしません。

• カタログ更新、機関/公告の検索、および掲示ツールは、設定とキャッシュ状態に応じてBDDKのアップストリームサービスにアクセスできます。

• ライブ規制HTTPパスは、正確なBDDK/mevzuat HTTPSホスト、リダイレクト/DNS再検証、およびアーティファクトタイプごとのコード所有のストリーミング制限を強制します。リトライログはURL、クエリ文字列、例外テキストを省略します。公開機関ツール、公告ツール、掲示ツール、および更新ツールもライブのBDDKソースを呼び出す可能性があるため、OpenShiftのegress契約は、承認済みの規制ソースまたはプロキシのTCP 443をパブリックとオペレーターの両方のランタイムに許可する必要がありますが、ライフサイクルJobには許可してはなりません。DNS検証はDNS-to-connect競合を排除できないため、NetworkPolicyまたは承認済みプロキシ/ファイアウォールが引き続き必要です。

• デフォルトの埋め込みモデルは完全なコミット d13f1b27baf31030b7fd040960d60d909913633f に固定され、オプションのデフォルトリランカーは 1427fd652930e4ba29e8149678df786c240d8825 に固定され、不変スキーマは vector(768) のみを受け入れます。モデル/チャンク設定の変更には、管理された完全な再埋め込みと取得回帰テストが必要です。

• 取得パブリケーション記録は、チャンクの整合性、現在のコンテンツハッシュ、およびアクティブな取得プロファイルが検証を通過した後にのみ書き込まれます。不完全または古いインデックスが検索結果に暗黙的に混在することはありません。

• ブートストラップは、レビュー済みコーパスをマニフェストの正確なアーティファクトパスにバインドし、予約済みのシードファイル名によるバイパスを拒否します。別の verify-corpus 実行は診断用のプリフライトのみです。本番トラストゲートは、別途マウントされたトラストキーを使用して、同じ bootstrap 呼び出しに直接渡さなければなりません。deploy/openshift-overlays/bank-bootstrap は、リポジトリのプリフライトで、そのコマンド、読み取り専用の承認済みコーパスPVC、および別個の読み取り専用のコーパストラストSecretの正確なインベントリをチェックします。実際の銀行プロビジョニングとJobの実行は外部ゲートのままです。

• マイグレーションv0005は、追記専用のリリース/アクティベーション証跡と、17のコーパステーブルにわたるミューテーションエポックを追加します。厳密なローカルコーパス呼び出しは、実行の前後で同じアクティブリリースを検証します。マイグレーションv0008は、パブリッシャーの旧直接パブリケーション付与を廃止します。bddk_release_verifier はコーパス/トラスト素材を読み取り、厳密なメンバーシップを証明し、ベリファイアのリビジョン/イメージ来歴と60〜3,600秒のTTLにバインドされたリクエストをステージングします。bddk_release_publisher は、一度きりのリクエストIDのみをアクティベートできます。アクティベーションは、有効期限、再利用、取得準備、コーパスエポック、状態ハッシュを原子的に再チェックします。単一のプリンシパルが両方のロール（またはスキーマ所有者権限）にアクセスできると分離が崩れるため、銀行のSecret/RBAC管理は必須のままです。マイグレーションv0007は別途、パブリッシャーが retain-corpus-generation --expected-release-id ... を実行して、17の型付き保持リレーションにわたって正確なアクティブ状態を封印できるようにします。保持は、世代にバインドされた提供や再アクティベーションではありません。v7以前の非正規ハッシュの是正は、変更されていないv5/v6スキーマ上の正確でレビュー済みのパブリケーション専用互換性境界のままです。v7に到達した後は、v8への途中で定常状態のバイパスになってはなりません。現在のバイナリは publish-corpus-release CLIを無効化しています。歴史的な行やバインディングを決して作り出さないでください。承認されたアップグレード是正に従い、その後v8マイグレーションと付与を完了してください。追跡対象コーパスは署名されており、現在のプロファイルが再生成する9,675チャンクを宣言します。マイグレーションv0010は、正確に2つのフレッシュネスポリシー、quantified_measured_signature_verified_pass と明示的に弱い quantified_unmeasured_signature_verified_pass を許可します。両方とも定量化された目標と検証済み署名が必要です。ベリファイアはマニフェストの証拠からレベルを導出します。--accept-unmeasured-freshness は弱いレベルを許可しますが、それを測定済みとしてラベル付けし直すことは決してありません。

• マイグレーションv0004の11の所有者管理の法的キュレーションテーブルは、ソースコンテンツと取得アイデンティティを分離します。変更は所有者のみに限定されたままです。v0008は、リリースベリファイアに、パブリケーション証拠を再計算するために必要な正確な読み取り専用例外を付与します。v0006は、公開の棄権優先の resolve_regulation_status パスを追加します。合成された実PostgreSQLの証拠は、実際の規制ファミリーの最新性を確立しません。

• 評価ゲートには、4つの署名済みレイヤーが必要です。測定済みコーパス、専門家データセット、正確なCitationパックに対する法的キュレーターの証明、および保持されたソース/取得/ページ/抜粋履歴に対する法的リリースチェックポイントです。正規のコーパス/データセット/キュレーター/リリース署名者のフィンガープリントは異なっていなければなりません。現在のプリフライトは、オペレーター提供のアンカーの下での暗号整合性のみを証明します。銀行承認とモデルスコア承認は偽のままです。20ケースのセットはドラフトであり、キーローテーション、指名レビュアーポリシー、専門家ケースの実行は未解決のままです。

• サプライチェーン経路は、Buildxの --provenance=false --load を使用してコンテナをローカルでビルドします。フェイルクローズで、マニフェスト記述子/ダイジェスト、設定ダイジェスト、ロードされたイメージ、Syft SBOMを同じイメージにバインドします。リポジトリは別途、署名なしのSLSA来歴を作成し、モデルマニフェスト/ランタイム/Dockerfileのピン整合性を検証します。保留中の例外を適用する結果は、プロモーション対象になることは決してありません。銀行署名、アドミッション、レジストリプロモーションは外部ゲートのままです。

• ランタイムのwheel/sdistは、seed_data、ベンチマークコード、デプロイメントアセットを除外します。提供されるコンテナは、レビュー済みシードを明示的に含みます。wheelデプロイメントは、承認済みコーパスをマウントし、--seed-dir または BDDK_SEED_DIR をbootstrapに渡さなければなりません。

• 低品質の抽出結果は warning または fail としてマークされます。

• 数式が多い、またはOCR破損のあるドキュメントは、ソースPDFのレビューが必要になる場合があります。

• get_bddk_document は、モデルコンテキストの前にデータURI、生のHTML、選択されたOCRアーティファクトを削除します。

• モデルはツール出力のみから回答する必要があります。決定番号、日付、法的結論を捏造してはなりません。

• 既知の抽出問題、追跡対象の失敗リスト、バックフィルコマンドについては、docs/DOCUMENT_QUALITY.md を参照してください。

• 対象銀行のOpenShift AIクラスター、バックアップ/リストアプロセス、およびClaude/Codex/GPT/GPT-OSS/LM Studio/ローカルモデルのクライアントマトリックスは、このリポジトリでの受け入れテストをまだ完了していません。

開発コマンド

uv run pytest tests/ -v --tb=short
uv run ruff check .
uv run ruff format .

このプロジェクトでよく使用される重点チェック:

uv run pytest tests/test_markdown_quality.py tests/test_tools_documents.py -v
uv run pytest tests/test_legal_ref.py tests/test_section_index.py tests/test_tools_sections.py -v
uv run pytest tests/test_vector_store.py tests/test_legal_ref.py -v -rs

ライセンス

ソースコードは MIT License の下で配布されています。規制ソース文書およびその他の第三者データには、別途の来歴または再利用条件がある場合があります。コードライセンスは、それらの素材に対する追加の権利を付与するものではありません。確認済みの境界、未解決の決定、リリースゲートは、Licensing and Provenance に記録されています。