> For the complete documentation index, see [llms.txt](https://docs.konvu.com/konvu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.konvu.com/konvu/triage-and-remediation/exploitability-assessment/reviewing-assessments.md).
# Reviewing Assessments
How to evaluate assessment results, provide feedback, and re-trigger assessments when your environment changes.
After Konvu completes an assessment, you should review the result and the supporting evidence together. This page covers how to evaluate what Konvu found, when to trust it, and what to do when you disagree.
## Evaluating a result
Open a finding's detail page to see its assessment. A useful review checks three things:
1. **The result.** Is it Exploitable, False Positive, Needs input, or Inconclusive?
2. **The evidence.** What data supports the assessment result? See [Reading an Assessment](/konvu/triage-and-remediation/exploitability-assessment/reading-an-assessment.md) for how to interpret each evidence type.
3. **The confidence score.** How strong is the evidence? High confidence means multiple evidence sources agree.
For most findings, the result and evidence will be clear-cut. Focus your review time on:
* **Exploitable findings** with high confidence. These are your priority. Verify the evidence makes sense, then move to remediation.
* **Needs input findings.** These have the highest return on your time. [Answer the questions](/konvu/triage-and-remediation/exploitability-assessment/answering-konvus-questions.md) to unlock a definitive assessment result.
* **Inconclusive findings.** Review the evidence to see what's missing, or answer any pending questions.
Low-confidence False Positives deserve a quick look at the evidence before you dismiss them.
## When to investigate further
Trust the assessment when:
* The confidence score is high and the evidence clearly supports the assessment result.
* Multiple evidence types (static, runtime, AI) agree on the assessment result.
* The reasoning references specific code paths, functions, or configurations in your codebase.
Investigate further when:
* The confidence score is low or the assessment result seems surprising given what you know about the code.
* The evidence references code you've recently changed.
* The finding is for a critical vulnerability in a sensitive component, regardless of the assessment result.
* The AI reasoning makes an assumption about your environment that you know to be incorrect.
## Rating an assessment
You can provide feedback on any assessment to tell Konvu whether you agree with the assessment result. This feedback improves future assessments.
From the finding detail page, use the agree/disagree buttons to rate the assessment. If you disagree, add a comment explaining why. This context helps Konvu learn.
## Decision audit trail
Every assessment-related action is recorded:
* Assessment results and the evidence at the time.
* Your feedback (agree/disagree) with comments.
* Dismissal actions and who performed them.
* Answers to Konvu's questions and who provided them.
You can view the assessment history on the finding detail page, which shows how the assessment result evolved over time as new evidence became available. This includes the assessment decision log:
```bash
konvu finding get --include logs
```
This audit trail is useful for compliance reviews and for understanding how a finding's assessment changed over time.
## Re-triggering assessments
You may want Konvu to reassess a finding after changes in your environment:
* You deployed a code change that affects whether the vulnerable code is reachable.
* You changed a configuration that affects exploitability conditions.
* You want to benefit from improvements to Konvu's analysis.
You can request a reassessment from the finding detail page. When a new assessment starts, the finding's status moves to **Ongoing** while preserving the previous assessment result for reference. See [How Assessments Work](/konvu/triage-and-remediation/exploitability-assessment/how-assessments-work.md#previous-assessment-results) for details on the lifecycle.
{% hint style="info" %}
Focus your review time where it matters most. Findings with a **Needs input** result have the highest return on investment. A single answer can resolve the assessment definitively. Exploitable findings with high confidence should go straight to remediation planning.
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.konvu.com/konvu/triage-and-remediation/exploitability-assessment/reviewing-assessments.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
