Program audits and violations: the judgment queue

What this queue is

Every program you run, an approved-vendor list, a carrier partnership, a TPA relationship, a certification mandate, produces two kinds of raw records behind the scenes: audits (someone checked whether a party or franchisee is meeting the standard) and violations (something came in below the bar). Those records sit on the program itself, but a completed audit or a live violation isn't useful sitting on a program page nobody is looking at that day. It needs to land somewhere a franchisor actually checks every morning and can move forward with one click.

That somewhere is Decisions, at hq.verinode.ai/decisions. This article is about the slice of that board that carries program audits and violations specifically: how a program_audits or program_violations row becomes a tile in your queue, what severity it's given, and what each button on it actually does to the underlying record. For the rest of the Decisions board (decision plans, interventions, consent requests, the shared gallery, the status and area filters), see HQ Decisions: the franchisor inbox. For the program-detail-page side of the same data (where audits get scheduled and where violations are first read), see Audits and violations: enforcing a program.

Where to find it

Click Decisions in the HQ sidebar (hq.verinode.ai/decisions). Program audit and violation rows show up in the same flat gallery as every other Decisions row, no separate tab or page. Two ways to isolate just this slice:

• Open the business-area dropdown (labeled "All areas" until you click it) and pick Compliance. That's the domain every program audit and violation row carries, alongside nothing else on this board, decision plans read Operations, interventions read Risk, consent requests read Governance.
• Type into Search decisions…. A program audit or violation's title always names the program, so searching a program's name surfaces its open rows.

How a row gets here: the join

The queue doesn't read program_audits and program_violations directly against every program on the platform. It scopes to your group first, then pulls only the actionable rows underneath it:

1. Verinode reads every row in the network data where group_id matches your network. If your network has zero programs set up, this whole source contributes nothing to the board, not an empty-state message, just no rows from this source at all.
2. Against that list of program ids, it pulls two sets in parallel:

- the network data where status is submitted or disputed. - the network data where escalation_state is open or escalated.

1. Each result is mapped into a tile in the shared Decisions shape, with the program's own name attached from the same the network data read, so a tile never has to re-fetch the program separately.

Two statuses are deliberately excluded from each source. A draft audit hasn't been conducted yet, there's nothing to judge, so it never reaches this queue, only Submitted (turned in for review) and Disputed (already contested once) are queue-worthy. An approved or withdrawn audit is already closed out and drops off. Same logic on violations: resolved and waived are closed, only open (freshly detected) and escalated (flagged for a closer look) stay in the queue.

Reading a tile

Audit tiles. The title reads {Audit type} · {Program name}, for example "Annual · Fire Restoration Standard" or "Spot · Water Mitigation Equipment." Audit type is one of Annual, Quarterly, Spot, Triggered, or Self-attest, whatever was picked when the audit was scheduled. The entity name shown on the tile is the program itself, not a franchisee or vendor, because an audit's judgment queue row is about the program-wide review, not any one party's file. The date is when the audit was conducted.

Violation tiles. The title is the violation's own reason field, free text written at detection time (for example "Insurance certificate lapsed" or "Cycle time in red band, three cycles running"). The entity name is again the program. The date is when the violation was first detected.

Both kinds of tiles carry a colored accent that reads the same as every other row on this board: red for urgent pending, amber for non-urgent pending, green for something already acted or resolved, teal for parked. On this source specifically:

• A pending audit or violation goes red (urgent) only if its severity is Critical. Everything else pending renders amber (non-urgent), regardless of source, dollar impact doesn't apply here since program rows carry no estimated dollar figure.
• An escalated violation renders green (acted), the same color used for anything moved forward on this board.
• Disputed audits and resolved/waived rows age out of this specific queue (see above), so you won't see the ignored or resolved tile colors on program rows here, those states simply drop the row from the board entirely once the underlying source query excludes them.

Severity: how Critical / Warning / Info gets decided

Every row on the Decisions board is normalized to one of three severities so the whole board reads consistently no matter which of the four sources a row came from. For program audits and violations specifically:

Audits map on their status, not on any score:

| Audit status | Severity shown | |---|---| | Submitted | Info | | Disputed | Warning |

A submitted audit is routine, someone finished a check and it's waiting on your sign-off. A disputed audit already has friction on it, someone (HQ, in an earlier pass) contested the result, so it's promoted to Warning even though nothing about its underlying score changed. The audit's numeric score (0 to 100, when one has been recorded) and its findings excerpt are both carried into the row's detail but don't feed the severity calculation; severity here is a status read, not a score read.

Violations map directly off the severity value recorded on the violation itself:

| Violation severity (as recorded) | Severity shown on the queue | |---|---| | Critical | Critical | | High | Warning | | Medium | Info | | Low | Info |

This is a many-to-one collapse: the underlying program_violations table (and the program detail page's Open violations row) tracks four distinct levels, Critical, High, Medium, Low, but the Decisions queue's shared severity vocabulary only has three slots. High folds into Warning alongside Medium and Low would otherwise sit at Info on their own, and Medium and Low both land at Info. If you need the finer-grained four-level read, or the violation's detected_by tag (audit, signal, manual, or KPI threshold), open the program's own detail page, described in Audits and violations: enforcing a program, the queue tile itself doesn't surface detected_by.

Status: pending or already moving

Underneath the shared severity, each row also carries a status, which drives whether it counts as Pending or Acted in the board's status dropdown:

• A submitted or disputed audit is always Pending (mapped internally to "new"), there's no in-between state for an audit sitting in this queue: it's either awaiting your review or it's been moved out already.
• An open violation is Pending. An escalated violation is Acted, escalating is itself a forward move, not a park.

Neither kind ever shows as Parked or Ignored on this board; those two statuses belong to sources with a real paused or dismissed state (decision plans, interventions). A disputed audit or a waived violation simply stops appearing here once its underlying status flips out of the queue-eligible set, described above.

The buttons: what Act, Park, and Ignore actually do

Only group admins can use these. Anyone else sees the tile and its Discuss button, which opens the agent panel with the row's context loaded, but not the action buttons themselves.

On an audit tile (only reachable while the audit is Submitted or Disputed):

• Act approves it. The audit's status flips to approved, and it drops out of this queue immediately (approved audits aren't queue-eligible).
• Ignore disputes it. status flips to disputed. If it was already disputed, Ignore isn't offered a second time in the same way, disputing is a one-way move from Submitted.
• Park is not available on an audit. There's no paused state in an audit's lifecycle; clicking it (if you could) would return "Park not supported," it simply isn't wired to a state change.

On a violation tile (reachable while Open or Escalated):

• Act resolves it. escalation_state flips to resolved, stamped with the time and which admin closed it out.
• Park escalates it. escalation_state flips to escalated, for a violation you want a closer look at rather than closing outright. Once escalated, the tile's status reads Acted (see above), but the button is still available if you subsequently want to Act (resolve) or Ignore (waive) it.
• Ignore waives it. escalation_state flips to resolved as well, but tagged as a waive rather than a fix, the record of "we saw this and accepted it as-is."

Every mutation runs a check that the audit or violation's parent program actually belongs to your group before writing, so a row can't be acted on across a group boundary even if an id were guessed. The tile updates in place once the action completes; there's no page reload.

Clicking anywhere on the tile body that isn't a button opens the same row in the workspace slider for a closer read (the audit's score and findings excerpt, or the violation's detected-by tag and full reason text), without triggering any state change.

Empty states

There's no dedicated empty-state message for "no program audits or violations." If your programs have nothing in Submitted/Disputed or Open/Escalated state, this source simply contributes zero rows to the board. What you see depends on what else is in your queue:

• If every source is empty, the gallery (with the status filter on All) reads that there are no decisions yet and that they'll appear as Verinode spots cost savings, risk, and growth opportunities in your data.
• If other sources have rows but this one doesn't, you'll just see fewer Compliance-domain tiles, or none, when you filter the area dropdown to Compliance. Nothing on screen calls that out as unusual, an all-clear compliance state looks the same as a network with no programs at all.
• If your group has zero programs configured under the network data, this source never runs its second query at all, so program rows are permanently absent from this board until at least one program exists. Set one up under Programs first.

Why this respects the HQ privacy boundary

Both source tables behind this queue, the network data and the network data, are network-level compliance records, not a franchisee's private business data. An audit's subject is a party the program qualifies (a vendor, carrier, TPA, cert body) or an enrolled franchisee's compliance standing against a shared standard everyone in the program already agreed to. A violation is the same: a rules breach against a program's own terms, not a read into a franchisee's margins, job files, invoices, or claims.

Unlike interventions and consent requests, the other two sources on the Decisions board, program audit and violation rows never carry an anonymized franchisee label, because the entity attached to the row is the program itself, not an individual location. Verinode never reaches into a franchisee's own systems to build this queue; everything here comes from records HQ's own program administration and audit process already produced.

How to use it

1. 1Open Decisions and set the area dropdown to Compliance to isolate program audits and violations from the rest of your inbox.
2. 2Scan for red (Critical severity) tiles first, those are violations recorded as Critical against a program.
3. 3Click Discuss on a disputed audit or an escalated violation before deciding, especially if the underlying reason or findings excerpt needs more context than the tile shows.
4. 4On an audit: Act to approve it once you accept the result, or Ignore to dispute it if the finding looks wrong and needs a second look.
5. 5On a violation: Park to escalate it if you want eyes on it a while longer, Act to resolve it once it's actually fixed, or Ignore to waive it if you're accepting it as-is without a fix.
6. 6For the finer-grained severity read (the full Critical/High/Medium/Low scale) or the violation's detection path, click through to the program's own detail page rather than relying on the queue tile alone.

Related reading

• HQ Decisions: the franchisor inbox, the full board this queue is one slice of: search, status and area filters, and how the other three sources (decision plans, interventions, consent requests) behave.
• Audits and violations: enforcing a program, the program-detail-page side of the same two tables: scheduling an audit, the full four-level violation severity scale, detected_by, and the Recent audits / Open violations rows.
• Audit rubrics: weighted criteria for vendor-approval programs, how a vendor-approval program's pass threshold is built, the standard an audit's score is measured against.
• Programs, the catalog page where programs are created and where this queue's source tables get their group_id scope.
• Compliance: brand health across your network, the network-wide rollup that certification, safety, and audit data feeds into alongside this queue.

Data sources