メインコンテンツへスキップ
月曜日により厳格な pii-shield ポリシーを出荷し、水曜日にチームメイトが regex を 広げ、そして今、実際のトラフィックが誤検知を投げています。あなたは何が変わったか、 誰が変えたか、そしてロールバックを — 以前の JSON を推測したり何かを再デプロイ したりすることなく — 確認する必要があります。それがガードレールのバージョニングが 与えるものです：変更ごとの履歴行、任意の 2 つの間の diff、ワンクリックの revert。 このページはバージョニングの面に焦点を当てたランディングページです。ガードレール エンジンそのもの — ルールの種類、ステージ、アクション — については、 ガードレール概要または完全な ガードレールリファレンスから始めてください。

​
1. ガードレールのバージョニングが記録するもの

ガードレールへのすべての変更 — create、update、delete、revert — は、変更と同じトランザクション内で追記専用の履歴行を書き込みます。行は、 その瞬間のユーザーに見える設定のスナップショットを捕捉します：
  • ガードレールの name、
  • それが enabled だったかどうか、
  • それがワークスペースの default だったかどうか、
  • 完全な rules ボディ。
各行は、単調増加する version 番号（1 から開始）、それを生成した operation、author、そしてタイムスタンプを持ちます。行は編集と トランザクション的に書き込まれるため、履歴がライブポリシーと同期を失って漂流する ことは決してありません — 編集がコミットすれば、その履歴行もコミットします。
履歴は追記専用です。revert は過去の行を巻き戻したり書き換えたりしません。 新しいバージョンを追記します（§4 を参照）。 あなたは常に、誰が何をしたかの完全なシーケンスを順番に見ることができます。

​
2. 具体例 1 つ — 不正な編集を見つけてロールバックする

ガードレール 42 が漂流したとします。これらすべてを自分のセッション上の コンソールから行います — sk-orca-... リレーキーは /v1/* 呼び出し専用で、 ポリシーの読み取りや変更には決して使いません。
1

履歴を一覧する

/console/guardrails でガードレール行の History を開きます。フィードは 新しい順です。v5 update（水曜日、チームメイトによる）、v4 update （月曜日、あなたによる）、v3 update、と v1 create まで遡って見えます。 履歴の読み取りは、任意のワークスペース Member に開放されています。
2

疑わしい変更を diff する

リグレッションを挟む 2 つのバージョン — v4 と v5 — を選んで diff を 表示します。rules ボディが並べて表示されるため、広げられた regex が変更 された行として浮き上がります。
3

Revert する

v4 を復元します。ライブガードレールの name、enabled フラグ、default フラグ、 rules がそのスナップショットに戻され、新たな v6 revert 行が追記されます。 変更は次のリクエストで反映されます — 再デプロイなし、SDK 変更なし。 revert には Developer+ ロールが必要です。
REST API での同じフロー、すべてセッション / アクセストークン上（決して リレーキーではない）、X-Workspace-Id でワークスペーススコープ： 
# 1. List versions (Member)
curl https://api.orcarouter.ai/api/guardrail/42/history \
  -H "Authorization: Bearer <session-token>" \
  -H "X-Workspace-Id: <ws-id>"

# 2. Diff v4 against v5 (Member) — returns both snapshots to render side by side
curl "https://api.orcarouter.ai/api/guardrail/42/history/diff?from=4&to=5" \
  -H "Authorization: Bearer <session-token>" \
  -H "X-Workspace-Id: <ws-id>"

# 3. Revert to v4 — appends a new "revert" version (Developer+)
curl -X POST https://api.orcarouter.ai/api/guardrail/42/revert \
  -H "Authorization: Bearer <session-token>" \
  -H "X-Workspace-Id: <ws-id>" \
  -H "Content-Type: application/json" \
  -d '{"to_version": 4}'
revert レスポンスはrevert 後のライブガードレールを返すため、UI は追加の ラウンドトリップなしにリフレッシュできます。このガードレールでスクリーニング される次の /v1/* 呼び出しは、復元されたポリシーを見ます。

​
3. 履歴、diff、バージョンフィード

GET /api/guardrail/:id/history はバージョン履歴を新しい順に返します。各 エントリは、そのバージョン番号、operation（create / update / delete / revert）、author、タイムスタンプを持つ 1 つのスナップショットです。フィードは ワークスペーススコープです — 別のワークスペースの呼び出し元は、欠落した ガードレールと同じ not-found エンベロープを受け取るため、存在が漏れることは 決してありません。
GET /api/guardrail/:id/history/:version はバージョン番号でひとつの スナップショットを取得します — revert するかどうかを決める前に、ある時点で ライブだった正確な rules ボディを検査するのに便利です。
GET /api/guardrail/:id/history/diff?from=N&to=M は両方の スナップショット — from と to — を返すため、コンソールは name、フラグ、 rules の並列比較をレンダリングできます。両方のバージョンがあなたの ワークスペースに属さなければならず、そうでなければ呼び出しは一律の not-found エンベロープを返します。
読み取り — 履歴一覧、単一バージョン、diff — は、任意のワークスペース Member に開放されています。それらは純粋な検査です：トラフィックについて何も変わらず、 モデルやベンダーの呼び出しも行われません。

​
4. revert は新しいバージョンとして復元する

revert は巻き戻しではありません。to_version ボディを伴う POST /api/guardrail/:id/revert：
  1. ターゲットバージョンのスナップショットをロードします。
  2. ライブガードレールの name、enabled フラグ、default フラグ、rules を、その スナップショットに復元します — アトミックに、ひとつのトランザクションで。
  3. 今ライブな状態を捕捉する新たな revert 履歴行を追記します。
そのため、v5 を v4 に revert すると、内容が v4 と等しい新しい v6 が 生成されます。あなたの履歴は v1 → v2 → … → v5 → v6(revert) と読めます — すべての ステップが保存され、何も変更されません。後でその古いスナップショットを再び revert すると v7 が得られ、以下同様です。
復元された disabled または non-default 状態は、そのまま往復します。 revert するバージョンが enabled: false だった、あるいはワークスペースデフォルト でなかった場合、revert はライブガードレールを正確にその状態に戻します — ポリシーを サイレントにオンのままにはしません。revert がそれらのフラグも反転させるか どうかを知るために、先に diff してください。
バインディングはゲートウェイに存在するため、revert はこのガードレールに アタッチされたすべての API キーを一度にシフトします — そしてこれがそうであれば ワークスペースデフォルトも — 次の呼び出しで。アタッチメントがどう解決されるかは キーにアタッチと ワークスペースデフォルトを参照してください。

​
5. ロールと保持

アクションルートロール
バージョンの一覧 / 読み取り、diffGET …/history、…/history/diff、…/history/:versionMember
バージョンへ revertPOST …/revertDeveloper+
すべての履歴ルートは /api/guardrail/* であり、X-Workspace-Id 下の セッション / アクセストークンで認証します — 決して sk-orca-... リレーキー ではありません。revert は、ライブトラフィックを変更するため、ガードレールの作成や 更新と同じ Developer+ ゲートを持ちます。
履歴は、ガードレールごとに最新 50 バージョンまで保持されます。編集を続けると 古い行は自動的に整理されるため、おしゃべりな編集ループのワークフローでも履歴が 無制限に成長することはありません。一覧エンドポイントは、最新 50 件まで、新しい順に 返します。
バージョニングをflag ファーストのチューニングと 組み合わせます：新しいルールを flag として出荷し、 Matches フィードを観察し、もし誤作動 したら、古いポリシーを手で再構築するのではなく、数秒で diff して revert します。

​
6. 次に進む先

出荷前にテストと eval

revert する必要があるバージョンになる前に、サンドボックスとコーパスで ポリシーを証明します。

誤検知のチューニング

バージョニングが安全にする flag-then-promote ループ。

アクション：block、mask、flag

バージョンがライブになると各ルールが何をするか。

ガードレールリファレンス

完全なエンジン — ルールの種類、ステージ、プリセット、そして完全な API。
ここでのバージョニングはガードレールコンテンツポリシーをカバーします。 ファイアウォールはツールポリシー向けの独自の変更面を持ちます。2 つの強制 レイヤーがどう異なるかについては、 ガードレール vs. ファイアウォールを 参照してください。