Documentation

Working with findings

A Dokima finding is the result of a review lifecycle, not a raw match from a single analysis pass. The report brings the outcome and supporting detail together so a developer can decide what to do next.

What a report includes

Published issues can include:

• a concise plain-English description;
• the full technical description;
• severity and confidence;
• verification status and verifier reasoning;
• repository, component and affected scope;
• evidence and relevant source locations;
• the attack path and practical outcome;
• plain-English and detailed remediation.

Not every field is equally certain. Read the verification reasoning and evidence alongside the severity label.

Active and dispositioned findings

New, valid and unresolved findings remain active in the report. A developer can record a disposition without editing the generated evidence.

Terminal dispositions include:

• fixed in code;
• accepted risk;
• mitigated;
• false positive;
• duplicate;
• not worth fixing.

These hide the issue from the active view while retaining its review history.

Findings that need human judgment

Needs review and Needs developer review are active states. They do not close the issue.

Use Needs developer review when the issue appears real and open, but the next decision depends on business logic, intended behaviour, an external control or another fact that a developer is best placed to judge. The rationale appears prominently in the issue view.

Discuss findings from the workspace

Run:

dokima chat

Dokima opens the configured interactive runner with generated context about the current findings and annotation workflow. Proposed annotations remain separate until they are accepted.

Refresh older report enrichment

If published findings are missing newer report fields, run:

dokima fix

This is a bounded repair pass. It fills missing report enrichment and regenerates the HTML; it does not run a new hunt, validation pass or complete Finding Review.