The Triage Log and restoring decisions

What the Triage Log is

A working restoration business generates a steady stream of decisions: a stale receivable, a carrier that has gone quiet, a plan nobody has touched in weeks. Left alone, that stream piles up into hundreds of open items and the Action Plans and Decisions pages stop being useful. Verinode keeps the list workable by auto-archiving decisions that no longer need your attention, on a schedule, using rules and, for the gray-zone cases, a weekly agent pass.

The Triage Log is where every one of those auto-archives shows up, with the reason attached, so nothing Verinode set aside disappears without a trace. Every entry can be restored with one click. Verinode never deletes a decision on its own and it never decides anything is settled without telling you why; it only moves items out of your immediate view and keeps a full record so you can put any of them back.

Where to find it

Open Action Plans from the sidebar (/actions). In the top-right of the page header, next to Workload and Run analysis, there is a Triage Log link. Click it and the log opens as a card on top of the page, no navigation away from what you were doing. The same link and the same overlay appear on the Decisions page.

A standalone full-page version also exists at /decisions/triage-log, built from the same data, for anyone who wants a direct link or a full-width view instead of the overlay.

What you see when it opens

The summary line

Across the top of the Triage Log, four counts:

• Last 7 days: how many decisions the system archived in the past week.
• Last 30 days: the same count over the past month.
• By rule engine: of the last 30 days' archives, how many were caught by Verinode's nightly deterministic rules (age-based idle timers, expired items, and duplicates).
• By agent: of the last 30 days' archives, how many came from Verinode's weekly agent pass, the pass that reviews the harder, gray-zone cases a fixed rule cannot call cleanly.

These four numbers are a quick temperature check: a rising 7-day count against a flat 30-day count means archiving has picked up recently, and a heavy "By agent" share means more of what got set aside was a judgment call rather than a straightforward idle timer.

The row list

Below the summary, every decision the system archived in the last 60 days, most recent first. Each row shows:

• A colored dot for severity: gray for Info, yellow for Warning, red for Critical, the same severity coding used throughout Decisions.
• The decision's title, exactly as it read before it was archived.
• A reason label, explaining why the system set it aside. The reasons you will see are:

| Reason label | What triggered it | |---|---| | Low-impact, idle 30+ days | An Info-severity decision that sat untouched past 30 days | | Mid-impact, idle 60+ days | A Warning-severity decision that sat untouched past 60 days | | Parked, idle 90+ days | A parked decision that sat untouched past 90 days | | Past expiration | The decision passed its own expiration date | | Duplicate of newer signal | A newer decision superseded this one | | Agent: low priority this week | The weekly agent pass judged it not worth surfacing this week | | Agent: stalled plan | The weekly agent pass judged the plan behind it had stalled with no progress |

The first five reasons come from the nightly rule engine; the last two come from the weekly agent pass. That split is exactly what feeds the "By rule engine" and "By agent" counts above.

• The domain, if the decision belonged to one (Margin, Carriers, Jobs, and so on), and the entity name it was tied to (a client, a carrier, a job), when either is known.
• How long ago it was archived: shown in hours for anything under a day, then in days, then weeks (up to nine weeks), then months.
• "Restored before", in yellow, if you have restored this exact decision from the Triage Log at least once already. Treat a repeat appearance of the same restored item as a signal that a particular rule may be running too aggressively for how you actually work, worth a second look at whether that item genuinely doesn't need attention or keeps getting swept up by mistake.
• An italicized note in quotes, only on agent-archived rows, the free-text reasoning the weekly pass gave for setting that item aside (for example, why it judged a plan stalled).

The Restore button

Every row ends with a Restore button. Click it and:

1. The button reads Restoring… while the request runs.
2. On success, the row disappears from the list immediately, no page reload, and the decision returns to your open Action Plans / Decisions list at its prior state.
3. On failure, the row stays in place and an error message appears under it in red (for example, if the decision was already restored by another click, or if something else changed it in the meantime).

Restoring is fully reversible in the other direction too: nothing about a restore stops the same decision from being auto-archived again later if the underlying condition (still idle, still expired) still applies. Verinode keeps a record of every prior archive-and-restore round trip on that decision, which is what powers the "Restored before" flag.

1. 1Open Action Plans (or Decisions) and click Triage Log in the top-right of the page header.
2. 2Scan the summary line: Last 7 days, Last 30 days, By rule engine, By agent.
3. 3Read down the row list. Each row's reason label tells you exactly why the system set that decision aside, and the time-ago tells you how long it has been out of view.
4. 4If a row still matters, click Restore. It returns to your open list immediately and the row disappears from the log.
5. 5If a row reads "Restored before," treat that as a hint that whatever set it aside the first time may be firing on this one too readily.

Empty and loading states

While the overlay is loading, it reads: "Loading the triage log…"

If the load fails, it reads: "Couldn't load the triage log. Try again."

If nothing has been archived in the last 60 days, the row list is replaced with: "Nothing has been auto-archived recently. Triage runs nightly, check back tomorrow." That is the expected state for an operator whose feed is genuinely current, it does not mean anything is broken.

How this fits the rest of Decisions

The Triage Log is the housekeeping layer underneath everything else in the decision workspace. Decisions arrive in the Feed, you work them from Action Plans, and once a decision is genuinely stale, expired, superseded, or judged low priority by the weekly agent pass, it moves here rather than cluttering the list you actively work from. See acting on decisions for how a decision moves from a plan to done in the first place, and how that differs from the operator-initiated dismiss and ignore actions that never touch the Triage Log at all.

Best-practice example

Say you open Action Plans on a Monday and the Triage Log shows Last 7 days: 6, Last 30 days: 22, By rule engine: 19, By agent: 3. Scanning the rows, most are "Low-impact, idle 30+ days" or "Past expiration," routine housekeeping you'd expect on any active week. Two rows are "Agent: stalled plan," each with an italicized note explaining the reasoning, and one of those two also carries "Restored before." That combination is worth ten seconds: read the agent's note, decide whether the plan really stalled or whether it is still moving in a way the agent could not see, and restore it if it still matters. The other agent-flagged row, with no restore history, is likely a genuine stall worth leaving archived.

Data sources