How OpenDocket calculates risk scores and what they mean.
The OpenDocket Score is a relative risk pattern index from 0 to 100. A lower score means more high-severity risk patterns were found in the codebase.
It is a blind spot indicator for engineering teams.
OpenDocket uses a categorical risk classification based on the number of high-severity patterns found:
| LOW RISK | 0 high-severity findings | No immediate regulatory concern detected in code |
| MODERATE RISK | 1-5 high-severity findings | Targeted remediation recommended |
| ELEVATED RISK | 6-15 high-severity findings | Prioritize remediation before production |
| CRITICAL RISK | 16+ high-severity findings | Immediate attention required |
When the Gemini Verification Layer has run, classification is based on confirmed high-severity findings (not raw totals). This prevents documentation-only pattern matches from inflating the risk level.
OpenDocket uses a dual-model architecture — and this is the product differentiator.
Scans broadly — finds every pattern that could indicate a compliance risk. This produces a comprehensive set of findings but includes noise from documentation files, config references, and test data.
Gemini 2.5 Flash (Google) — Verification LayerChallenges each finding independently. It asks: is this evidence from actual application code? Would a regulator actually find this concerning? Is the severity appropriate?
The result is a tiered output:
The confirmed count is the number you should act on. The total count shows the full scope of what was examined.
Evidence is classified into three tiers based on file type:
A finding is only classified as High Risk if supported by at least two source code files with matching evidence. This prevents monorepos with extensive documentation from generating inflated risk assessments.