Incident Status Automation: A Timeline That Could Run Backward
Blocking only the fully-finished case leaves every other invalid jump wide open
A status field that is meant to track a specific, real-world process — an incident moving through detection, investigation, mitigation, and resolution — implicitly promises more than just "this field can hold one of several values." It promises that the SEQUENCE of values a given record passes through actually reflects the sequence the real underlying process went through. A check that only refuses to change a record already in its single, fully-terminal state (here, `archived`) correctly protects that one specific case, but it says nothing at all about every other possible jump — including ones that make no operational sense, like moving a record backward from a more-resolved state to a less-resolved one, or skipping over steps a real investigation would never actually skip.
How the underlying problem shows up before you fix it
A status field intended to track a real, ordered process (triage, investigation, resolution) enforces only a check against its OWN single, fully-terminal end state — with no separate logic validating that any other requested transition is actually a legitimate next step from wherever the record currently stands.
A record that has reached a status widely treated elsewhere in the product as effectively 'done' (here, `resolved`) can nonetheless be moved BACKWARD to an earlier, less-resolved status, contradicting other data already recorded at the moment of that earlier transition (a resolution timestamp, linked follow-up documentation) without any of that other data being updated or invalidated to match.
The absence of an explicit, enumerated set of valid next-states for each current state means every possible transition is implicitly ALLOWED by default, rather than every transition needing to be explicitly permitted — an easy gap to leave open specifically because the code required to allow everything is simpler than the code required to allow only some things.
This class of defect produces no error and no obviously broken screen under ordinary, correct use — a person following the intended, forward-moving sequence never encounters the gap at all; it surfaces only for an accidental misclick, a stale cached button, or a deliberate attempt to move a record to an unintended status.
A record's own status is read and relied upon elsewhere in the product (reporting, postmortem workflows, dashboards) as an implicit guarantee about what has and has not yet happened — a status field that can silently move backward undermines every one of those downstream assumptions built on top of it.
Why guarding only the terminal state feels sufficient until a record moves backward
Writing an explicit check for one specific, clearly-understood condition — "this record has already reached its single, final, fully-done state" — is a natural, minimal first line of defense, and it correctly closes off the single most obviously wrong case (continuing to edit something that is supposed to be permanently finished). The gap is that a real process with several intermediate stages has many MORE invalid transitions than just "don't touch the finished one" — skipping stages, moving backward between two non-terminal stages, or reaching a stage out of its intended order are all separately wrong in ways a single terminal-state check says nothing about, and each of those additional gaps needs its own explicit rule rather than being caught incidentally by the one check already in place.
How Centriu Helix taught its incident timeline which way it is allowed to move
Centriu Helix's own internal incident-tracking service is used to record and follow a real operational incident's own lifecycle — from initial detection, through active investigation and mitigation, to resolution and an eventual postmortem. Before this fix, the service's only safeguard against an invalid status change was a check confirming the incident's CURRENT status was not already the single, fully-terminal `archived` state; any other requested transition, from any other current status to any other non-terminal target status, was accepted without further scrutiny — including jumps with no operational meaning at all, such as moving a `resolved` incident back to `open` or `investigating`.
The fix introduces an explicit table naming, for each of the service's own recognized statuses, exactly which next statuses are considered valid transitions from there. An incident generally moves forward through its own investigation sequence (`open` → `investigating` → `identified` → `mitigated` → `resolved`), with some legitimate lateral movement between the middle, actively-being-worked stages reflecting how a real investigation can genuinely move between identifying and mitigating a cause more than once before resolution. Critically, `resolved` is treated as functionally forward-only: an incident that has reached that status may only continue on to `postmortem` (adding retrospective documentation) or `archived` (fully closing it out) — it can never move backward to any earlier, less-resolved status, and `postmortem` itself may only proceed to `archived`. A status-change request naming any transition outside this explicit table is now rejected outright, with a specific error naming both the incident's current status and the invalid status that was requested, rather than being silently accepted.
What is actually built today
Centriu Helix's incident-tracking service enforces an explicit table of valid status transitions for every status an incident can be in, rejecting any requested change outside that table with a specific, named error.
A `resolved` incident can move on only to `postmortem` or `archived` — it can no longer be silently moved backward to `open`, `investigating`, `identified`, or `mitigated`.
The transition table reflects the actual, real-world sequence of an incident's own lifecycle, including legitimate lateral movement between the active, being-worked stages (investigating, identified, mitigated) that a real investigation can genuinely revisit before reaching resolution.
The service's original safeguard against modifying an already-`archived` incident remains fully intact, now expressed as one specific row of the same explicit transition table rather than as a separate, standalone check.
Every rejected transition attempt names, in its own error message, both the incident's actual current status and the specific invalid status that was requested, rather than a generic failure a person would need to independently diagnose.
A resolved incident that could still slide backward (illustrative framing of the actual confirmed mechanism)
Before the fix, an incident correctly marked `resolved` — with its own resolution timestamp recorded and a postmortem potentially already underway — could still be moved back to `open` or `investigating` by a request naming that transition, with no check rejecting it as operationally invalid. After the fix, the identical request is refused outright, with an explicit error stating that a `resolved` incident cannot transition to `open` or `investigating` — the only paths forward from `resolved` are `postmortem` and `archived`.
What changes operationally
Centriu Helix's incident-tracking service now enforces an explicit table of valid status transitions for every stage of an incident's own lifecycle, closing a gap where a `resolved` incident could be silently moved backward to an earlier, less-resolved status, contradicting its own recorded resolution timestamp and any postmortem documentation already built on top of it.
When this is not the right fit
This automation covers specifically Centriu Helix's own internal incident-tracking status transitions — an engineering operations tool, not a customer-facing feature. It is a distinct mechanism from this pillar's separate companion page on the same broader fix wave's approval-gate counting defect, which concerns how MULTIPLE approvals are tallied, not how a single record's own status field is allowed to change over time.
Guarding the terminal state alone vs. an explicit table of every valid transition
Checking only that an already-finished record cannot be edited further is the minimal possible safeguard, and it correctly closes the single most obviously wrong case with very little code. It leaves every OTHER transition implicitly allowed by default, including ones — like moving backward between two non-terminal stages — that make no more operational sense than editing a finished record does. An explicit table naming exactly which transitions are valid from each specific status inverts that default: nothing is allowed unless it is specifically named as legitimate, which is the only version of the two that actually enforces the real sequence a process like incident resolution is meant to follow, rather than merely protecting its one most obviously final state.
Related systems
Main system: Centriu Helix.
What it does NOT do
- Does not change what information is recorded at each stage of an incident's own lifecycle — the fix governs only which status TRANSITIONS are permitted, not the content captured at any individual stage.
- Does not overlap with this pillar's separate companion page on the same broader fix wave's approval-gate counting defect — that page concerns how multiple approval decisions are tallied; this page concerns how a single record's own status field is allowed to change over time.
- Does not retroactively identify or correct any specific incident record that may have already undergone an invalid backward transition before this fix shipped — the fix prevents the class of defect from recurring going forward; a team needing a historical review would need its own dedicated audit.
- Does not add any new incident status or lifecycle stage — the fix constrains movement between the module's existing, already-defined set of statuses.
- Does not extend this same explicit-transition-table pattern to any other status field in Centriu's other systems — this fix is specific to Helix's own incident-tracking service, confirmed to have this exact gap.
Security and governance
Centriu Helix's internal incident-tracking service now enforces an explicit table of valid status transitions for every stage of an incident's lifecycle, rejecting any transition outside it with a specific, named error — closing a gap where a resolved incident could be silently moved backward to an earlier, less-resolved status. Full detail on this module's operational and incident-response practices lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Was any real incident actually moved backward by this defect before it was found?
The finding describes the mechanism itself, confirmed and closed as part of a dedicated fix effort — it does not identify or claim a specific historical incident of misuse; a team needing that assessment would need its own dedicated review of past incident records.
What was the ONE safeguard that existed before this fix?
A check refusing any status change on an incident already in its single, fully-terminal `archived` state. Every OTHER transition — including operationally invalid ones like moving a resolved incident back to an earlier stage — was accepted without further scrutiny.
Can a resolved incident still be reopened at all, in any form?
A `resolved` incident can move on to `postmortem` (adding retrospective documentation) or directly to `archived` — but it can no longer transition back to `open`, `investigating`, `identified`, or `mitigated`, which the fix now explicitly rejects.
Is this the same finding as the approval-gate page on this site?
No — this page and that page come from the same broader fix effort but address genuinely different mechanisms: this one governs a single record's own allowed status transitions; the other governs how multiple approval decisions on a gate are counted.
Why is some lateral movement between non-terminal stages still allowed?
Because a real incident investigation can genuinely move between identifying and mitigating a root cause more than once before actually reaching resolution — the transition table reflects that real, legitimate back-and-forth, while still refusing genuinely invalid jumps like moving backward FROM a resolved state.
What does Centriu Helix cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Helix keeps an incident timeline moving only forward
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.