> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Stratum Rule Package の作成

> Layer A の検知器、Layer B の分類ルール、Layer C のラベルポリシーを、正しい順序で書き込み Stratum のグレード分類を意図どおりに動かします (Starfort v1.4 版)

[Stratum ポリシー管理](/ja/v1.4/admin/stratum-policy)が Taxonomy・Rule Package の構造とバージョン規律を扱うのに対し、このページは Rule Package の**内容**を扱います — 3 つの層を何からどのように埋めるか、そしてルール同士が衝突しないように優先度・確定・抑制をどう設計するか、です。

1 つの文書の判定は、3 つの層を順に通過します。

```mermaid theme={"dark"}
flowchart LR
    D["文書"] --> A["Layer A<br/>detector シグナル"]
    A --> B["Layer B<br/>分類ルール → グレード候補"]
    B --> C["Layer C<br/>ラベルポリシー → 最終グレード"]
    C --> R1["自動確定"]
    C --> R2["グレーゾーン<br/>（二次レビュー）"]
    C --> R3["ブロック"]
```

<Note>
  このページの YAML 例は、構造理解のための抜粋です。実際の作成では `/aim` が提供する **policy type テンプレート**を出発点とし、フィールド構成と検証はテンプレートのスキーマを基準にしてください。テンプレートは JSON と YAML の両方をサポートし、ポリシーモデルは YAML で定義されます。
</Note>

## 始める前に — まず Taxonomy から

Rule Package のすべてのグレード参照は Taxonomy から来ます。作成前にプロジェクトの Taxonomy（グレードの集合・順位・判定方式・しきい値）を先に確定し、Rule Package が参照するバージョンを決めてください。detector の grade attribution と分類ルールが emit するグレードは、いずれも**その Taxonomy バージョンに存在するグレード**でなければなりません。

## Layer A — detector: 何を検出するか

detector は特定のシグナルを検出する最小単位であり、各 detector は自分がどのグレードに寄与するか（grade attribution）を持ちます。判定パイプラインの段階ごとに性格が異なります。

| 段階     | detector  | 適した対象                                                                                 |
| ------ | --------- | ------------------------------------------------------------------------------------- |
| **L1** | フィンガープリント | 登録済みの[フィンガープリントテンプレート](/ja/v1.4/admin/fingerprint-templates)で作成された文書 — 確信度が高く、即時確定の根拠 |
| **L1** | 完全一致      | 事前登録された実データとの完全一致                                                                     |
| **L2** | パターン      | 形式が固定された定型の識別子（マイナンバー・カード番号など） — 検証ルールを伴う                                             |
| **L2** | キーワード     | ドメインキーワード — 文脈語の近接で信頼度を補強                                                             |
| **L3** | 意味ベースの分類  | 定型シグナルがなくても、文書の意味からグレードを推定                                                            |
| **L4** | 条項判断      | 境界ケースにおけるポリシー条項基準の判断 — 反対方向の証拠を含む                                                     |

```yaml theme={"dark"}
detectors:
  - id: det.pat_マイナンバー
    kind: pattern
    grade_attribution: 機密
    regex: '(?<!\d)\d{4}[-.\s]?\d{4}[-.\s]?\d{4}(?![-\s]?\d)'
    validator: mynumber_checkdigit
    context_words: [マイナンバー, 個人番号]
    proximity_chars: 250
    confidence_tiers: { format: 0.75, context: 0.85, checksum: 0.95 }
    action: mask

  - id: det.fp_契約申込書
    kind: fingerprint
    grade_attribution: 機密
    template_id: tmpl_契約申込書
    match_threshold: 0.8
    action: review_only
```

作成のポイント:

* **grade attribution はグレードごとに正確に。** detector が寄与するグレードが、Layer B の組み合わせと Layer C の集計の出発点になります。
* **パターン detector は「形式 + 検証 + 文脈」の 3 段構えに。** 正規表現には数字境界（`(?<!\d)`、`(?![-\s]?\d)`）を固定し、チェックデジットなどの `validator` は信頼度を引き上げる補強として、`context_words` + `proximity_chars` は文脈語が近接したときに信頼度を上げる段差（`confidence_tiers`）として使います。形式だけ一致したマッチと、文脈・検証まで通過したマッチを異なる信頼度で区別しておかないと、Layer B でしきい値条件をかけられません。
* **`action` は検出項目のマスキングの扱いを決めます。** マスキングでリスクが除去される項目は `mask` にしてマスキング版の再判定の対象とし、クレデンシャル類のように伏せてもリスクが残る項目や、それ自体は判断材料に過ぎないシグナルは `review_only` にします — マスキング不可の項目が残った文書はグレードが維持され、外部送信がブロックされます。
* **フィンガープリント detector は登録済みの様式を参照します。** `template_id` の指すフィンガープリントテンプレートがプロジェクトに登録されている必要があり、参照の有効性は Rule Package の有効化時点で検証されます。

L4 の条項判断は、グレード基準を自然言語の条項として定義します。含む・含まないの例で境界を引き、「すでに公開されている情報」のような**反対方向の証拠条項**も併せて用意します。

```yaml theme={"dark"}
clauses:
  - clause_id: cl.機密.審査基準
    grade: 機密
    title: 審査基準
    markdown: |
      審査ロジックや基準値が露出する内容であれば機密と判断する。
      - 含む: 判定基準表、基準値を含む社内マニュアル。
      - 含まない: すでに公表された基準の一般論。
```

L4 の判断は常に「レビュー必要」のシグナルとしてのみ作用し、それ自体がブロックやマスキングを直接下すことはありません。

## Layer B — 分類ルール: シグナルをグレード候補へ

分類ルールは detector のシグナルを組み合わせて、グレード候補を emit します。

| 要素           | 役割                                                                                    |
| ------------ | ------------------------------------------------------------------------------------- |
| `condition`  | detector シグナルの組み合わせ — `signal`（マッチ有無）、`compare`（件数・信頼度の比較）、`and` / `or` / `not`（否定条件） |
| `emit`       | 条件を満たしたときに出すグレード候補                                                                    |
| `priority`   | ルール間の評価優先度                                                                            |
| `terminal`   | 確定 — 該当グレードを即時確定させる強いルール                                                              |
| `suppresses` | 抑制 — このルールが発火したら、指定した他ルールの候補を無効化                                                      |

```yaml theme={"dark"}
rules:
  - id: rule.機密_申込書様式          # 登録様式で作成された文書 — 即時確定
    priority: 90
    condition: { op: signal, detector_id: det.fp_契約申込書, test: matched }
    emit: { grade: 機密 }
    terminal: true

  - id: rule.機密_pii検証             # 検証済みの個人識別情報 — 信頼度しきい値との結合
    priority: 80
    condition:
      op: and
      nodes:
        - { op: signal, detector_id: det.pat_マイナンバー, test: matched }
        - { op: compare, detector_id: det.pat_マイナンバー, field: confidence, cmp: ge, value: 0.85 }
    emit: { grade: 機密 }

  - id: rule.一般_マスキング加工版    # 否定条件 — 加工済みの文書は機密候補を抑制
    priority: 78
    condition:
      op: and
      nodes:
        - { op: signal, detector_id: det.pat_マスキング痕跡, test: matched }
        - { op: not, node: { op: signal, detector_id: det.pat_マイナンバー, test: matched } }
    emit: { grade: 一般 }
    suppresses: [rule.機密_pii検証]
```

設計のポイント:

* **確定（terminal）は確信度が 1 に近い根拠だけに。** フィンガープリントのマッチや完全一致のように、誤検知の余地がほとんどないシグナルが対象です。terminal を乱用すると、後段（意味分類・条項判断）とラベルポリシーが補正する機会が失われます。
* **しきい値条件は `compare` で。** 同じ detector でも、形式だけ一致したマッチと検証まで通過したマッチでは信頼度が異なるため、`field: confidence`（信頼度）や `field: count`（件数）の比較でルールの発火条件を絞り込みます。
* **否定条件で反対の証拠を反映してください。** 上の例のように、マスキングの痕跡があり、かつアクティブな PII がなければ加工版とみなして一般を emit しつつ、`suppresses` で機密候補を抑制します。L4 の反対方向の証拠条項（公表済み・公開確定）も、`not` 条件で機密の条項判定から除外できます。
* **priority は根拠の強さの順に。** 確定系を高く、単独では判断がつかない弱いシグナルは低 priority の下位候補としておき、グレーゾーンへの収束用に使います。

## Layer C — ラベルポリシー: 競合解消と外部送信のルーティング

ラベルポリシーは、Layer B が出したグレード候補を最終グレードとして確定し、外部送信のルーティングを決定します。

```yaml theme={"dark"}
label_policy:
  taxonomy_ref: my-company@1.0
  conflict_resolution: highest_rank
  manual_label_precedence: true
  routing:
    機密:   { low: 0.60, high: 0.85 }
    社外秘: { low: 0.60, high: 0.85 }
```

* **`taxonomy_ref`** — この Rule Package が参照する Taxonomy の特定バージョンです。
* **`conflict_resolution: highest_rank`** — 1 つの文書から複数のグレード候補が出た場合、最も高いグレードで確定します。単一の機微な区間が文書全体のグレードを引き上げ、低い側への誤分類を防ぎます。
* **`manual_label_precedence`** — 手動で付与されたグレードを、自動判定が勝手に上書きすることはありません。
* **`routing`** — グレードごとの確信度しきい値です。`high` 以上なら自動確定、`low` と `high` の間ならグレーゾーンにルーティングされ、人による二次レビューにつながります。外部送信不可の判定はブロックされます。

一般グレードはスコア型ではなく **clearance gate** です — 疑わしいシグナルがなく、判定が完了した文書だけが通過します。判定を完了できなかった場合（分析失敗・タイムアウト）は一般に格下げされず、fail-secure により安全側で処理されます。

## Taxonomy の参照整合性

* Rule Package が参照する Taxonomy バージョンは、`taxonomy_ref` で**固定**されます。Taxonomy を改訂して新バージョンを発行しても、既存の Rule Package は参照していたバージョンのまま動作し続けます。新しいグレード体系を使うには、`taxonomy_ref` を更新した新しい Rule Package バージョンを発行して Pin する必要があります。
* detector の grade attribution と分類ルールが emit するグレードが参照先 Taxonomy のグレード集合に存在するか、フィンガープリント detector が参照するフィンガープリントテンプレートとバージョンが存在するかは、スキーマ検証と有効化時点の検証の対象です。

## チェックリスト

* Taxonomy のバージョンを先に確定し、`taxonomy_ref` で固定したか？
* すべての detector に grade attribution を指定し、emit するグレードがすべてその Taxonomy に存在するか？
* パターン detector に数字境界と `validator`・文脈語による信頼度の段差を入れたか？
* マスキングでリスクが除去されない項目（クレデンシャル類）を `mask` にしていないか？
* `terminal` は、フィンガープリント・完全一致のような確信度の高い根拠だけに使ったか？
* 反対の証拠（加工版・公表済み）を否定条件と `suppresses` で反映したか？
* `routing` の `low` / `high` しきい値が、自動確定とグレーゾーンの境界を意図どおりに引いているか？
* フィンガープリント detector が参照する[フィンガープリントテンプレート](/ja/v1.4/admin/fingerprint-templates)が登録済みで、バージョンが有効か？

<Tip>
  作成を終えた Rule Package は、保存しただけでは適用されません。新しいバージョンを Project Stratum に **Pin** してはじめて判定に使われます — バージョン規律は [Stratum ポリシー管理](/ja/v1.4/admin/stratum-policy)を参照してください。
</Tip>