Accept or dismiss the impact review's exclusion

States a finding update may move this finding to now, in lifecycle order. Accepting risk is a separate exception workflow and never listed.

Deprecated for display: use conclusion_confidence. 0 whenever impact_conclusion is unknown, because there is no conclusion for a confidence to qualify.

Whether it touches an architectural object, which ones and why, from its stored impact review. linked follows a confirmed or rule-detected conclusion; possible names objects the review proposed without one; not_linked follows exclusion evidence; not_reviewed has no conclusion yet.

The business impact a person set: urgent, high, moderate or low, from the customers, data and services it would affect. Null until someone sets it.

Who set the business impact, when, their answers and their rationale.

For findings the Security Architect published: affected objects and relationships, observed and expected condition, violated rule, evidence, consequences, contextual severity, proposed action and remediation outcome.

Confidence in the impact conclusion, from 0 to 1, or null when impact_conclusion is unknown. For scanner findings it is the impact review model's own estimate for a conclusion the evidence gate accepted, and it is not calibrated.

States this finding may reach now only through a policy-exception request, which an independent Owner approves. Today that is accepting risk.

Which of the five result kinds this finding is: scanner_vulnerability, structural_finding, hypothesis, control_weakness or architectural_drift. It is orthogonal to impact_conclusion: a structural finding detected by rule reads rule_detected there, never confirmed.

A plain label for finding_class, such as Structural finding.

Which Findings group it belongs to: security (a scanner reported it, such as a vulnerable dependency) or architectural (the architecture analysis reported it: a structural finding, control weakness or investigation). It follows finding_class.

The architecture-impact conclusion the evidence allows: confirmed (the evidence-gated impact review accepted it, the same rule as the actionable filter), not_demonstrated (the gated review accepted exclusion evidence), rule_detected (a deterministic architecture rule matched; the impact review does not assess it) or unknown (no gated conclusion yet). Every view derives it from the same fields.

The impact review's decision on this finding that waits for a person: impact_exclusion (it excluded the open finding on evidence) or false_positive_automation (it closed the finding), or null.

One sentence on what the proof grade means for this finding.

How far the stored evidence goes: candidate (a rule matched), reachable (code evidence shows the affected code is used), observed (runtime or cloud evidence links to it) or verified (the evidence-gated impact review confirmed it).

A plain label for where the finding came from, such as Dependency vulnerability check. Show this to customers instead of tool.

The capability that observed the finding, such as dependency_vulnerability_check; Veriom's own sources keep their names (analysis, veriom-structural-engine).

The team's work on it (the collaboration status) on list and attention reads, or null when nobody has worked on it. The Findings page shows it in one status chip with state and lifecycle_state.