ELTON manages the full vulnerability lifecycle inside a change-controlled model of your device. Every status change writes the metric and the evidence at the same moment, so lifecycle management and metrics are one motion, not two systems.
A finding enters Needs Triage, gets verified on the real device, and closes as Fixed or Not Affected. The clock and the VEX record are written as it moves, not reconstructed later.
A view is ELTON's snapshot of one product state: architecture, SBOM, configuration, interfaces, trust boundaries, and code. Every status, rating, VEX reason, and metric is scoped to that view. Findings never move between views, they clone, and each clone carries its own EL ID.
Everything is allowed. Architecture edits, new findings, open and close in the same view. This is the CI/CD path, so a commit can open and close a finding without spawning a new view.
Change-controlled. The twin is locked and a finding here cannot be marked Fixed. Triage, Affected, and Not Affected still apply, and clones still flow out.
Read-only history. No edits and no new findings, but still a valid endpoint when a metric walks the clone chain to a resolution.
Every finding holds exactly one status: Identification, Needs Triage, Under Investigation, Affected, Not Affected, Fixed. There are two closures, and only two. There is no False Positive state.
The vulnerability was real and the fix ships in a specific version. Draft views only, which is exactly what makes "fixed in version X" a real, evidenced answer.
Real upstream, but this product is not exposed. It always carries one of five VEX reasons, so a dismissal is documented and exported, never assumed.
In a Release view, an Affected finding cannot be marked Fixed. To close it, you clone it into a Draft view and fix it there. That single rule is how ELTON answers, with evidence, which software version closed a vulnerability.
These are orthogonal to lifecycle. Any combination is valid, and all three dimensions export to VEX together.
Not Verified or Verified. It tracks whether test evidence backs the current determination, and any lifecycle change resets it.
None, Potential, or Confirmed. Only Confirmed satisfies the "inline mitigations already exist" VEX reason. Potential does not.
Evidence comes at L1 static reachability on the twin, L2 binary and code, and L3 live exploit on the device. L3 carries the most weight.
MTTT, MTTV, and MTTM are calculated per view. The same CVE produces different, independently correct numbers in v1.1, v1.2, and v1.3, because each view is a distinct software version with a distinct exposure window.
Time to triage. Starts when a finding enters Needs Triage, stops when it leaves. Once started it never resets on re-assessment.
Time to verify. Starts at triage exit, stops when verification flips to Verified without the status changing. We verify a status, not a finding.
Time to mitigate. Starts at Affected, stops at Fixed in the same Draft view, or when a downstream clone reaches Fixed or Not Affected.
Because every status, rating, verification result, mitigation, VEX reason, and clock is captured as the finding moves, the report is not assembled at the end. It is the lifecycle, read out.
Of everything open in a view, how much rests on test evidence rather than analysis alone. ELTON reports it per view and pushes it up.
Of everything closed as Fixed, how many closures have a PASS test proving the fix works. This is the number that survives an audit.
Watch one finding travel from discovery to a signed VEX statement, every transition evidenced along the way.