Interpret results

Verified 2026-09-18. A Deton result is scoped to the candidate and values asserted in its supplied records: proof plan, source-version label, environment label, attack family, oracle, and test-condition fields. The pure evaluator does not authenticate those assertions, live execution, or custody. No state is a general statement that an application is secure.

Candidate and pending states

candidate and proof_pending are presentation states, not proof verdicts.

Candidate confidence describes the detector's match confidence. It is not the probability that exploitation succeeded.

Canonical verdicts

The domain contract defines six terminal outcomes.

confirmed

Establishes: for the current evaluator, confirmed means that the evaluator accepted a supplied, identity-matching record through the configured publication, safety, redaction, sample, and actionability gates. It does not prove live execution, record authenticity, independent custody, persistence, delivery, or canonical publication.

Here, deterministic is a schema enum value. It is not statistical confidence, it is not certainty, and it is not repeatability, provenance, or attestation.

Does not establish: that unrelated paths, configurations, revisions, repositories, or vulnerability families are safe or covered.

Next action: inspect the supplied record and asserted revision, seek separate runtime and provenance evidence where required, apply a correction, add the proposed regression test, and plan a future retest under the stated conditions. Human and repository policy still decide whether and how a pull request is blocked.

not_exploitable

Establishes: not_exploitable remains schema-compatible, but its use requires a separately admitted bounded-refutation contract that the current evaluator does not provide.

Does not establish: that the candidate can never be exploited, that another path or environment is safe, or that the detector produced a false positive.

Next action: do not infer this state from a missing observation. Preserve any separately admitted bounded-refutation evidence and review its scope, prerequisites, alternate paths, and future retest conditions.

Public copy should prefer “not reproduced under tested conditions” when that is the exact evidence available.

inconclusive

Establishes: for the current evaluator, observed: false yields inconclusive with reason oracle_not_observed. More generally, the engine could not make a trustworthy positive or bounded-refutation decision. Causes can include missing execution, incomplete evidence, rejected noise, marker mismatch, insufficient samples, a redaction block, or a safety gate.

Does not establish: safe, fixed, not exploitable, or passed.

Next action: inspect the recorded reason, correct setup or evidence gaps, select a different authorized method, or route the candidate to human review.

unsupported

Establishes: the source, stack, family, or proof contract is not enabled for confirmation in this path.

Does not establish: that the vulnerability is absent, harmless, or outside the application's risk.

Next action: use an appropriate complementary review or testing technique. Do not invent a Deton verdict for a family without an approved proof contract.

out_of_scope

Establishes: the requested family or action is excluded from the authorized proof scope. The dashboard can present this under the neutral unsupported category.

Does not establish: absence or safety.

Next action: confirm authorization and scope. Use a separately approved process if the work is necessary.

error

Establishes: validation failed to complete as intended. The dashboard can present this under the inconclusive category.

Does not establish: evidence for or against exploitability.

Next action: inspect operational telemetry, repair the failing path, and rerun against an immutable source revision when authorized.

Publication and merge behavior

Only confirmed is eligible for the pure builder to construct an in-memory security-issue value, and only after configured checks accept the supplied fields. This does not establish persistence, attempted or successful delivery, or canonical publication; see Current availability.

Do not describe neutral as fail-closed merge enforcement. GitHub documents success, skipped, and neutral as successful statuses for required checks. An organization that wants inconclusive or unsupported results to block a merge needs a separate, explicit policy and implementation. See GitHub status checks and code-scanning merge protection.

Follow-up language

For a future negative retest, use this bounded wording:

The expected observation was not reproduced for the recorded source revision, fixture or environment, configuration, and proof-plan conditions.

Do not replace it with “fixed everywhere,” “safe,” “not vulnerable,” or “zero false positives.” If the previous environment cannot be reconstructed or the new evidence is incomplete, record inconclusive.

Reading an evidence packet

Before relying on a packet, verify that it names:

• the immutable source revision or fixture version;
• candidate, proof-plan, and oracle-result identities;
• the attack family and proof-contract version;
• the expected and observed oracle;
• sample, timeout, egress, seed, and identity requirements;
• redaction and forbidden-observation status;
• affected location and bounded impact;
• reproduction, remediation, bad-fix warning, and regression-test guidance;
• prospective retest criteria;
• limitations, evidence date, and reviewer.

Treat those names and values as supplied assertions unless separate evidence authenticates their origin, custody, persistence, and execution context.

Missing identity, scope, or safety fields weaken the interpretation. A screenshot or severity label alone is not a proof packet.

Why multiple techniques remain necessary

NIST's developer-verification guidance recommends complementary techniques and does not treat one method as total software assurance. OWASP ASVS similarly defines a broad, versioned basis for testing technical controls. Deton's bounded proof contracts can add evidence for enabled families; they do not replace code review, threat modelling, dependency review, architecture review, or other appropriate security testing.

• NIST IR 8397
• OWASP ASVS

Reporting a disagreement

Preserve the source revision, candidate, plan, observation, verdict reason, and redacted evidence. A disagreement should result in a traceable correction or a new reviewed result—not a silent change from an uncertain state to confirmed.