2 つのポリシーアーティファクト
2 つのアーティファクトはそれぞれ独立したバージョンを持ち、Rule Package が特定の Taxonomy バージョンを参照します（referential integrity）。グレード体系は比較的安定しているため、1 つの Taxonomy バージョンを複数の Rule Package バージョンが再利用する形が一般的です。
Taxonomy — グレード体系
v1.4 時点のグレードは 3 種です。
1 つの文書から複数グレードのシグナルが出た場合は最も高いグレードで確定し（highest-rank）、手動で付与されたグレードを自動判定が勝手に上書きすることはありません。グレード体系を Taxonomy として分離しているため、分類ルールはグレードを抽象的に参照でき、グレードの数・名称・基準が異なる顧客企業にも同じルール構造を使えます。グレードの意味と判定パイプラインについては、Stratum の概念を参照してください。
Rule Package — 3 層構造
Rule Package は、検出（何を）と判定（どのように）を 3 つの層に分離します。
各層を何からどのように埋めていくかは、Stratum Rule Package の作成を参照してください。Layer A のフィンガープリント detector は、プロジェクトに登録されたフィンガープリントテンプレートを参照します。
Guard Policy と同じ管理規律
Taxonomy と Rule Package の管理規律は、Guard Policy と同一です — 既存のポリシー運用方式をそのまま再利用します。Rule Package が Pin されていない Project Stratum は、何の判定も行わず、ファイルをそのまま通過させます。Guardian がポリシー未割り当ての状態で検査なしに通過させる動作と同じ、計画された状態であり、Pin を解除してもこの状態に戻ります。判定を開始するには、Rule Package を Pin する必要があります。
/aim テンプレートから始めて、プロジェクトが定義する
/aim（System）には、Stratum の policy type テンプレートがあります。各プロジェクトはこのテンプレートを標準の出発点として、自分の Taxonomy と Rule Package を定義します — Guardian が /aim の Policy Type Catalog（サポート集合）をもとに、プロジェクトが Guard Policy を定義するのと同じ方式です。つまり /aim はテンプレート（標準の出発点）を、プロジェクトは実際の定義・バージョン・Pin を管理します。
Taxonomy と Rule Package は任意の形式ではなく、定められたスキーマに従います。スキーマが入力検証とバージョン管理の根拠になります。policy type テンプレートは JSON と YAML の両方をサポートし（相互変換可能）、ポリシーモデルは YAML で定義されます。
管理の場所
権限
閲覧は Project Member 以上、Taxonomy・Rule Package の定義・編集と二次レビューの決裁には Project Admin 以上が必要です。ポリシーの作成・承認・有効化の役割分離（作成者 ≠ 承認者）は、既存のポリシーライフサイクルのロールモデルにそのまま従い、変更は監査ログに記録されます。次のステップ
Stratum Rule Package の作成
Layer A の detector、Layer B の分類ルール、Layer C のラベルポリシーを埋めていく実務ガイドです。
フィンガープリントテンプレートの登録・管理
フィンガープリント detector が参照する定型フォーマット（空の様式）の登録・改訂・再閲覧です。