Verinode
Open Verinode

Triage Log: restoring auto-archived items

Left alone, an active queue of network initiatives, program flags, and consent requests grows every week and never shrinks. Verinode keeps that queue usable by quietly archiving items nobody is act…

6 min read·Updated July 14, 2026
On this page

What the Triage Log is

Left alone, an active queue of network initiatives, program flags, and consent requests grows every week and never shrinks. Verinode keeps that queue usable by quietly archiving items nobody is acting on anymore: something low-severity that has sat untouched for a month, a stale item that was parked and forgotten, a duplicate of a newer entry. That is auto-archiving, and it runs on its own schedule so you never have to clean house manually.

The Triage Log is the housekeeping list behind that process. It shows everything the system archived on your account in the last 60 days, why each one was archived, and gives you a one-click way to bring any of them back if the system judged it wrong. Nothing is deleted. Auto-archiving only moves an item out of your active view; the Triage Log is where you check that work and correct it.

Note

Auto-archiving is a housekeeping layer, not a judgment on the underlying initiative. An item can be entirely valid and still get archived for going quiet. Restoring it costs one click.

Where to find it

Open Actions from the HQ sidebar at hq.verinode.ai/actions. In the page header, next to Workload, there is a Triage Log link. Clicking it opens the Triage Log as an overlay card on top of the Action Plans page, so you never leave what you were looking at. Closing the overlay returns you exactly where you were.

The same list also exists as a standalone page at /decisions/triage-log for the equivalent view under Decisions.

The two ways an item gets archived

Every archived row in the Triage Log was put there by one of two mechanisms, and the log tells you which:

  • Rule engine (deterministic). A nightly pass applies fixed, predictable age rules. It never touches anything marked critical severity, only info and warning items and parked items that have gone quiet.
  • Agent (LLM). A weekly pass, run Sunday night, looks specifically at the gray-zone cases the rule engine is not allowed to touch on its own, severity that is technically critical but has stalled, or a plan that was started and then abandoned. The agent reads the situation and writes a short note explaining its call.

The summary line at the top of the Triage Log breaks both counts out so you can see, at a glance, how much of the last month's archiving was mechanical versus judgment-based.

The summary line

Above the list, four figures run left to right:

  • Last 7 days. Count of items archived in the past week.
  • Last 30 days. Count of items archived in the past month.
  • By rule engine. Of the last 30 days' archives, how many the deterministic rules caught.
  • By agent. Of the last 30 days' archives, how many the weekly agent pass caught.

These four numbers always describe the last 30 days of activity even though the list of rows below can reach back a full 60 days.

Reading a row

Each row in the list carries the same set of details:

  • Severity dot. A small colored dot on the left: gray for Info, yellow for Warning, red for Critical. Hovering it shows the plain-text severity label.
  • Title. The name of the archived item, unchanged from how it read in your active queue.
  • Reason. Plain-language explanation of why the system archived it. The possible reasons are:

- Low-impact, idle 30+ days: an info-severity item with no plan in motion that has not recurred in 30 days. - Mid-impact, idle 60+ days: a warning-severity item with no plan in motion that has not recurred in 60 days. - Parked, idle 90+ days: an item you set to parked that then sat untouched for 90 days. - Past expiration: the item passed its own expiration date. - Duplicate of newer signal: a newer entry already covers the same underlying issue, so the older one was archived in its place. - Agent: low priority this week: the weekly agent pass judged it not worth surfacing this week. - Agent: stalled plan: the weekly agent pass found a plan that was started and then saw no further progress.

  • Domain. Where the item belongs on the platform (shown in Title Case), when one is set.
  • Entity name. The specific program, location, or record the item is attached to, when one is set.
  • Time archived. A relative timestamp such as "3 days ago" or "2 months ago," calculated from when the item was archived.
  • Restored before. A yellow flag that appears only if this exact item has been archived and restored at least once already. It is Verinode's way of telling you the rule keeps misjudging this particular item, worth a second look at why it keeps going stale.
  • Agent note. When the agent (not the rule engine) archived the item, its reasoning appears in a quoted, italicized line underneath, for example a note explaining that a plan started weeks ago has seen no step completions since. The rule engine never writes a note; only agent-based archives carry one.

Restoring an item

Every row ends in a Restore button. Click it and the item leaves the archive and returns to your active queue immediately, no confirmation dialog. While the request is in flight the button reads Restoring… and is disabled; once it succeeds the row disappears from the Triage Log without a page reload.

Restoring does three things:

  1. Puts the item back in your open Action Plans (and Decisions) queue.
  2. Keeps a record of the fact that this item was archived and then restored, which is what powers the Restored before flag if it happens again.
  3. Leaves the reason and rule that archived it on file for offline review, so patterns of over-eager archiving on a particular reason can get tuned over time.

If a restore fails, for example because the item was already restored by someone else, or was dismissed manually rather than auto-archived, a short red error line appears under that row explaining why, and the row stays in the list.

Tip

If you see the same item earning a Restored before flag more than once, that is a signal worth raising, not just a repeated click. It means a specific rule keeps mis-timing this particular kind of item on your account.

The 60-day window

The Triage Log only ever shows items archived within the last 60 days. Older archives are not deleted, they are simply outside the window this list surfaces. There is no "load more" or pager for anything older; if you need something archived further back, ask your Verinode contact.

Empty states

If nothing has been archived recently, the list area reads:

"Nothing has been auto-archived recently. Triage runs nightly, check back tomorrow."

If the overlay is still fetching data, it reads "Loading the triage log…" briefly. If the fetch fails outright, it reads "Couldn't load the triage log. Try again."

The privacy boundary

The Triage Log only ever reflects activity on your own HQ account, the network initiatives, program flags, and consent requests your leadership team is running. It never surfaces a franchisee's individual, private business decisions. That boundary holds everywhere on the platform: franchisees own their operator-level data, and HQ works with network aggregates, rankings, and compliance signals, never a single location's underlying numbers. Restoring an item on your Action Plans page only ever restores something that belonged to your queue in the first place.

  1. 1From the HQ sidebar, open Actions.
  2. 2Click Triage Log in the page header.
  3. 3Read the summary line to see how much was archived in the last week and month, and the split between the rule engine and the agent.
  4. 4Scan the list for anything archived in error, using the reason label and, where present, the agent's note.
  5. 5Click Restore on any item you want back in your active queue.
  6. 6Close the overlay to return to Action Plans, where the restored item now appears.

Related reading

Was this helpful?