The four HQ decision sources and how they map into one log

What this article covers

HQ Decisions and its sibling page, Action Plans, both read from the same place under the hood: a single function that fans out to four separate network-level systems, pulls whatever is open or recently closed in each one, and translates every row into one shared shape before handing it to the board. This article is the deep dive on that translation: which native status, business area, and severity each of the four sources produces, how far back each one reads, what powers the timeline bars on Action Plans, and exactly which buttons appear on a tile and what they do underneath. If you want the walkthrough of the board itself, search, filters, and how to work the queue day to day, start with HQ Decisions: the franchisor inbox instead. This one is about where the rows come from and how they get their shape.

Where it lives

Both pages sit under the same HQ sidebar group as Decisions:

• Decisions, at hq.verinode.ai/decisions, the full log across all four sources, organized by status.
• Action Plans, at hq.verinode.ai/actions, the same four sources narrowed to whatever is currently active or completed, laid out on a Gantt timeline by default (with a Calendar toggle alongside it).

Every row on either page originates from exactly one of four network-level systems. None of them read a franchisee's own job files, invoices, or claims: they read the network-level tables HQ's own admins and Verinode's aggregator already maintain.

Why one mapper instead of four screens

Left alone, these four systems each speak their own language. A decision plan is draft, active, paused, completed, or archived. An intervention is queued, contacted, in_progress, resolved, or no_action. A consent request is pending, approved, declined, withdrawn, or expired. A program audit or violation carries its own status and escalation vocabulary again. Four tables, four vocabularies, four places to check every morning.

The mapper is the layer that reads all four, keeps each one's real lifecycle intact underneath, and projects every row into the same shared shape the board actually renders: a status bucket, a business-area domain, a severity, a title, an entity (when there is one), and, for Action Plans, a synthesized timeline. That shared shape is the same one Verinode IQ's Decision Log uses on the operator side, which is why HQ Decisions and Action Plans look and behave identically to their operator-side counterparts even though nothing here reads an operator's own signals.

The four native systems

| Source | What it is | Native status values | |---|---|---| | Decision plans | The playbooks you've drafted for the network, a coordinated initiative you'd roll out across locations | draft, active, paused, completed, archived | | Interventions | A specific location an HQ admin flagged for follow-up. Full detail in The interventions queue for at-risk locations | queued, contacted, in_progress, resolved, no_action | | Consent requests | HQ's own ask of a franchisee, most often to unlock a benchmark comparison or share a data point | pending, approved, declined, withdrawn, expired | | Program audits | A check run against a party or franchisee on one of your programs. Full detail in Audits and violations: enforcing a program | draft, submitted, approved, disputed, withdrawn | | Program violations | An unresolved problem a check (or another detection path) turned up against a program's rules | open, escalated, resolved, waived (tracked separately from severity: low, medium, high, critical) |

Program audits and violations are two different tables (program_audits and program_violations) but the mapper treats them as one combined source for the log: both are drawn from your programs and both land in the Compliance business area.

How each native status becomes a shared status

The board works off six shared status values internally (new, seen, actioned, parked, dismissed, resolved), which the status dropdown then collapses into five: Pending (new or seen), Acted, Parked, Ignored, Resolved. Every source maps its own vocabulary into that shared set on its own terms.

Decision plans

| Native status | Shared status | Shows as | |---|---|---| | draft | seen | Pending | | active | actioned | Acted | | paused | parked | Parked | | completed | resolved | Resolved | | archived | dismissed | Ignored |

Interventions

| Native status | Shared status | Shows as | |---|---|---| | queued | new | Pending | | contacted | actioned | Acted | | in_progress | actioned | Acted | | resolved | resolved | Resolved | | no_action | dismissed | Ignored |

Consent requests

| Native status | Shared status | Shows as | |---|---|---| | pending | new | Pending | | approved | actioned | Acted | | declined | dismissed | Ignored | | withdrawn | dismissed | Ignored | | expired | parked | Parked |

Program audits and violations

Audits and violations don't run through the same kind of status table, because each one is fixed at read time:

• Every audit the board shows (submitted or disputed) is stamped Pending, full stop. Whether it's a plain submission awaiting your review or one already flagged as disputed doesn't change its status bucket, only its severity (see below) and its title tell the two apart.
• Every violation the board shows is Pending while its escalation state is open, and Acted once it becomes escalated. There's no separate "resolved" bucket a violation passes through here.

Decision plans, interventions, and consent requests behave differently: because their read windows are date-based rather than status-based (see below), a plan you completed, an intervention you resolved, or a request that was declined or withdrawn keeps showing up on the board, correctly marked Resolved or Ignored, for a while after it closes out. That's the difference between "still relevant to show as closed" (plans, interventions, consent) and "no longer part of the compliance queue once handled" (audits, violations).

Business area and severity

Every row also carries a domain (the business-area facet on the Decisions filter bar) and a severity, both assigned by the mapper rather than read off any status field:

| Source | Domain | Severity rule | |---|---|---| | Decision plans | Operations | Warning if the plan's kind is directive; Info for playbook, recommendation, or experiment plans | | Interventions | Risk | Always Warning | | Consent requests | Governance | Always Info | | Program audits | Compliance | Warning once disputed; Info otherwise | | Program violations | Compliance | Mirrors the violation's own recorded severity: Critical, Warning (for a high-severity violation), or Info (medium or low) |

The domain dropdown on Decisions labels these Operations, Risk, Governance, and Compliance, and only appears once your open rows span two or more of them. On the tile itself, severity never shows as the word "Critical" or "Info": it shows as a colored dot plus a plain-language label, Urgent for critical, Act soon for warning, When you can for info, the same three labels IQ's operator-side Decision Log uses. Tile-accent color follows status first (green once acted or resolved, teal once parked, grey once ignored) and only splits pending rows by urgency (red for urgent, amber for everything else).

Because none of the five row kinds carries an entity of type vendor, client, carrier, or TPA, every HQ decision tile shows a plain business-area glyph in its icon slot rather than a resolved company logo. Compliance rows (audits and violations) get a dedicated compliance glyph; Operations, Risk, and Governance rows fall back to the same generic decision glyph.

Building the row: title and entity

• Decision plans title from the plan's own name, falling back to "Untitled plan." They never carry an entity, a plan is about the network, not about one location.
• Interventions title from the flag reason, falling back to "At-risk franchisee." Their entity is the flagged location, entity type franchisee.
• Consent requests title from the rationale, falling back to "Consent request." Their entity is also the franchisee being asked, entity type franchisee.
• Program audits title as {Audit type} · {Program name}, for example "Annual · Fire Restoration Standard." Their entity is the program itself, entity type program.
• Program violations title from the recorded reason, falling back to "Program violation." Their entity is also the program, entity type program.

Interventions and consent requests are the only two sources that name a specific franchisee, and that name holds to Verinode's privacy boundary: unless your network's entity model is set to a single legal entity, the location's real name is replaced everywhere on this board, in search, and inside the workspace slider, with a stable label built from the location's own record rather than its name (for example "Franchisee #A1B2"). Same-entity networks, one operating company running every location, see the real name, since it's the company's own data. Decision plans, program audits, and violations never carry a franchisee identity in the first place; they're about the network or a program, not about any one member's private business.

The synthesized plan behind Action Plans

Action Plans reads the same rows as Decisions, narrowed to whatever is currently Acted or Resolved, and lays the in-flight ones out on a Gantt timeline. IQ's operator-side Gantt draws its bars from a real step-by-step plan the agent generates when an operator acts on a signal. HQ's four sources have no equivalent, an intervention or a consent request was never run through an agent plan, so the mapper builds a stand-in timeline for each row kind, anchored on that row's own real timestamps:

• Decision plans: Drafted (day 0, always shown complete), Activated (dated to when the plan actually went active), Adoption check (a checkpoint partway through), Completed (dated to when it wrapped, or 30 days out as a placeholder while still running). This stand-in only builds once a plan has an activation date, which in practice is always true by the time a plan reaches Action Plans, since only active or completed plans qualify for that page.
• Interventions: Flagged (day 0), Contacted (day 3), In progress (day 7), Resolved (dated to the actual resolution, or 21 days out as a placeholder). Each step marks complete once the intervention's real status has passed it.
• Consent requests: Sent (day 0), Approved (dated to the actual approval, or 7 days out as a placeholder), Closed (3 days after Approved). Closed never marks complete on this stand-in, so an approved consent request's Action Plans bar always shows its final step as still open, since HQ has no further action to take on an approved request beyond what already happened.
• Program violations: Detected (day 0), Escalated (day 3), Resolved (dated to actual resolution, or 14 days out as a placeholder).
• Program audits get no stand-in timeline at all, and for good reason: an audit's shared status never becomes Acted or Resolved (see above), so an audit row never qualifies for Action Plans in the first place. Audits only ever appear on the Decisions page.

What each source's buttons do

Tile buttons are wired straight to the source table a row came from, and only a group admin can use them; a non-admin (Viewer role) sees the same buttons but the underlying action is rejected server-side.

| Source | Act | Park | Ignore | |---|---|---|---| | Decision plans | Activates a draft or paused plan; completes an active one | Pauses an active plan | Archives the plan from any state | | Interventions | Advances the lifecycle: queued → contacted → in progress → resolved | Not supported, interventions have no paused state | Closes it with no action taken | | Consent requests | Not available, HQ can't approve or decline on a franchisee's behalf | Not supported | Withdraws HQ's own request | | Program audits | Approves a submitted or disputed audit | Not supported | Disputes a submitted audit | | Program violations | Resolves the violation | Escalates an open violation | Waives the violation |

Discuss appears on every row regardless of status and opens the AI agent panel with that row's context loaded. Rows already Resolved or Ignored show Discuss only, there's nothing left to act on. Clicking the tile body itself, rather than a button, opens the workspace slider for a closer read without changing anything.

How far back the log reads

Each source has its own lookback, and it isn't the same shape for all four:

• Decision plans: the last six months, by when the plan was created, regardless of status.
• Interventions: anything still queued, contacted, or in progress shows no matter how old it is. Anything already resolved or closed without action only shows if it was flagged within the last three months.
• Consent requests: anything still pending shows no matter how old it is. Anything already approved, declined, withdrawn, or expired only shows if it was last updated within the last three months.
• Program audits: no date window at all, only whatever is currently submitted or disputed.
• Program violations: no date window at all, only whatever is currently open or escalated.

If your network hasn't set up any programs yet, the audits and violations source contributes nothing, since both are scoped to your own programs' records.

Empty states

If nothing matches the current filter on Decisions, the gallery shows a plain message instead of an empty grid: with the status dropdown on All, it reads that there are no decisions yet and that they'll appear as Verinode spots cost savings, risk, and growth opportunities in your data; on any other status it reads that nothing is in that state right now. On Action Plans, an empty Gantt reads differently depending on which bucket you're viewing, for example "Nothing overdue. Steps past their due date land here so they don't slip," or "No completed plans yet. Plans you resolve land here so you can run a retrospective."

Related reading

• HQ Decisions: the franchisor inbox, the full walkthrough of the board itself: search, filters, and how to work the queue.
• The interventions queue for at-risk locations, the full detail on flagging, statuses, and the franchisee drill-in behind an intervention row.
• Audits and violations: enforcing a program, the full detail on scheduling audits and the escalation lifecycle behind a violation.
• Programs, where the programs behind audits and violations are set up and managed.
• Standards, the process standards and forms audits that feed some of the audit rows on this board.
• Compliance: brand health across your network, where certification, safety, and reputation data behind program audits and violations rolls up.
• Network Health: your HQ command home, where interventions first get flagged.
• Report library, where broadcasts and exports related to network decisions are archived.
• Broadcasting to your network, for pushing a decision plan's outcome out to every location once it's complete.
• What HQ sees, the platform shell this page lives inside.
• Item 19 basics and Discovery Day, background on the disclosure and in-person steps some program and consent decisions eventually feed into.

Data sources