How Rokkhe validates a finding
Updated · By Rokkhe team
In a governed Rokkhe run, an agent that suspects a vulnerability cannot file it as a finding. It submits a hypothesis with its proof-of-concept and evidence. A separate validator agent, which cannot be the proposer, receives only the claim and the authorized targets, collects fresh evidence and decides. Rokkhe accepts the finding only when the validator reproduced it independently; otherwise the hypothesis is rejected or inconclusive, with a reason code.
What is a finding hypothesis?
A fully specified claim that has not been accepted yet. It carries everything a finding would: description, impact, target, technical analysis, the proof-of-concept and its steps, evidence, assumptions, counter-evidence, confidence, CVSS metrics and remediation. It also states a validation assertion: the observable result that would confirm it, in 20 to 2,000 characters. A hypothesis is capped at 512 KiB.
Who decides whether it is real?
A different agent, spawned with the validator role and assigned that one hypothesis. The tools enforce the separation:
- A validator cannot propose hypotheses, and a proposer cannot decide its own.
- The validator reads only its assigned hypothesis, and must read it before it may decide.
- It receives the claim and the authorized targets. The proposer's proof, evidence and conclusions are withheld, so it has to collect its own.
- An acceptance needs a rationale, the independent evidence and a reproduction log.
What can the validator decide?
| Verdict | Reason codes |
|---|---|
| accepted | reproduced_independently |
| rejected | not_reproducible, insufficient_evidence, out_of_scope, duplicate, expected_behavior, invalid_impact, unsafe_to_validate |
| inconclusive | environment_unavailable, budget_exhausted, ambiguous_result, blocked_by_scope |
A verdict with a reason code from another row is refused. An accepted hypothesis that turns out to duplicate an existing finding is recorded as rejected with the reason duplicate.
What happens to hypotheses that fail?
They stay in the run's validation ledger with their verdict, reason and evidence, and they never enter accepted findings. GET /api/finding-hypotheses lists the ledger by status: pending, in progress, accepted, rejected or inconclusive.
Does every run work this way?
Every scan a Rokkhe deployment launches in database mode is governed: it is bound to an engagement and a signed execution profile, and the hypothesis workflow is the only way to file a finding. A run without an execution profile, such as a local CLI run, files findings directly through the reporting tool. That tool still demands the proof-of-concept, evidence, counter-evidence, confidence and CVSS metrics and rejects duplicates, but no second agent reproduces the finding.
Why does validation matter after the fix?
Only a finding accepted as reproduced_independently can be retested, because the retest replays the proof that was accepted. /learn/how-a-retest-verifies-a-fix covers that step, and /docs/retests the details.