Act, Park, and Ignore per source kind

What this article covers

HQ Decisions is one board built from four separate network-level systems, and The four HQ decision sources and how they map into one log explains how each one's native status gets translated into the shared Pending, Acted, Parked, Ignored, and Resolved buckets you see in the status dropdown. This article is the companion piece focused on one specific question: when you click Act, Park, or Ignore on a tile, what actually happens underneath. Which mutation fires, what gets written, who is allowed to click it, and what happens when the click fails.

Everything here applies equally on Decisions (hq.verinode.ai/decisions) and Action Plans (hq.verinode.ai/actions). Both pages are the same gallery component reading the same four sources; Action Plans just pre-filters to the rows currently in flight or completed.

Where to find it

Open Decisions in the HQ sidebar, or Action Plans beside it. Every tile in the gallery carries up to three action buttons along its bottom edge, plus Discuss, which opens the AI agent panel with that row's context loaded and never changes anything. The three action buttons are always labeled the same way regardless of which of the five source kinds the tile came from: Act, Park (shown as Not now on the button itself), and Ignore. Which of the three actually appears, and what each one does, depends on the row's source and its current status. That mapping is the subject of this article.

The admin gate

Every one of these buttons is gated to group admins. Before any mutation runs, the server checks the signed-in HQ user's role on the group. If the role is not admin (for example, a Viewer-role HQ user), the action is rejected and the button click returns an error rather than writing anything. The button itself still renders for a Viewer, it isn't hidden, but clicking it does nothing to the database. There is no separate "read-only mode" toggle for this: the check runs on every single Act, Park, and Ignore call, independent of which of the four source tables the row belongs to.

How a click becomes a database write

1. 1You click a button on a tile. The tile updates immediately, before the server responds, so the gallery feels instant. Its accent color and status label switch to what the click implies (green for Act, teal for Park, grey for Ignore).
2. 2The click calls one of three functions keyed off the row's source kind: an Act call, a Park call, or an Ignore call. Each one first re-checks the admin gate, then looks up the row's current status and group ownership before writing anything.
3. 3If the row doesn't exist, or belongs to a different group than the one you're signed into, the write is rejected. If the row exists and the admin gate passes, the function writes the new status (and, where relevant, a timestamp and the acting admin's id) directly to the source table the row came from: the network data, or the network data.
4. 4On success, the page refreshes its data. Decisions, Action Plans, and the Feed are all told to reload their server-rendered content, since a status change on one of these four sources can affect what any of those three pages show.
5. 5On failure, the optimistic update from step 1 reverts. The tile snaps back to its status from before you clicked, and the error is logged for troubleshooting rather than shown as a banner on the page today.

Decision plans: activate, complete, pause, archive

A decision plan is a playbook you've drafted for the network. Its lifecycle in the network data runs draft → active → completed, with paused and archived as side branches.

• Act is context-sensitive: a draft or paused plan moves to active (and the plan's activation timestamp is stamped). An already-active plan moves to completed (and its completion timestamp is stamped). If the plan is already completed or archived, Act does nothing and returns an error telling you the plan is already in that state, there's nothing further to act on.
• Park only applies to an active plan, and only pauses it. Clicking Park on anything that isn't currently active has no effect: the underlying write is conditioned on the plan's status already being active.
• Ignore archives the plan, from any status. This is the one action on decision plans that works no matter where the plan currently sits in its lifecycle.

Because Act does double duty (activate, then later complete), the same button carries a different meaning depending on the tile's current state: on a fresh, undrafted plan it reads as "start this," on a running plan it reads as "mark this done."

Interventions: advance the queue or close it

An intervention is a specific franchisee location flagged for follow-up (see The interventions queue for at-risk locations for the full detail on how a location gets flagged in the first place). Its lifecycle in the network data runs queued → contacted → in_progress → resolved, with no_action as a side branch.

• Act advances exactly one step at a time: queued becomes contacted, contacted becomes in_progress, and in_progress becomes resolved (stamped with a resolution timestamp). There is no way to skip a step by clicking Act twice quickly, each click only reads whatever the current status is and advances from there. If the intervention is already resolved or no_action, Act returns an error saying the intervention is already in that state.
• Park is not available on interventions. An intervention has no paused state in its lifecycle, so this button is never wired to a working action here.
• Ignore closes the intervention with no_action (also stamped with a timestamp), from whatever status it's currently in. This is the queue's version of "nothing further needed here," distinct from working it through to resolved.

Consent requests: withdraw only

A consent request is HQ's own ask of a franchisee, most often to unlock a benchmark comparison. Its lifecycle in the network data runs pending → approved or declined, with withdrawn and expired as side branches. Approving or declining is the franchisee's decision, made on their own side of the platform, not HQ's.

• Act does not work on consent requests at all. HQ cannot approve or decline on a franchisee's behalf, so clicking Act on a consent-request tile always returns an error explaining that operators approve or decline, not HQ.
• Park is not available either.
• Ignore is the only live action, and it withdraws HQ's own request. It only works while the request is still pending or already approved; a request already declined, withdrawn, or expired returns an error naming its current status, since there's nothing left to pull back. A successful withdrawal writes withdrawn, a withdrawal timestamp, and a fixed reason ("HQ withdrew via Decisions surface") onto the request, and appends an entry to the request's own audit trail recording that HQ, not the franchisee, withdrew it and when.

Program audits: approve or dispute

A program audit is a check run against a party or franchisee on one of your programs (full detail in Audits and violations: enforcing a program). The board only ever shows audits currently submitted or disputed. Once you approve or dispute one, it drops off the Decisions board on the next load, since the underlying query no longer matches it.

• Act approves the audit, moving it to approved, regardless of whether it arrived as a plain submission or as one already disputed.
• Park is not available on audits.
• Ignore disputes the audit, moving it to disputed. This is the "I don't accept this result as-is" action, distinct from approving it.

Both actions first confirm the audit's program belongs to your own group before writing anything, so an audit tied to a program outside your group can't be touched from here even if its id were somehow known.

Program violations: resolve, escalate, or waive

A program violation is an unresolved problem a check turned up against a program's rules. Its state lives in a separate escalation_state field on the network data, tracked independently of the violation's own severity (low, medium, high, critical). Escalation state runs open → escalated → resolved or waived.

• Act resolves the violation: it sets escalation state to resolved, stamps a resolution timestamp, and records which admin closed it out. This works from either open or escalated, there's no requirement to escalate first.
• Park escalates the violation, moving open to escalated. This button only applies while the violation is still open; once it's already escalated, Park has nothing further to do.
• Ignore waives the violation: same resolution timestamp and admin-id stamp as Act, but the escalation state records waived instead of resolved, so the distinction between "this got fixed" and "we're letting this one go" survives in the record even though both close the violation out.

All three actions first confirm the violation's program belongs to your own group before writing anything.

Quick reference

| Source | Act | Park | Ignore | |---|---|---|---| | Decision plans | Activates a draft or paused plan; completes an active one | Pauses an active plan | Archives from any status | | Interventions | Advances one step: queued → contacted → in progress → resolved | Not available | Closes with no action taken | | Consent requests | Not available (franchisee's call) | Not available | Withdraws HQ's own request (pending or approved only) | | Program audits | Approves (submitted or disputed) | Not available | Disputes (submitted only) | | Program violations | Resolves (open or escalated) | Escalates (open only) | Waives (open or escalated) |

Related reading

• HQ Decisions: the franchisor inbox: the board itself, search, filters, status counts, and how to work the queue day to day.
• The four HQ decision sources and how they map into one log: how each source's native status becomes the shared Pending/Acted/Parked/Ignored/Resolved set, and how far back each one reads.
• The interventions queue for at-risk locations: how a franchisee gets flagged in the first place.
• Audits and violations: enforcing a program: how a program audit or violation is created and what it means for the program.
• Benchmark consent requests: what a consent request unlocks once a franchisee approves it.