Compliance review of a vendor usually starts with discovery: what exists, where is it, who maintains it. For this platform, discovery is a table — everything reviewable is a public URL.
The nine pieces before this one each take a single obligation — model risk, records, communications, consumer protection, change control — and walk it in depth. This capstone is the opposite artifact: the whole reviewable surface on one page, organized the way a compliance function encounters it. Each row names the artifact, where it lives, and the review question it most often answers. The deep dives are linked where a row deserves an afternoon instead of a glance.
The map
| Artifact | Where it lives | The review question it answers |
|---|---|---|
| Model specifications | /docs/models/{model} and specUrl in every response | What does this compute, on what assumptions |
| Machine contracts | /api/v1/models/{model} | What inputs, domains, and constraints govern |
| Dual-implementation validation | /api/v1/evals/{model} — 250 re-runnable cases per model | How is correctness verified, and can we check |
| Facts registry | /facts and /api/v1/facts | Where do regulatory constants come from, and how fresh |
| Response envelope | Every API and MCP response | What did any given answer assume, cite, and compute |
| Decision record hash | The record field in each envelope | Can stored answers be proven unaltered |
| Public changelog | /models/changelog | What changed, when, why — the change-control record |
| Sentinel design | Catalog sentinels, annotated in envelopes | How are extreme outcomes represented honestly |
| Platform disclaimer | The disclaimer field on every response | What cautionary language ships by default |
| Aggregate telemetry | /api/v1/telemetry | What operational data exists — and what was never stored |
| Commercial terms | /pricing | What is committed in writing, and what is a conversation |
| Published answers to diligence | The answered questionnaire in this library | Where does due diligence start |
How to read the map by role
A model-risk reviewer starts at the specs, the eval datasets, and the changelog — the SR 11-7 mapping (/writing/sr-11-7-mapping) sequences that reading and names what stays the firm's to produce. A records owner starts at the envelope and its hash — the books-and-records piece (/writing/books-and-records-envelope) draws the line between the record format's properties and the storage layer's obligations. A communications principal starts at the assumptions surface, the sentinels, and the disclaimer — the fair-and-balanced piece (/writing/finra-2210-calculators) turns those into a review workflow. A consumer-protection reviewer starts with what the platform refuses to do — the silent-clamping analysis (/writing/udaap-silent-adjustment) explains why rejection-not-adjustment is the design's center. And an operations or audit owner starts with the replay procedure (/writing/audit-replay) and the annual review agenda (/writing/annual-model-review), which are the two recurring exercises the rest of the map feeds.
The property that makes the map work
Every row shares one trait: it can be checked without asking anyone's permission. A reviewer can open the spec, re-run the vectors, recompute a hash, diff the changelog, and read the registry's verification dates on any afternoon, before or after any commercial conversation, without an NDA. That trait — reviewability without negotiation — is the pillar's actual thesis. Obligations differ by charter and regulator; the artifact set that answers them is one platform surface, maintained continuously because the engine itself depends on it. The compliance function's discovery phase collapses into bookmarks, and the harder work — judgment about fit, scope, and the firm's own controls — gets the time discovery used to consume.
- Bookmark the twelve rows; they are the whole reviewable surface.
- Route each teammate to their row's deep-dive piece for the afternoon version.
- File the three named absences alongside the artifacts — an honest map includes what is not there.
- Re-capture the map at your annual review; everything on it changes visibly when it changes.
- Keep the judgment in-house — the map supplies evidence, never conclusions.
Sources
- [1] Worthune API documentation. https://worthune.com/docs
- [2] Worthune writing: SR 11-7 and the Verified-Model Stack: A Mapping for Model-Risk Teams. https://worthune.com/writing/sr-11-7-mapping
- [3] Worthune writing: The Vendor Due-Diligence Questionnaire, Answered. https://worthune.com/writing/vendor-questionnaire-answered