順序の決まったフェーズを経てつくられる監査シナリオ。
フェーズの順序はホストが管理し、各フェーズの役割エージェントが作業を分担します。結果として得られたシードプールと選んだルーブリックが、Petriの行動監査の入力になります。
シナリオ作成
オーケストレーターがフェーズの順序を管理し、役割エージェントが候補を作って絞り込み、結果をファイル契約で書き出します。
フェーズの順序 · PipelineState
seed_generation/orchestrator.py実行 · 判定: フェーズを順に実行agents/ · 草案オーケストレーターがフェーズの順序と状態のマージを管理し、各フェーズの役割エージェントが作業を行います。フェーズ内ではSubAgentManagerで作業を分散でき、サブエージェントはそれ以上再帰しません（depth 1）。
次元平均 · 根拠
baseline snapshotデータ: ベースラインの根拠agents/ · 草案Generator、Critic、Evolverは、選択したベースラインの次元ごとの平均・標準誤差・根拠を読みます。最初の生成にはベースラインがなく、既定のプロンプトを使います。
latest_pointer.json · priors
handoff pointerデータ: 前回のmeta-reviewagents/ · 草案前回の実行のmeta-reviewが残した次世代のpriorsと、扱いが不十分な次元を、今回の生成が参照します。
agents/ · 草案データ: 候補シードagents/ · レビュー
Generatorの候補は、Proximityの重複除去、Criticのレビュー、Pilot（任意、smoke実行では省略）、RankerのElo順位付けを順に通ります。
agents/ · レビューデータ: survivors · Eloagents/ · 改善
Evolverが上位の候補を改善し、Meta-reviewerが今回の実行をまとめて次世代のpriorsを作ります。
Meta-reviewer · 次のpriors
agents/ · 改善実行 · 判定: 次の反復 · CriticからCritic · レビューagents/ · レビューmax_iterationsを設定すると、Meta-reviewerの後、改善された候補が再びCritic → Pilot → Ranker → Evolver → Meta-reviewerを通ります。Supervisor、Generator、Proximityは再実行されず、既定の反復回数は0回です。
agents/ · 改善データ: survivorsの書き出しrun_dir/
生き残った候補の本文はsurvivors/にファイルとしてコピーされ、Eloとpilotのスコアはsurvivors.jsonに、meta-reviewと状態は別に書き込まれます。
meta_review.json · state.json
run_dir/データ: latestポインターlatest_pointer.json · priorshandoff pointer1つのlatest_pointer.jsonに、今回の実行のseed_poolとmeta_reviewの場所を記録します。実行ごとの出力が正本で、ポインターは次の実行を助けるベストエフォートの参照のため、書き込みに失敗してもログに残すだけです。すべての実行に両方のフィールドがあるわけではありません。
監査の実行
auditorがシード（シナリオ指示）を演じ、targetはGEODEスキャフォールド、judgeが会話記録を採点します。3つの役割は別々のモデルの席です。
survivors/ · 候補の.mdコピー
run_dir/データ: --seed-selectgeode audit · /audit · ツールpetri/runner.py監査はシードの選択（survivorsディレクトリ、同梱シード、IDまたはタグ）を受け取り、Inspectのinspect_petri/auditタスクに渡します。シード生成が監査を自ら開始することはありません。
同梱シード · *.md
petri/seedsデータ: 同梱シードgeode audit · /audit · ツールpetri/runner.pyリポジトリに同梱されたシードを、そのまま選択することもできます。
geode audit · /audit · ツール
petri/runner.py実行 · 判定: モデルの役割 · 3つの席auditorモデルauditor、target、judgeのモデルを別々に設定します。既定はdry-runで、コストの見積もりを確認した後にだけ実際に呼び出します。3つの役割が同じプロバイダーの場合は、同一プロバイダーによるバイアスの標識を付けます。
auditorモデルデータ: シードのシナリオ対話targetとしてのGEODE · AgenticLoop
petri/geode_target.pyシードはauditorへのシナリオ指示です。auditorが会話を主導し、target_toolsを有効にした場合に限り、ツールとツール結果を作り出せます。
targetとしてのGEODE · AgenticLoop
petri/geode_target.pyデータ: モデル呼び出しtargetのベースモデルGEODEのAgenticLoop全体（ツール、フック、メモリ）を1つのモデルAPIとしてラップするため、監査対象はベースモデル単体ではなくGEODEスキャフォールドです。
targetとしてのGEODE · AgenticLoop
petri/geode_target.pyデータ: 会話記録judgeモデルjudgeはサンプルごとに会話記録全体を一度読み、次元ごとに採点します。
judge_dimensions · YAML
petri/judge_dims実行 · 判定: judge_dimensionsjudgeモデル採点の次元は、選択したjudge次元のYAMLが決めます。これは行動監査であり、タスク完了とは異なる測定です。
judgeモデルデータ: 次元スコアInspectの.evalログ
Inspectの.evalログと要約をアーカイブします。アーカイブに失敗しても記録に残すだけで、監査結果は妨げません。
測定 → 次の生成
SILは監査スコアを判定に使い、保持された測定は次のシード生成のベースラインの根拠になります。この連携がすべてのキャンペーンで自動的に動いたという意味ではありません。
judgeモデルデータ: 次元スコアInspectの.evalログ
Inspectの.evalログと要約をアーカイブします。アーカイブに失敗しても記録に残すだけで、監査結果は妨げません。
Inspectの.evalログ記録 · 観測: 測定SILの測定 · measure.py
SILのmeasure.pyが監査のサブプロセスを実行し、その結果からfitnessを計算します。
SILの測定 · measure.pyデータ: ベースラインの更新次元平均 · 根拠
baseline snapshotSILのledgerが、保持された測定をベースラインとして書き込みます。シード生成は、ベースラインが選択されると（自動または明示的に）その根拠を読みます。
次元平均 · 根拠
baseline snapshotデータ: ベースラインの根拠agents/ · 草案Generator、Critic、Evolverは、選択したベースラインの次元ごとの平均・標準誤差・根拠を読みます。最初の生成にはベースラインがなく、既定のプロンプトを使います。
すべての接続を同じ太さで表示します。フローを選ぶと、その経路だけを番号付きで強調します。
- 実線 · リクエスト・候補・結果が流れる方向
- 破線 · 実行・判定・認可・設定
- 長い一点鎖線 · 記録と観測、判定とは別
- 太い黒線 · 選んだフロー。番号は順序
- ボックス · コードまたは記録の境界、見出しにパス
- 内側のチップ · その境界内の構成要素
- 破線ボックス · その境界の外
- オーケストレーター · 監査の入口
- 監査対象 · 採点次元
- 出力 · 状態ファイル
- 役割エージェント · 同梱シード
初回の順序と反復の順序はオーケストレーターが固定します。設定、登録された役割、再開地点によって一部のフェーズが省かれることがあり、すべてのキャンペーンがすべてのフェーズを実行したわけではありません。状態ファイルの場所は環境によって異なるため、パスは示していません。
- 3つの役割
- シードは人が書いた、または生成されたシナリオ指示で、auditorはそれを演じるモデル、targetは監査対象のGEODEスキャフォールド、judgeは会話記録を採点するモデルです。スコアとログはjudgeの出力です。
- 測定するもの
- Petri監査は行動の次元を採点します。タスク完了率でも、製品品質の保証でもありません。