What Counts as a Finding
Strix's reporting layer answers a harder question than “did a tool return something interesting?” It asks what the evidence permits the system to claim, what it cannot yet claim, and how that distinction should survive into a developer's report. This chapter examines the candidate-closure model, the coverage ledger, and the report contract so readers can judge a Strix result without confusing a clean-looking output with a complete review or a high severity label with demonstrated impact.
The distinction matters because security work contains two kinds of error. A false positive wastes attention and can make teams distrust the process. A false negative disappears into the silence of an unexamined surface. Strix's design addresses both by making closure explicit: a candidate can be confirmed, ruled out by a specific control, or left open because proof is missing. The report and coverage artifacts then preserve not just what the agents said, but what kind of conclusion they reached.
Three ways to close a candidate
A candidate is strongest when a working proof of concept demonstrates the security consequence. Strix's guidance also allows a complete reachable source trace when runtime execution is genuinely out of reach, but that is a lower-confidence, explicitly qualified report rather than an equivalent to a live proof. It becomes a finding through the vulnerability-report interface. The report is expected to describe the affected target, technical mechanism, reproduction, evidence, assumptions, remediation, and severity. The important point is that reporting is tied to a consequence, not to the attractiveness of the hypothesis that led to it.
A ruled-out candidate requires a different kind of evidence. The tester must name the control, locate it in the relevant path or show it in observed behavior, and establish that it runs before the dangerous effect. “The framework probably escapes this,” “the endpoint returned 403,” or “a similar route is safe” is not enough. A control on a sibling route can leave the candidate alive; a check that runs after an object is fetched cannot explain why the object was protected. The negative conclusion is therefore a claim with its own proof obligation.
The third state is an open proof gap. The candidate is plausible, but the tester could neither confirm it nor identify a control that rules it out. Missing credentials, an unavailable internal service, a build that cannot run, or a context failure can all lead here. The absence of runtime proof lowers certainty; it does not create evidence of safety. Strix's coverage vocabulary calls for a follow-up outcome so the unresolved surface remains visible to the root agent and, ultimately, to the reader.
Coverage broadens this model from individual hypotheses to the surface that was actually reviewed. Its ledger distinguishes a finding reported, a surface on which no issue was identified, a candidate ruled out, a risk that does not apply, and a surface that requires further review. “No issue identified” means the area was tested without a reportable result. “Ruled out” means a named candidate has a specific control. “Not applicable” means the risk cannot arise on that surface. “Requires further review” means the uncertainty is genuine. Those outcomes should not be swapped merely to make the final dashboard look tidy.
The ledger is shared across the agent graph and is mutable in a controlled way. If two agents try to record the same surface and risk area, Strix rejects the duplicate rather than placing contradictory rows side by side. If later work resolves an earlier gap, it updates the existing row and keeps the previous outcome as history.