Audits and violations: enforcing a program

What this covers

A program is only as real as your ability to check whether the network is actually following it. Every program in Verinode HQ, an approved-vendor list, a carrier partnership, a TPA relationship, a certification mandate, a training requirement, a brand standard, a safety program, carries two enforcement primitives on its detail page: Recent audits, the record of checks that have been run against a party or franchisee on that program, and Open violations, the queue of unresolved problems those checks (or other detection paths) turned up. This article covers both in depth: how to schedule an audit, what each audit status means, how a violation's severity and escalation state work, what actually detected each one, and where the real enforcement action, approving, disputing, resolving, escalating, waiving, happens.

For the rest of the program detail page (the hero, approved parties, franchisee enrollments, the audit rubric, the KPI matrix, the network target), see Inside a program: the detail view and its rows. This article goes one level deeper on just the two enforcement rows.

Where to find it

1. 1Open Programs from the HQ sidebar at hq.verinode.ai/programs.
2. 2Click into any program (except a Marketing co-op, which has its own ledger surface). You land on hq.verinode.ai/programs/[id].
3. 3Scroll past the hero and whichever authoring rows apply to this program's type. Open violations appears next, when the program has at least one unresolved violation. Recent audits follows it, shown to admins on every program and to everyone else only once at least one audit has been recorded.

The actual approve, dispute, resolve, escalate, and waive actions do not live on this page. They live one page over, at Decisions (hq.verinode.ai/decisions), described in its own section below.

Scheduling an audit

Group admins see a + Schedule tile at the end of the Recent audits row (non-admins never see this tile; they see the row only once audits already exist, and never see any authoring affordance on it).

1. 1Click + Schedule. A "Schedule audit" modal opens.
2. 2Pick a Subject. The list is drawn from whichever roster this program actually tracks: approved parties, if the program's enrollment model is an approved-party list, or enrolled franchisees, if it is mandatory or opt-in. If the roster is empty, the modal explains why instead of letting you schedule against nothing: "Add an approved party first, then schedule an audit against it." for approved-list programs, or "Enrollments warm up once operators self-attach or the program is activated." for mandatory/opt-in programs.
3. 3Pick an Audit type: Annual, Quarterly, Spot, Triggered (signal-driven), or Self-attest (operator). The modal pre-selects Quarterly when the program's own audit cadence is monthly or quarterly, and Annual otherwise, though you can override it for any one audit.
4. 4Pick a Scheduled date, defaulting to today.
5. 5Optionally add Initial findings, free text for whatever triggered this audit or whatever the auditor should know going in.
6. 6Click Schedule audit.

Scheduling creates the audit in Draft status, attributed to you as the auditor (auditor_kind: hq). The modal is explicit about what this does and does not do: "Creates a draft audit row scoped to one approved party [or one enrolled franchisee]. Score + findings get filled in as the audit is conducted." In other words, scheduling reserves the slot; the score, the fuller findings, and the move out of Draft happen as the audit is actually carried out, not in this modal.

Audit status: what each one means

An audit's status runs through a fixed sequence, shown on its tile as {Audit type} · {Status} (for example "Annual · Approved" or "Spot · Disputed"):

| Status | What it means | |---|---| | Draft | Just scheduled. No score or final findings yet. | | Submitted | The audit has been conducted and turned in for HQ review. This is the state where it becomes actionable. | | Approved | HQ has accepted the audit result. Rendered in green. | | Disputed | HQ has flagged the result as contested rather than accepted. Rendered in red, the same accent Verinode uses network-wide for "needs attention." | | Withdrawn | The audit was pulled. Draft and Submitted audits both render in a neutral amber tone; only Approved (green) and Disputed (red) get a distinct color. |

Where the status actually changes. Draft and Submitted audits sit on this page as a record, but the move from Submitted to Approved or Disputed happens on the Decisions page, not here (see below). Only audits in Submitted or Disputed status surface there as actionable rows; a fresh Draft audit does not appear in your Decisions queue until it has been conducted and submitted.

Each audit tile's sub-line shows the score out of 100 plus a short findings excerpt when both exist, just the findings excerpt when there is no score yet, or the auditor's kind (for example, "hq") when neither is on file. The meta line shows when it was conducted, relative to today ("3 days ago," "2 months ago"). Up to 20 audits show, most recently conducted first.

Violation severity and escalation state

Each open violation is a tile, drawn with an action framing so it stands out from the informational rows around it, labeled {Severity} · {Escalation state} (for example "Critical · Open" or "High · Escalated"):

Severity has four levels:

• Critical and High both render in Ember Red, the accent Verinode uses across the product for "this needs attention now."
• Medium renders in Hard Hat Yellow, the "keep an eye on it" accent.
• Low renders in a neutral gray.

Escalation state tracks where a violation sits in its own lifecycle: Open (freshly detected, nothing done yet), Escalated (flagged for closer attention), Resolved (closed out as fixed), or Waived (closed out as accepted, not fixed). Only violations currently in Open or Escalated state appear in this row at all: once a violation is Resolved or Waived, it drops out of the Open violations row (and, as of this writing, there is no separate row on this page that lists resolved or waived history; a violation's resolution lives in its own record but is not surfaced back here).

Each tile's sub-line names the subject (the franchisee or approved party the violation is against) and how it was detected, and its meta line shows when it was first detected, relative to today. Up to 20 open violations show, most recently detected first.

There is no admin-authoring affordance on this row. Unlike approved parties, audits, the rubric, or the KPI matrix, Open violations is read-only history: violations arrive here from the detection paths below, not from a "log a violation" button on this page.

What detected each one

Every violation carries a detected_by tag, shown in its sub-line in plain lowercase (for example "Detected by audit" or "Detected by kpi threshold"):

• audit. The violation traces back to an audit result, an approved party or franchisee that came in below whatever the program's rubric or standard calls for.
• kpi threshold. Specific to Carrier programs with a KPI threshold matrix configured: a reading landed in the red band on one of the four tracked metrics (cycle time, first contact, billing accuracy, customer satisfaction).
• signal. An automated network-wide pattern detection flagged the party or franchisee independent of any specific audit or KPI reading.
• manual. Entered by hand rather than derived from an audit, a KPI reading, or a signal.

Enforcing: approve, dispute, resolve, escalate, waive

This is the part that makes a program more than a list, the actions that actually change an audit's or violation's state. They live on Decisions (hq.verinode.ai/decisions), the same triage log used for network-level plans, interventions, and consent requests, described in The decision log: lanes and status tiles. Program audits and violations both surface there once they are actionable, and every tile carries the same three buttons: Act, Park, and Ignore. Only group admins can use them.

On an audit (only once it has reached Submitted or Disputed status; a Draft audit does not appear here):

• Act approves it, flipping its status to Approved.
• Ignore disputes it, flipping its status to Disputed.
• Park is not available for audits today; using it returns an error rather than changing anything.

On a violation (surfaced whenever it is Open or Escalated):

• Act resolves it: escalation state becomes Resolved, stamped with the resolution time and which admin closed it out.
• Park escalates it: escalation state becomes Escalated, for a violation that needs a closer look rather than a straight resolve or waive.
• Ignore waives it: escalation state becomes Waived, stamped the same way as a resolve, the record of "we saw this and accepted it as-is" rather than "we fixed it."

Quick reference

| Row / action | Who sees or can use it | What changes | |---|---|---| | Open violations row | Everyone, only when at least one violation is Open or Escalated | Read-only; no action here | | Recent audits row | Admins always; everyone else once one exists | Read-only except the + Schedule tile (admin only) | | Schedule an audit | Admins only | Creates a Draft audit | | Decisions: Act on an audit | Admins only | Submitted/Disputed → Approved | | Decisions: Ignore an audit | Admins only | Submitted → Disputed | | Decisions: Park an audit | Not supported | No change | | Decisions: Act on a violation | Admins only | Open/Escalated → Resolved | | Decisions: Park a violation | Admins only | Open → Escalated | | Decisions: Ignore a violation | Admins only | Open/Escalated → Waived |

Best-practice example

A Carrier program has a KPI threshold matrix configured with cycle time and billing accuracy enabled, one metric flagged AUTO-DECERTIFY. A cycle-time reading lands in the red band and a violation shows up in Open violations, "Critical · Open," detected by kpi threshold, against the carrier. Before deciding anything, click through to Decisions: since this is a fresh violation, it is not yet actionable as an audit result, only as the violation itself. If the read is a one-off, Park it to Escalated and keep watching the next cycle's numbers before deciding. If the pattern repeats or the carrier confirms the miss, Act to resolve it once the carrier corrects course, or leave it Escalated while you schedule a Spot audit from the program page to confirm the root cause before it goes to the carrier relationship owner.

Related help articles

• Inside a program: the detail view and its rows, the full hero-plus-row-stack this article's two rows sit inside.
• Programs: how HQ codifies what the network adopts, the catalog page every program opens from.
• The decision log: lanes and status tiles, how Act, Park, and Ignore work as a pattern across every HQ decision surface.
• Compliance: brand health across your network, the network-wide compliance, safety, and reputation rollup these per-program records feed into the bigger picture next to.
• Standards, the certification and process-standard side of network enforcement.

Data sources