UCPA and TTI both run on the same foundation: ~92,000 mappings between security tools and framework safeguards. Here's how those mappings are produced, where AI is and isn't used, and what review workflow stands behind them.
The Dataset
Every coverage percentage, gap recommendation, and tool ranking in FrameworkMapper rests on the framework_mappings table — a relation between each tool in our catalog and the framework safeguards it can address. The table is populated programmatically; nothing in it is hand-edited in a spreadsheet.
Frameworks covered: CIS Controls v8.1, NIST CSF v2.0, NIST SP 800-53 Rev. 5 (323 base controls), NIST SP 800-171 Rev. 2, CMMC Levels 1 & 2, HIPAA Security Rule, and the Texas Cybersecurity Framework.
Mapping Strengths
Every mapping is classified into one of three strengths. The classification drives the weighted coverage math used everywhere coverage is reported.
The tool's primary capability addresses the safeguard. Selecting it is the canonical way to implement that control.
Example: An MFA platform mapped direct to CIS 6.5 (Require MFA for Administrative Access).
The tool contributes meaningfully to the safeguard but isn't the primary control. A complementary tool or process is usually needed.
Example: An EDR platform mapped supports to CIS 8.1 (Establish an Audit Log Management Process).
The tool touches the safeguard's domain loosely. A dedicated control is almost certainly required to fully meet the safeguard.
Example: A general SIEM mapped partial to CIS 17.4 (Establish and Maintain an Incident Response Process).
See How coverage is measured for the weighting math and the "mapping is not implementation" caveat.
How They're Produced
When a tool enters the catalog, an AI model researches its public-facing capabilities (vendor docs, product pages, third-party reviews) and produces a structured capability profile. The model is configurable per environment; today we use either Anthropic Claude (Sonnet 4.6 / Opus 4.7) or a self-hosted Open-WebUI model. The model choice is recorded with each generated record so historical decisions remain traceable.
For each (tool, framework) pair, a second AI pass classifies the tool against each safeguard in that framework. The output is a value in {'direct','supports','partial', null} plus a short rationale string. The classifier uses a versioned prompt template stored in the ai_prompts table — every edit to the prompt creates a new row in ai_prompt_versions so the prompt that produced a mapping can be retrieved later. Output values are server-side-validated against the enum before insert.
Newly generated mappings are persisted with status = 'pending' and surfaced in an internal review queue. Reviewers (Midwest Cyber and Viosoph security analysts) either approve the mapping unchanged, re-rate it (e.g., downgrade direct to supports), or reject it. Approval flips the status to 'approved' and stamps the reviewed_by / reviewed_at columns. Rejected mappings are deleted and the decision is fed back into prompt-template tuning.
Mappings are re-evaluated when (a) a source framework releases a new revision (e.g., CIS Controls v8.1 → a future v9), (b) a tool's product capabilities materially change, or (c) a customer disputes a mapping. The platform also runs an automated "drift" check that compares a tool's current capability profile against the profile that produced its mappings; significant drift requeues the tool for re-classification.
Review Status
We don't claim every mapping has been hand-validated. About half of the mappings in the catalog have been reviewed and approved by an analyst; the rest are AI-generated and still in the queue. The split below reflects the live dev catalog and is the same split that drives coverage math today.
| Framework | Approved | Pending review | Total | % Approved |
|---|---|---|---|---|
| CIS Controls v8.1 | 16,183 | 6,148 | 22,331 | 72.5% |
| HIPAA Security Rule | 4,349 | 4,041 | 8,390 | 51.8% |
| Texas Cybersecurity Framework | 4,072 | 4,619 | 8,691 | 46.9% |
| NIST CSF v2.0 | 4,791 | 6,109 | 10,900 | 44.0% |
| CMMC Level 2 | 5,628 | 7,588 | 13,216 | 42.6% |
| NIST SP 800-171 Rev. 2 | 5,138 | 7,401 | 12,539 | 41.0% |
| NIST SP 800-53 Rev. 5 | 5,076 | 7,822 | 12,898 | 39.4% |
| CMMC Level 1 | 1,320 | 2,239 | 3,559 | 37.1% |
| Total | 46,557 | 45,967 | 92,524 | 50.3% |
Honest disclosure: today's coverage math uses every mapping, approved or not.
The gap-analysis SQL filters by framework, not by review status. That means a customer's coverage % is computed using both approved mappings and pending AI-generated mappings. We chose this trade-off so coverage stays useful while review completes; the alternative (approved-only) would under-state coverage for newer frameworks. A future release will surface the approved / pending split per safeguard in the customer UI so the trade-off is visible at the row level.
AI Transparency
A clean line: AI helps us produce the catalog content. Every number a customer sees is deterministic and reproducible.
Buyers in compliance-sensitive verticals (CMMC, healthcare, federal) sometimes need to attest that AI isn't making scoring decisions on their behalf. This page is intended to support that attestation. If you need a more detailed disclosure for an audit, contact us.
Validate For Your Environment
Even the strongest direct mapping says only that a tool has the capability to address a safeguard. Whether it actually does in your environment depends on configuration, deployment scope, monitoring, and operational maturity — things the catalog can't see. The footer on every page of FrameworkMapper says this; the coverage caveat on every gap-analysis API response says this; we say it here too because it's the single most important framing for using the platform responsibly.