Sumsub Conformance

Sumsub — Conformance (regulation ↔ deployed config)

Traces every requirement of a regulation through the live config graph and answers, per requirement: collected? → scored? → enforced? The headline finding it surfaces — that nothing else does — is COLLECTED-BUT-NOT-ENFORCED: the config gathers and scores the data a regulation needs, then doesn't act on it (e.g. an appropriateness questionnaire that's scored but never routed).

This is an advisory gap assistant, not a compliance guarantee. It verifies the config-representable parts deterministically and honestly delimits the rest (semantic intent = judgment; SDK/platform outcomes = out of scope). Get a human to sign off.

When to use

• Existing client: "here's our regulation, here's our tenant — what's actually enforced?"
• New client who configured Sumsub with the create- skills: close the generate → verify* loop — did the assembled config end up enforcing the regulation it was built from?

Endpoints (read-only)

All via scripts/sumsub_curl.sh (App-Token HMAC). resolve_graph.sh wraps these:

Auth — App Token + secret (sandbox only)

This skill talks to the public Sumsub API and signs each request per the authentication reference. The how-it-works writeup lives in `sumsub-api-auth`.

⚠️ Sandbox tokens only. Read-only, but still: do not accept a production App Token. If the user offers one, refuse and ask for a sandbox pair at <https://cockpit.sumsub.com/checkus/home?sbx=true> (Connect Sumsub to your AI agent -> Build & configure -> Generate token). The helper rejects tokens that don't start with sbx:.

Procedure

Use the scripts — do not hand-roll the deterministic steps. The whole point of this skill is that resolution and the verdict are deterministic, not re-derived by eyeball each run: - Resolve the graph ONLY via `resolve_graph.sh`. Do not call /resources/... endpoints directly, list levels by hand, or strip the HTTP <code> trailer yourself — the script does all of that and emits one clean graph. - If the graph can't be resolved, STOP — never work around the failure. A 401/403, a 404, or 0 levels / "level not found" from resolve_graph.sh means the run cannot proceed. Report the failure plainly (likely a bad/non-sandbox token or wrong level name) and stop. Do not edit resolve_graph.sh (or any script) to route around the error, add a by-id fallback, retry a different endpoint, or otherwise improvise a graph — and never emit a report, bucket counts, or a CONFORMANT verdict from a partial or substituted graph. No resolved graph → no findings. - Derive the verdict ONLY from `trace.py` / `report.py`. Do not read the workflow/questionnaire JSON by eye and decide "enforced / not enforced" yourself — that re-introduces variance and hallucination. The COLLECTED-NOT-ENFORCED finding must come from the engine. - If a script already ran, trust its output — do not re-verify it with manual API calls. - To inspect the graph for the Map step, run `python3 scripts/graph_summary.py "$CONFIG"`. Do not hand-iterate the graph JSON: questionnaires/poaPresets/crossCheckPresets are dicts keyed by id (iterating yields id strings → 'str' has no attribute 'get') and entitlements is a list. graph_summary.py prints the section/item indices + scores you need, correctly. The agent's judgment belongs to two steps only: ingest (reading the regulation) and map (matching requirements to deployed config elements — questions, docSets, fields, countries, entitlements). Everything else is the scripts.

Artifacts — MANDATORY location & naming. Every run MUST write its artifacts into the same directory as the source regulation file, named from its stem (filename without extension). Never save in the cwd or under improvised names. Derive the exact paths once, up front: `` eval "$(python3 scripts/artifact_paths.py "<path/to/RegFile.pdf>")" # $REQUIREMENTS = <dir>/<stem>_regulations.json (the requirements you build in steps 1+3) # $CONFIG = <dir>/<stem>_config.json (resolve_graph output, step 2) # $REPORT = <dir>/<stem>_report.md (the rendered report, step 6) ` e.g. Level4regulations.pdf → Level4regulations_regulations.json, Level4regulations_config.json, Level4regulations_report.md. Use $REQUIREMENTS / $CONFIG / $REPORT` verbatim in the steps below.

1. Ingest the regulation (judgment). Just Read the document with the Read tool — it reads PDFs natively (renders pages + extracts text), so nothing needs to be installed. For a PDF over ~10 pages, Read it in page ranges (the Read tool's pages parameter, ≤20 pages per call). Reading visually is equal or better than a text extractor — it preserves tables, headings and layout that flat-text extraction loses. Optional, only if already installed and never a blocker: pypdf/pdftotext can pull a long, text-heavy PDF in one shot, and scripts/render_regulation.py (PyMuPDF) pre-renders a scanned/image-only PDF to PNGs for explicit DPI control — see `references/conformance-method.md` step 1. If a library is absent, just Read the PDF directly. Then extract requirements and write them to `$REQUIREMENTS` (the <stem>_regulations.json beside the source — see the Artifacts rule above), per `references/requirements-schema.md`: each = {id, source, text, type, enforceable, …}. Always capture `source` — the citation into the original document (section number / heading / page, e.g. "§5.9.2", "Section 2 — Scoring Result", "p.21"); the report leads with it so findings trace back to the regulation, not to an artificial id. Mark outcomes that live in SDK/platform/CRM as enforceable: sdk|platform. Show the extracted requirements to the user and confirm before tracing — this is the highest-risk step.
2. Resolve the deployed graph (deterministic). bash scripts/resolve_graph.sh <levelNameOrId> > "$CONFIG" (level + questionnaires-with-scores + presets + auto-found workflow + entitlements). This one command replaces any manual level-listing / curl / HTTP-trailer stripping — don't do those by hand.
3. Map (judgment). First inspect the graph: `python3 scripts/graph_summary.py "$CONFIG"` — it prints questionnaires with [section]/[item] indices + option scores, docSets, APPLICANT_DATA fields, geo, entitlements, and the workflow (don't hand-iterate the JSON). Then for each requirement pick the right type and fill its match — not everything is a questionnaire question. The per-type match shapes are in `references/requirements-schema.md`:

• questionnaire question/score → match: {questionnaire, section, item} (+ expectScores);
• document collected → match: {docSet: "IDENTITY", types: [...]};