proving-ground

Proving Ground — デモループ

Proving Ground: Design Thesis（2026年10月4日）のフェーズ2「デモループ」を実装したビルドです。 エージェントは顧客の財務オペレーションシステムの封印された複製を調査し、実行できる例外ワークフローを実証します。そして、各タスクを許可する検証器が、そのタスクの課金基準になります。

1. Twin ─────▶ 2. Explore ─────▶ 3. Propose
                                      │  exceptions become new tasks
4. Admit ─────▶ 5. Prove & price ──▶ 6. Operate & bill  ◀──────────┘

出力：out/proof_packet.md — ワークフローごとの証明パケット（月間処理量、現在の単位コスト、過去の未使用ケースでの合格率と95%信頼区間、既知の失敗モード、結果ごとの価格、実行中の計測結果）と、ブレーカーを通過した検証器を示す許可レポートです。

3つの設計ルールをコードで実現

ルール（論文）	場所
タスクは顧客の記録から生まれます。 実際の処理量を示す証拠がある場合のみ、候補が許可されます。	agents.propose では処理量と単位コストの提示が必要です。loop.explore ではすべての数値を /stats/exceptions と照合します。
エージェントが自分の仕事を採点することはありません。 提案者、ソルバー、検証器、ブレーカーは、それぞれ別のモデルファミリーを使います。	提案者は google/gemini-2.5-flash、ソルバーは openai/gpt-4.1-mini（ティア openai/gpt-4.1 と比較）、ブレーカーは deepseek/deepseek-chat-v3-0324、検証器はコード（policy.py）です。
証明はリプレイであり、判定者の意見ではありません。	loop.prove は、各ワークフローにつき過去の未使用ケース20件をサンドボックスのコピーで再実行します。policy.verify は、記録システムから必要な最終状態を再計算し、監査ログを確認して範囲外の書き込みがないか検査します。LLM が判定を行うことはありません。

ブレーカーは記録を参照できません。スクリプト化されたショートカット戦略と、書き込み専用ツールを持つ LLM で構成されています。（a）検証器が、過去のケースを人間が実際に解決した方法と90%以上一致し、（b）ブラインド戦略がそのタスクで70%に達しない場合にのみ、タスクが許可されます。vendor_bank_change は意図的に固定ルールの対照タスク（「保留してフラグを設定」）になっています。ブレーカーはこれをブラインドで通過するため、ゲートが結果ベースの価格設定対象から除外します。これがゲートの正しい動作です。

実行結果（results/、2026年10月5日、モデル利用料 $3.57）

ワークフロー	許可済み	価格設定ティア	リプレイ合格率（n=20、95% CI）	結果ごとの価格	実行中の計測
quantity_mismatch	はい	gpt-4.1-mini	100% [84–100]	$4.58	7/8
price_mismatch	はい	gpt-4.1-mini	95% [76–99]	$3.17	7/8
missing_po	はい	gpt-4.1-mini	90% [70–97]	$5.22	8/8
possible_duplicate	はい	gpt-4.1（mini：60%）	100% [84–100]	$2.02	8/8
unmatched_payment	はい	gpt-4.1	60% [39–78] — 契約基準未達	$5.72	6/8
vendor_bank_change	除外	—	ブラインドの「保留してフラグを設定」が100%合格	—	—

ゲートを通過しました（5つの検証器がブレーカーを通過）。未照合の支払いに関する結果は、有益な失敗の例です。両方のティアが合計額による照合に苦戦しており、パケットは価格設定を行わず、その事実を明記しています。 パケット全文：results/proof_packet.md。

ホスト型デモツイン

https://proving-ground-production.up.railway.app — 合成顧客、封印された API、トークンごとに1つのプライベートサンドボックスです。GET /policy と GET /schema は公開されています。それ以外はすべて、Authorization: Bearer <token> と X-Sandbox: <your actor> が必要です。例外に対応し、POST /exceptions/{id}/verify を実行してから、GET /proof を実行してください。docs/deployment.md と docs/billing.md を参照してください。

エージェントとして入る

アカウント不要、人間不要です。GET / がメニューです（JSON、ブラウザーでは HTML。/llms.txt と /.well-known/agent-card.json は、クローラーと A2A クライアント向けに同じ情報を提供します）。

# 1. take a seat: a bearer token (shown once), a private sandbox, free credits
curl -s -X POST https://proving-ground-production.up.railway.app/seat \
     -H 'Content-Type: application/json' -d '{"name":"my-agent"}'

# 2a. REST: send both headers on every call; reads are free, each resolve/escalate costs 1 credit
curl -s -H 'Authorization: Bearer <token>' -H 'X-Sandbox: my-agent' \
     'https://proving-ground-production.up.railway.app/exceptions?status=open&kind=price_mismatch'

# 2b. MCP: point any MCP client at /mcp with the same token (streamable HTTP, no X-Sandbox needed)
#     — or with no auth at all: `initialize` seats you and returns Mcp-Session-Id; that session IS a seat
#     (same free allowance, same x402 top-up), which is what directory listings that forbid static tokens need

ツールには MCP の title／annotations（readOnlyHint、destructiveHint、idempotentHint）が含まれ、最初に分かりやすい入口が来るよう並んでいます。 利用規約は /terms、プライバシー情報は /privacy にあります（いずれも草案であり、法的助言ではありません）。利用を開始すると、これらに同意したものとみなされます。 /openapi.json には、従量課金の操作に x-payment-info（x402scan／Bazaar 形式）が含まれ、info.termsOfService も記載されています。

各請求では、検証者の判定と請求額が返されます。GET /proof（または proof ツール）が証明パケットです。クレジットがなくなると、オペレーターが有効にしたチャージ方法（PG_TOPUP）を示す 402 Payment Required が返されます。決済手段によるチャージでは、管理者キーを使って POST /seats/{actor}/credit 経由で利用枠にクレジットを追加します。このメーターは、設計上、決済手段に依存しません。

実行する

pip install -r requirements.txt          # fastapi, uvicorn (everything else is stdlib)
python -m src.cli seed                   # deterministic synthetic AP twin: out/twin.db (12 months, ~8.7k invoices, 3,960 exceptions)
python -m src.cli selfcheck              # asserts: verifier agrees with history, truth stable, reopen/replay round-trips
python -m src.cli run-all                # explore → admit → prove → price → operate → packet (starts the API if needed)
python -m src.cli packet                 # re-render out/proof_packet.md

モデルへのアクセス：$OPENROUTER_API_KEY に OpenRouter キーを設定するか、~/.config/agent-integrity/openrouter.key に保存します。 モデルは環境変数で設定できます（PG_PROPOSER_MODEL、PG_SOLVER_MODEL、PG_BREAKER_MODEL）。一連の実行にかかるモデル使用料は約 2～3 ドルです。各呼び出しの実際の費用が記録され、「サービス提供コスト」に反映されます。

個別の手順：serve、explore、admit、prove [--alt]、price、operate、packet、cost。

ツイン

twin_api.py は外部との境界を封じ込めており、エージェントには HTTP 経由でのみアクセスできます。X-Sandbox: <name> で分離されたコピー（out/sandboxes/<name>.db）を選択し、すべての書き込みには X-Actor が記録されます。ハーネス専用の列（pre_state、post_state、truth、held_out）が提供されることはありません。

例外は 6 種類あり、それぞれに複数の結果が用意されているため、常に同じ回答では通用しません：price_mismatch、 quantity_mismatch、possible_duplicate、missing_po、unmatched_payment（銀行照合の不一致）、 vendor_bank_change。履歴はエージェントが使うものと同じ actions.py を通じて生成されます。また、検証結果と履歴の一致が 100% ではなく現実的なものになるよう、事務担当者による「マネージャーの上書き」が 3% の割合で発生します。

ponytail: ツインはオープンソース ERP の合成代替です。API の表面がアダプターの境界となるため、Odoo／ERPNext バックエンドも同じエンドポイントを実装できます。

ファイル

src/schema.sql    tables            src/policy.md   the customer's AP policy (served at /policy)
src/seed.py       synthetic twin    src/policy.py   expected outcomes + verifiers (code keyed to the system of record)
src/actions.py    all state changes src/twin_api.py sealed API
src/llm.py        OpenRouter + tool loop + $ tally     src/agents.py  proposer / solver / breaker
src/loop.py       admit / prove / price / operate / packet            src/cli.py  entry point
src/selfcheck.py  the one runnable check