sumsub-create-aml-resolution-rules

Sumsub — AML 解決ルールの作成

簡潔な仕様から AML 解決ルールを作成し、エージェント API 経由でテナントのドラフト AML ルールチェーンに追加または更新し、（任意で）ドラフトを公開して有効にします。このチェーン（AML 解決ルールチェーンとも呼ばれます）は、受信した AML スクリーニングのヒットを自動審査します。各ルールは順番に、まだ審査されていないすべてのヒットに対して評価され、一致すると、そのヒットの審査結果（一致ステータス／リスクレベル／ホワイトリスト登録の有無／メモ）を設定したり、ケースにタグを付けたりします。

すべてのネットワーク処理は、1 つの署名付きクライアント ${CLAUDE_SKILL_DIR}/scripts/aml_rules_api.py（draft、published、archive、library、upsert、reorder、delete、publish）を通じて行います。ルールのペイロードは ${CLAUDE_SKILL_DIR}/scripts/build_aml_rule.py で組み立てます。

エンドポイント

すべて /resources/api/agent/amlResolutionRules 配下にあります。テナントごとにルールチェーンは1 つで、リビジョンは draft → published → archived の順にバージョン管理されます。（各行は aml_rules_api.py のサブコマンドに対応します。これらのパスを手動で呼び出すことはありません。）

メソッド	パス	サブコマンド	使用タイミング
GET	/draft	draft	編集可能なリビジョンを読み込みます。公開済みリビジョン（または空の状態）からドラフトを自動作成します。有効なテナントであれば 404 にはなりません。notices[] を含みます。
GET	/published	published	有効なリビジョンを読み込みます（まだ公開されていない場合は 404）。
GET	/archive	archive [marker]	リビジョン履歴をマーカー方式でページ分割して取得します。レート制限は 5 回／分です。ポーリングしないでください。
GET	/library	library	カテゴリ別にまとめられた、すぐに使えるルールテンプレートを取得します。
POST	/draft/rules	upsert	1 つのルールを追加または更新します。新規作成では id を省略します（チェーンの末尾に追加されます）。既存のルールを置き換える場合は、その id を指定します。レスポンスには、再計算された notices[] を含むドラフト全体が返されます。
PUT	/draft/rules/order	reorder	ルールの順序を変更します。本文 {"ruleIds": [...]} には、すべてのルール ID をそれぞれ 1 回ずつ含める必要があります。
DELETE	/draft/rules/{id}	delete <id>	ID を指定して、ドラフトから 1 つのルールを削除します。冪等です。ドラフトに存在しない ID を削除しても成功します。以下の同意ポリシーを参照してください。
POST	/draft/publish	publish	公開して有効にします。error レベルの通知が 1 つでもある場合は拒否されます。以前の公開済みリビジョンは自動的にアーカイブされます。

API 経由での公開は、統合フェーズで使用します。 統合が有効になったとみなされると、API は公開を拒否する場合があります（4xx）。その場合、チェーンは Sumsub の Web UI から人が確認して公開する必要があります。その段階での公開拒否は想定どおりの動作であり、回避すべきエラーではありません。拒否されたことを報告し、ユーザーに Web UI を案内してください。

通常の要件に加えて、トークンには次の要件があります。これらはエージェントエンドポイントのため、App Token はAI 用途（ダッシュボード UI の AI トークンページから作成）であり、manageAmlCases と manageClientSettings の権限を持つ必要があります。要件を満たさない場合の症状は次のとおりです。

• 403 "This endpoint is not allowed for this type of token" → トークンが AI 用ではなく、通常の App Token です。ユーザーに AI トークンを作成するよう依頼してください。
• すべてのエンドポイントで 404 "API is not available" → このテナントでは AML 解決ルール API が有効になっていません。直ちに停止してください。ユーザーに CSM または Sumsub サポートへの問い合わせを案内し、他のエンドポイントを再試行しないでください。

⚠️ 公開すると本番環境に影響します

AML Resolution Rule Chain は本番環境とサンドボックス環境で共有されています。隔離されるのは AML ケース／申請者のみで、チェーン自体は隔離されません。公開すると、実際の本番 AML スクリーニングのヒットを自動レビューするチェーンが変更されます（誤検知の解除、真陽性の確認、ホワイトリストへの登録）。サンドボックスの sbx: トークンを使っても安全にはなりません。公開するまではすべて安全です。ドラフトの読み取り、アップサート、並べ替え、ルールの削除はすべてドラフトにのみ作用し、公開されるまでは何もレビューしません。

そのため、公開するのはユーザーから明示的に依頼された場合のみにしてください。また、バックエンドに拒否される場合があることを把握しておいてください。チェーンが有効になった後（申請者がすでに多数処理されている／連携が完了している場合）、API は公開を拒否します（4xx）。これは想定どおりの動作であり、回避すべきエラーではありません。その旨を報告し、Sumsub の Web UI から公開するようユーザーに案内してください（「Endpoints」の注記を参照）。

認証 — App Token とシークレット（サンドボックスのみ）

このスキルは Sumsub の公開 API と通信し、 認証リファレンスに従って各リクエストに署名します。 認証の仕組みについての詳しい説明は sumsub-api-auth スキルにあります。401 Invalid signature が発生した場合は、そちらをお読みください。

⚠️ サンドボックスのトークンのみ使用してください。 ここでは本番環境の App Token を受け取ったり使用したりしないでください。これらのルールは実際の AML ヒットを自動レビューします。ユーザーから本番環境のトークンを提示された場合は、断り、https://cockpit.sumsub.com/checkus/home?sbx=true でサンドボックス用のペアを生成するよう依頼してください（Connect Sumsub to your AI agent -> Build & configure -> Generate token — 上記のとおり、このページでこれらのエンドポイントに必要な AI トークンが生成されます）。トークンとシークレットは一度しか表示されないため、ダイアログを閉じる前に両方をコピーしてください。aml_rules_api.py がこの要件を強制し、sbx: で始まらないトークンを拒否します。

変数	例
SUMSUB_APP_TOKEN	sbx:... — ダッシュボードで取得したサンドボックス用 AI App Token。
SUMSUB_SECRET_KEY	トークン作成時に一度だけ表示される、対応するシークレット。
SUMSUB_BASE	任意。デフォルトは https://api.sumsub.com です。

ユーザーが会話中にすでに認証情報を提供している場合は、それを再利用してください。 そうでない場合は、実行前に一度だけ確認してください。シークレットを決してそのままユーザーに返さないでください。

チェーンの実行方法（ルールを設計する際はこの点を念頭に置いてください）

1. ルールは上から下へ実行されます。順序が重要です。
2. 各ルールは、まだレビューされていないすべてのヒットに対して評価されます。モデレーションまたは前のルールによって matchStatus が設定されたヒットは、後続のルールではスキップされます。
3. ルールの効果は実行中にも反映されます。前のルールによって付与されたタグや再計算された screening.answer／screening.tags／screening.matchStatuses は、後続のルールから参照できます。これにより、ルールを連鎖させられます（ルール A が match_tin タグを付与し、ルール B が screening.tags containsAny ["match_tin"] に反応するなど）。
4. 具体的で判断が明確なルール（ID の一致、過去レビューの引き継ぎ）は、広範なクリーンアップルールより前に配置してください。広範な false_positive ルールを先頭に置くと、後続のより精密なルールが処理するはずのヒットを奪ってしまいます。

前提条件：AML スクリーニングが実際に稼働していること

このチェーンは、AML スクリーニングによって生成されたヒットに対してのみ動作します。スクリーニングが稼働していなければ、ルールは機能せず、評価対象もありません。特定の申請者レベルでスクリーニングを実行するかどうかは、独立した 2 つのゲートで決まります。

1. テナントの権限 WATCHLISTS — テナント全体に適用され、オンかオフのどちらかです。sumsub-check-permissions スキルを呼び出して確認してください。WATCHLISTS がある → AML スクリーニングを利用でき、すべてのレベルでデフォルトでオンです。WATCHLISTS がない → AML スクリーニングはテナント全体でオフです。申請者レベルの設定でオンにすることはできず、このルールチェーンがヒットを検知することもありません。
2. レベルごとのオプトアウト disableWatchlists — ゲート 1 を通過した場合にのみ関係します。そのレベルのトップレベルに disableWatchlists: true が設定されていない限り、スクリーニングは実行されます（クライアントがスクリーニング対象外にするレベルを指定する方法です）。これは sumsub-create-level スキルの対象であり、このスキルの対象ではありません。

WATCHLISTS 権限	レベルの disableWatchlists	そのレベルでスクリーニングは実行されますか？	チェーンはそのヒットに対して動作しますか？
なし	（任意）	いいえ — テナント全体でオフ	いいえ
あり	なし / false	はい（デフォルト）	はい
あり	true	いいえ — レベルでオプトアウト	いいえ

チェーンはテナントごとに 1 つで、スクリーニングが実行されるすべてのレベルのヒットに対して動作します。特定のレベルに限定されません。ルールを作成する前に（ステップ 0）、必ずゲート 1 を確認してください。WATCHLISTS がない場合、ここで作成する内容は権限が有効になるまで休止状態のままです。

タグは申請者ワークフローへの橋渡しになります

ルールタグは共通の申請者タグであり、AML 専用ではなくテナント全体で使われます。AML の実行内で連鎖するだけではありません。申請者ワークフローの条件にも、個人の場合は checks.personWatchlist.tags、企業の場合は checks.companyWatchlist.tags として表示されます。これにより、タグがルールチェーンとワークフロー間の引き継ぎ点になります。ルールチェーンで微妙な状況を検出し、ワークフローでそれに応じた経路に振り分けます。例：

1. AML ルール — 「ヒットに pep リスクラベルが含まれ、申請者が 30 歳未満」という条件に対し、タグアクション ["youngPep"] を設定します。
2. ワークフローのエッジ — checks.personWatchlist.tags に youngPep が含まれるかをテストする condition → 手動レビューのノード。

どちらのスキルも同じ Condition AST を作成するため（以下を参照）、2 つの側の記述はよく似ています。ユーザーの目的にスクリーニング後の振り分けやアクションが含まれる場合は、ここでタグを設定し、振り分け側については sumsub-create-workflow を案内してください。

手順

0. テナントで AML スクリーニングが有効になっていることを確認します（前提条件を参照）。sumsub-check-permissions スキルを呼び出し、WATCHLISTS がテナントで許可されているエンタイトルメントに含まれていることを確認します。含まれていない場合、テナント全体で AML スクリーニングがオフになっているため、このルールチェーンは実行されません。ユーザーにはその旨をはっきり伝えます（エンタイトルメントはユーザーの CSM／Sumsub サポートが有効にします）。そのうえで、先に進む前に明示的な確認を得てください。何も実行されないルールチェーンを黙って作成してはいけません。含まれている場合は、次に進みます。
1. ドラフトを読み取ります：${CLAUDE_SKILL_DIR}/scripts/aml_rules_api.py draft。これで利用可否も確認できます。404 "API is not available" または 403 が返された場合は、作業を中止して報告します（上記の「エンドポイント」を参照）。既存のルールを確認し、同じ意図のルールがすでにある場合は、重複を追加するのではなく、id を指定して更新することを提案します。upsert では名前による重複排除は行われません。変更を加える前に存在していたルール ID を記録します。削除に関する同意ポリシーを守るために必要です。
2. まずライブラリを確認します：${CLAUDE_SKILL_DIR}/scripts/aml_rules_api.py library。ユーザーの意図に合う既成テンプレートがある場合は、その rule 定義を基にします。id を取り除いて調整し、続行してください。テンプレートの vendors リストと、テナントが使用する AML ベンダーを照合します。
3. ルール仕様を記述します（下記）。condition は実際の Condition AST を直接記述してください。式のミニ言語はありません（条件の記述を参照）。input.entityType 条件を使って、ルールの対象エンティティタイプを指定してください（デフォルトは個人です。条件の記述を参照）。すべての exp パスがreferences/aml-rules-context-fields.mdに記載されていること、列挙型に基づくフィールドでは許可値がreferences/aml-rules-enumerations.mdに記載されていることを確認します。不明なパスがあると unknownField エラーノーティスが発生し、公開がブロックされます。
4. ${CLAUDE_SKILL_DIR}/scripts/build_aml_rule.py を使ってルールペイロードを組み立てます。標準入力に簡潔な仕様を渡すと、標準出力に完全なルール JSON が出力されます。ビルダーは薄いアセンブラーです。condition AST をそのまま渡し、レビュー／タグのアクションを組み立て、演算子／matchStatus 列挙型／emptyAction ガードを検証します。タイプミスや不正な AST があれば、ネットワーク呼び出しの前にここでエラーになります。
5. 解決済みのペイロードをユーザーに見せ、最初の upsert の前に明示的な確認を得ます。ルールの tags アクションで、まだ存在しないタグを追加する場合は、その点を明確に伝えてください。upsert により、テナント全体で使える申請者タグとして作成されます（ダッシュボードのフィルター、ワークフローなど、あらゆる場所で表示されます）。その名前を維持する価値があるか（明確で簡潔、再利用可能か）を確認するか、既存のタグを再利用してください。
6. ${CLAUDE_SKILL_DIR}/scripts/build_aml_rule.py < spec.json | ${CLAUDE_SKILL_DIR}/scripts/aml_rules_api.py upsert で upsert します。応答には、再計算された notices[] を含む完全なドラフトが返されます。複数のルールを作成する場合は、ルールごとに手順 3～6 を繰り返します。作成した各ルールにサーバーが割り当てた ID を記録してください。それによって、そのルールが自分の作成したものだと確認できます（手順 9）。
7. notices を確認します。error ノーティス（例：invalidTag、unknownField、unknownFunction）は公開をブロックします。ルールを修正し、その id を指定して再度 upsert してください。warning／info は参考情報としてユーザーに伝えます。references/aml-resolution-rules-schema.mdのノーティスキー表を参照してください。
8. チェーンの順序を設定します。 新しいルールは末尾に追加されます。評価順を変更する必要がある場合は、順序の完全な並べ替えを渡します：echo '{"ruleIds": [...]}' | ${CLAUDE_SKILL_DIR}/scripts/aml_rules_api.py reorder。
9. ルールの削除は、以下の同意ポリシーに従う場合に限ります。 ${CLAUDE_SKILL_DIR}/scripts/aml_rules_api.py delete <ruleId>。
10. 明示的に依頼された場合に限り公開します（「公開すると本番環境で有効になる」という注意を参照）：${CLAUDE_SKILL_DIR}/scripts/aml_rules_api.py publish。公開すると、ライブ環境とサンドボックスの両方で実際の AML ヒットに対してチェーンが有効になります。ユーザーから依頼がない限り、決して公開してはいけません。それまではドラフトは休止状態です。チェーンがアクティブになった後は、バックエンドが公開を拒否する場合があります（処理済みの申請者が多すぎる／インテグレーションが完了しているなど）。その場合は 4xx が返ります。これは想定内です。エラーを報告し、Sumsub のウェブ UI から公開するよう案内してください（「エンドポイント」の注意を参照）。
11. 報告します（ルール名を先に示し、ID だけを単独で示さないでください）。
    • 評価順に並べたルールチェーン（名前）、ドラフトの revision、ノーティスの概要。
    • ドラフト（編集可能）ビュー：https://cockpit.sumsub.com/checkus/sdkIntegrations/globalSettings/amlScreening?revision=draft&tab=amlRules&sbx=true
    • 公開済み（ライブ）ビュー（公開後）：https://cockpit.sumsub.com/checkus/sdkIntegrations/globalSettings/amlScreening?revision=published&tab=amlRules&sbx=true
    • どちらもクリック可能な Markdown リンクとして表示します。sbx=true はサンドボックスワークスペースを対象にします。
    • 最後に、専用の Rule id (for future updates / reorder): <id> 行を記載します。出力で生の ID を記載してよいのはこの行だけです。
    • 失敗時は、Sumsub の description／errorName をそのまま提示します。

ルールの削除 — 同意ポリシー

delete サブコマンドは、ドラフトからルールを完全に削除します（リビジョンとともにアーカイブされますが、編集可能なチェーンからはなくなります）。次の基準を適用してください。

• このセッションで作成したルール — 間違いだった場合、ユーザーから置き換えを求められた場合、または自分の作業を反復改善している場合は、自由に削除できます。通常は、id を指定してその場で更新するほうが、削除してから再作成するより適切です。ルールの位置を維持できるためです。ルール自体を本当に不要にする場合は削除してください。
• 自分が作成していないルール — 既存のルール、以前のセッションで作成されたルール、または人間が作成したルールは、そのルールについてユーザーから明示的な同意を得た場合に限り削除してください。削除前にルールの名前（name）を挙げて確認してください。チェーンを「整理」または「再構築」する際に、他の人のルールを付随的に削除してはいけません。
• ルールが自分のものかどうか不明な場合は、自分のものではないものとして扱い、確認してください。

削除は冪等であり、再計算された notices[] を含むドラフト全体を返します。削除後に notices[] を再確認してください（ルールを削除すると、残りのルールによって正当化されるタグやフィールドが変わることがあります）。

ルール仕様の形式（標準入力の JSON）

{
  "name": "Auto-clear hits with incompatible date of birth",   // required
  "description": "Optional free-form description",
  "id": "existing-rule-id",            // only when updating an existing rule

  // condition — the real Sumsub Condition AST, authored directly (see below).
  "condition": {
    "or": [
      { "and": [
        { "op": "ne",   "args": [ { "exp": "input.entityType" }, { "lit": "\"company\"" } ] },   // individual-only — scope every rule (see Authoring conditions)
        { "op": "eq",   "args": [ { "exp": "screening.vendor" }, { "lit": "\"complyAdvantageCSOM\"" } ] },
        { "op": "eq",   "args": [ { "exp": "match.dobs.hasData" }, { "lit": "true" } ] },
        { "op": "call", "args": [ { "exp": "dobsIncompatible" }, { "exp": "match.dobs" }, { "exp": "input.dob" }, { "lit": "\"weakContainment\"" } ] }
      ] }
    ]
  },

  // Review action — what to set on matched hits (every field optional):
  "review": {
    "matchStatus": "false_positive",   // unknown | potential_match | false_positive | true_positive
    "riskLevel": "LOW",                // vendor-specific — omit when unsure
    "whitelisted": true,               // accept the risk: allows approval despite the hit
    "note": "Cleared automatically: DoB mismatch"
    // OR the whole-review form (replaces all per-field keys):
    // "expression": "match.previousReview"   // carry over the previous screening's decision
  },

  // Tags added to the AML case when the rule matches. These are common applicant
  // tags (tenant-wide, usable everywhere — not AML-only). A tag that doesn't exist
  // yet is created automatically on upsert: prefer reusing an existing tag, and
  // name new ones clearly and concisely (e.g. "youngPep", not "rule3_tag"):
  "tags": ["auto_cleared_dob"]
}

ルールには review と tags のいずれか、または両方が必要です。どちらもない場合は、emptyAction エラー通知が返されます。レビューのフィールドにはスカラー値を指定できます（ビルダーが {lit} に JSON エンコードします）。または、値を直接計算する場合や指定する場合は、明示的に {"exp": "..."} または {"lit": "..."} を指定します。

作成条件

ルールの condition は、実際の Sumsub Condition AST を直接記述したものです。ワークフローのエッジ条件と同じ形式とルールに従うため、2 つのスキル間で整合性が保たれます。式のミニ言語はありません（以前の condition: "screening.vendor = …" 文字列と conditionRaw キーは削除されています。このビルダーはどちらも拒否し、この箇所を示します）。

⚠️ すべてのルールにエンティティタイプを指定してください。 個人と企業では照合対象のフィールドが異なり、結果の読み取り方も異なるため、一方を対象に作成したルールが他方では誤作動することがあります。各ルールには input.entityType 条件を必ず含めてください。ルールの意図から対象を推測し（個人名／生年月日／PEP シグナル → 個人、企業名／KYB シグナル → 企業）、判断に迷う場合は個人をデフォルトにしてください。

• 個人（通常のケース）：{ "op": "ne", "args": [ {"exp": "input.entityType"}, {"lit": "\"company\""} ] } — entityType ≠ company。
• 企業／組織：{ "op": "eq", "args": [ {"exp": "input.entityType"}, {"lit": "\"company\""} ] }。

意図的にエンティティタイプを問わないルール（まれなケース。例：「国 X のすべての sanctions ヒットをホワイトリストに登録する」）に限り、省略できます。ライブラリのテンプレートの多くには、すでにこの条件が含まれています。テンプレートを応用する場合も、その条件を維持してください。

{
  "or": [                                  // OR of AND-groups; first matching branch wins
    { "and": [
      { "op": "eq", "args": [ {"exp": "screening.vendor"}, {"lit": "\"complyAdvantageCSOM\""} ] },
      { "op": "in", "args": [ {"exp": "input.country"},    {"lit": "[\"BRA\", \"ARG\"]"} ] }
    ] }
  ]
}

• {exp: "<path>"} — 式のパスをそのまま指定します（references/aml-rules-context-fields.mdを参照）。比較の左辺であり、フィールド間のチェックでは右辺にもなります（{exp: "match.analysis.parentName"}）。
• {lit: "<json>"} — 文字列としてすでに JSON エンコードされたリテラルを指定します（API が保存する形式です）。例："\"complyAdvantageCSOM\""、"2"、"true"、"[\"pep\", \"sanctions\"]"。エンコードされていないリテラル（{lit: "BRA"}）は API に拒否されるため、エンコードが必要です。
• op は比較演算子のいずれかです（eq ne lt lte gt gte in notIn contains notContains containsAny notContainsAny containsAll containsOnly startsWith endsWith match empty notEmpty eqIgnoreCase …。すべての演算子はreferences/aml-resolution-rules-schema.mdを参照）。ビルダーは各 op が既知の演算子セットに含まれているか検証します。
• リストフィールドの集合メンバーシップ（match.riskLabels、screening.tags、match.complyAdvantage.matchTypes）：contains / containsAny は値を含むこと、containsAll は指定した値をすべて含むことを意味します。containsOnly は、指定した値以外を含まないことを意味します。「X のラベルのみ」に一致させる場合（例：有害メディアのみのヒット）は、containsOnly ["X"] を使ってください。列挙済みの値だけで語彙全体を網羅していると暗黙に仮定し、条件をすり抜けさせる notContainsAny [the-other-labels] は決して使わないでください（リスクラベルはちょうど6種類です。references/aml-rules-enumerations.mdを参照）。
• call は組み込み関数を呼び出します。これは、ワークフローにはない AML 条件の演算子です。最初の引数は {exp: "namesIncompatible"} のように関数名を指定し、残りはその引数です。例：{op: "call", args: [{exp: "dobsIncompatible"}, {exp: "match.dobs"}, {exp: "input.dob"}, {lit: "\"strict\""}]}。関数とシグネチャについては、references/aml-resolution-rules-schema.mdを参照してください。
• 否定には not* 演算子（notIn、notContains、notContainsAny、ne、notEmpty、…）を使います。negate フラグは設定しないでください。トップレベルの condition.negate は UI で未対応のため拒否されます。ワークフローのスキルと同じ仕様です。
• 日付：任意の Date フィールド（input.dob、match.previousReview.modifiedAt、match.sources.latestEndDate）では、.ageInDays / .ageInYears / .year などを利用できます。例：{op: "lt", args: [{exp: "match.previousReview.modifiedAt.ageInYears"}, {lit: "2"}]}。

Condition / And / Criterion AST 全体、リテラルのエンコード規則、演算子一覧、組み込み関数のシグネチャはreferences/aml-resolution-rules-schema.mdに記載されています。有効な exp パスはreferences/aml-rules-context-fields.md、列挙型フィールドの値はreferences/aml-rules-enumerations.mdを参照してください。どちらもreferences/aml-rules-expressions.mdから索引を参照できます。

使用例

• examples/minimal.json — リスクラベルに containsOnly を使う、タグのみのルールです。
• examples/auto-clear-dob-mismatch.json — call 関数とベンダーの一致タイプを使った例です。最も一般的な自動クリアの構成です。
• examples/reuse-previous-review.json — 日付の経過期間条件を含み、以前の判定を引き継ぐ、レビュー全体の expression 形式です。また、まれなエンティティ非依存ルールでもあります（以前の判定の引き継ぎは個人でも企業でも同じように読み取られます）。input.entityType フィルターが不要なのはこのケースだけです。

関連項目

• references/aml-resolution-rules-schema.md — レート制限のあるエンドポイント、すべてのフィールドと列挙値、条件 AST の構造、演算子の一覧、組み込み関数のシグネチャ、通知メッセージのキー、実行モデル。
• references/aml-rules-expressions.md — 式参照のインデックスと前文（ルート変数、applicant／Date の構造、列挙値に関する注意点）。以下の 2 つのデータファイルを参照します。3 つとも検索用データベースなので、最初から最後まで読む必要はありません。
• references/aml-rules-context-fields.md — 型を含む、exp のすべての有効なパス（## Types／## Index／## Functions）。
• references/aml-rules-enumerations.md — クローズド列挙型フィールドで許可される値（リスクラベル、照合ステータス、PEP 機関の種類、照合タイプなど）。
• sumsub-create-workflow — ワークフローのエッジ条件で同じ Condition ASTを作成します。式の参照には、applicant／applicantIdDoc の構造が記載されています。