用途
Sumsub Conformance 用于回答一个具体问题：某个租户已部署的 Sumsub 配置，是否真正满足某份法规或政策文档？它把法规中的每一条要求沿着实时配置图谱进行追踪，并对每条要求依次回答：是否被收集 → 是否被评分 → 是否被强制执行。它独有的核心发现是「已收集但未强制执行」（COLLECTED-BUT-NOT-ENFORCED）：配置收集并评分了法规所需的数据，却没有对结果采取行动，例如一份适格性问卷被评分但从未被路由。
定位与限制
这是一个咨询式的差距分析助手，不是合规保证，也不能替代合规官。它确定性地验证配置可表达的部分，并诚实地界定其余部分：语义意图属于判断，SDK/平台结果超出范围。最终需要由人工签署确认。它不会验证语义正确性（例如某个问题的措辞在法律上是否充分属于判断范畴），也无法验证 SDK/平台/CRM 的结果（披露弹窗、演示账户、只读模式、25%/10% 限制、CRM 时间戳等），这些会被归入 NOT-CONFIG-REPRESENTABLE。
适用场景
- 已有客户：「这是我们的法规，这是我们的租户——实际强制执行了什么？」
- 使用 create-* 技能配置了 Sumsub 的新客户：闭合「生成 → 验证」环路，确认组装出的配置最终是否强制执行了它所依据的法规。
使用方式
该技能通过只读端点访问公开的 Sumsub API，所有请求经由 scripts/sumsub_curl.sh（App-Token HMAC）签名，resolve_graph.sh 对其封装。涉及的端点包括 Levels、Workflows、Questionnaire 内容与评分、PoA/交叉检查预设、Entitlements（allowedChecks 键）。
认证使用 App Token + secret，仅限沙箱。技能会拒绝不以 sbx: 开头的令牌；若用户提供生产 App Token，应拒绝并要求提供沙箱令牌。可选环境变量包括 SUMSUB_BASE / SUMSUB_ENV=dev。
标准流程分为若干步骤：先解析部署图谱（仅通过 resolve_graph.sh，若解析失败必须停止，不得绕过）；从法规中提取要求（判断步骤，需向用户展示并确认）；将要求映射到部署配置元素（判断步骤）；用 trace.py 确定性地追踪，产出 MISSING / SCORING-MISMATCH / COLLECTED-NOT-ENFORCED / NOT-CONFIG-REPRESENTABLE / CONFORMANT 分桶结论；可选执行卫生检查子流程（lint_config.py）；最后用 report.py 渲染固定格式的报告。所有产物必须写入源法规文件所在目录，并以文件名主干命名（如 <stem>_regulations.json、<stem>_config.json、<stem>_report.md）。
防护规则
- 将确定性事实与判断分开（basis 字段），绝不把映射猜测当作已验证的发现呈现。
- 追踪只走「要求 → 部署」方向，不会把已部署问题标记为「多余」。
- enforcementSignal 必须具有区分性，泛化令牌（如 country）会匹配兜底边并产生假 CONFORMANT。
- 诚实失败：绝不绕过解析失败；若出现认证错误 / 404 / 0 levels，应停止并如实报告，不得编辑脚本或从部分图谱编造报告。
相关与示例
相关技能 sumsub-analyze-regulation 处理相反方向（法规 → 构建计划）。references 目录包含 requirements-schema.md（要求模型与分桶）、conformance-method.md（五个步骤、防护规则、范围）、lint-rules.md（卫生检查规则目录）。示例包括 sample-requirements.json 与 sample-graph.json（合成样例，覆盖每种分桶）、fiu-india-vasp-mapped.json 与 vasp-graph.json（可离线追踪）、cfd-requirements.json（真实 CFD/MiFID 要求）、fiu-india-requirements.json，以及 audit-input{,-dirty}.json 等测试夹具。
具体定价、平台支持范围等信息暂未提供。