"Audit rubrics: weighted criteria for vendor-approval programs"

An audit rubric is the weighted checklist a vendor-approval program uses to decide whether an approved party still deserves to be on the list. Instead of a single yes-or-no audit call, HQ breaks qu…

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

What the audit rubric is

An audit rubric is the weighted checklist a vendor-approval program uses to decide whether an approved party still deserves to be on the list. Instead of a single yes-or-no audit call, HQ breaks qualification into individual criteria (insurance current, on-time delivery, defect rate, and so on), assigns each one a weight and a maximum point value, and sets a single pass threshold as a percent of the total points on offer. The rubric row is the only row in the whole Programs detail page that exists for this one purpose: it declares what "pass" means, in points, for every party on that program.

The rubric row appears on exactly one program type: vendor approval. Carrier programs get their own KPI threshold matrix instead (see hq-program-detail-view), and every other program type (TPA, cert mandate, training, brand standard, safety, marketing co-op) has no rubric row at all, because those programs either track franchisees rather than external parties, or use a different scoring mechanism entirely.

Rubric criteria judge the approved parties on the program: the vendors, labs, cert bodies, or brokers the network has qualified, not any individual franchisee's business. That distinction matters for the HQ privacy boundary covered below.

Where to find it

  1. 1Open Programs from the HQ sidebar at hq.verinode.ai/programs.
  2. 2Find a vendor approval program in the Active, Drafts, or Sunset rows. Narrow the catalog first with the type-filter tabs if you have several (see hq-programs-type-filter-tabs).
  3. 3Click the program's tile. You land on hq.verinode.ai/programs/[id].
  4. 4Scroll to the Audit rubric row, positioned right after the Approved parties row and before the Network target row.

If the program you clicked is not a vendor-approval type, this row will not be there at all: it is one of the type-gated rows described in hq-program-detail-view.

Reading the row when a rubric exists

Each defined criterion renders as its own tile:

  • Label at the top left reads Weight N, the weight assigned to that criterion.
  • Headline is the criterion's own label, for example "On-time delivery + SLA met."
  • Sub-line reads Max N pts, the maximum points a party can score on that criterion alone.
  • Meta reads RUBRIC on every criterion tile.

After the last criterion tile, admins see one more tile: Edit rubric, labeled Rubric, with a sub-line reading "N criterion(s) · pass threshold N%." Clicking it reopens the rubric editor with everything you already saved.

The pass-threshold math

The rubric stores three numbers per criterion (a label, a weight, and a max-points value) plus one number for the whole rubric (the pass threshold, as a percent). Verinode combines them like this:

  • Total max points = the sum, across every criterion, of that criterion's weight multiplied by its max points.
  • Pass points = total max points multiplied by the pass threshold percent, rounded to the nearest whole point.

So weight is not a separate axis from points, it is a multiplier on how much each criterion's max points contribute to the rubric's overall ceiling. A criterion with a high weight and a high max-points value can carry far more of the total than a criterion with a low weight, even if both have the same max-points value on paper.

Worked example. Say a program has three criteria:

| Criterion | Weight | Max points | Weight × max points | |---|---|---|---| | Insurance + bonding current | 3 | 5 | 15 | | On-time delivery + SLA met | 5 | 5 | 25 | | Quality of work / defect rate | 5 | 5 | 25 |

Total max points = 15 + 25 + 25 = 65. At a 70% pass threshold, pass points = round(65 × 0.70) = 46. A party would need an audit score equivalent to 46 of those 65 possible points to clear the bar.

Editing the rubric (admin only)

Click + Build the audit rubric (when nothing is defined yet) or Edit rubric (once criteria exist) to open the Audit rubric modal.

The modal opens with this explanation: "Weighted criteria with per-criterion weight + max-points. Pass threshold is a % of total max possible points. A future slice wires auto-decertify when an audit comes in below threshold. Cap: 80 criteria." That sentence is the honest state of the feature: the rubric you build here is fully live as the declared standard, but the automatic enforcement described in the last section of this article has not shipped yet.

If you are starting from nothing, Verinode seeds the editor with three example criteria so you are editing rather than staring at a blank form: "Insurance + bonding current" (weight 3, max points 5), "On-time delivery + SLA met" (weight 5, max points 5), and "Quality of work / defect rate" (weight 5, max points 5). Treat these as a starting template, not a default you have to keep, rename, reweight, or delete every one of them.

  1. 1For each criterion, fill in a label (a short description of what's being judged, for example "Customer-sat rating at or above 4.5 stars"), a weight (a positive whole number, minimum 1), and max pts (a positive whole number, minimum 1, the ceiling that criterion contributes before weighting).
  2. 2Click + Add criterion to add another row. The button disables and reads "Cap reached (80 criteria)" once you hit the 80-criterion cap.
  3. 3Click Remove on any criterion's row to delete it.
  4. 4Set the Pass threshold as a whole percent from 0 to 100. As you type, the panel below the input live-recalculates and reads "≈ N pts of M max (X criterion(s), total weight W)" so you can see the point math update in real time before you save.
  5. 5Optionally add a Description shown to auditors: free text for anything an auditor should know about how the rubric gets applied, interpretation guidance or exception clauses that don't fit into a criterion label.
  6. 6Click Save rubric.

Verinode validates the rubric before saving and blocks the save with an inline message if:

  • No criteria are defined at all ("Rubric needs at least one criterion.").
  • Any criterion is missing a label ("Every criterion needs a label.").
  • Any criterion's weight is zero, negative, or not a number ("'{label}' needs a positive weight.").
  • Any criterion's max points is zero, negative, or not a number ("'{label}' needs a positive max-points value.").

There is no floor requirement enforced by the editor itself beyond "at least one criterion." The empty-rubric admin prompt describes a working range of 30 to 80 weighted criteria as the shape a real vendor-qualification rubric tends to take, but the editor lets you save fewer if that's genuinely all a given program needs.

Empty state

Non-admin viewer, no rubric defined: "No rubric defined yet. Group admin can author the weighted criteria + max points + pass threshold from this row."

Admin, no rubric defined: a tile reading "+ Build the audit rubric," with the sub-line "30–80 weighted criteria · max points · pass threshold. Drives the audit score + auto-decertify (follow-on)."

Where the rubric's numbers surface elsewhere

The rubric itself lives on the program. Its effects show up in two other places on the same detail page:

  • Approved parties row. Each approved party's tile shows "Last audit N/100" once that party has a completed audit score on file. That score is measured against whatever rubric is currently defined on the program.
  • Recent audits row. Each audit tile shows "Score N/100" when a score exists, alongside a findings excerpt. Scheduling a new audit here (the admin-only + Schedule tile) only captures the subject, the audit type, a scheduled date, and optional initial findings; the sub-line on that tile is explicit that "findings + score" get filled in "when conducted," meaning after the audit itself takes place, not at scheduling time.

Neither of those rows computes a score from the rubric automatically today. The rubric is the declared standard; a completed audit's score is the actual reading against it.

How the rubric is meant to drive the audit score, and what auto-decertify means

Two things are worth separating clearly, because the copy inside the product names both in the same breath and it is easy to conflate them.

Live today: the rubric you build here is the qualification standard for the program. It defines exactly what an auditor should be checking (each criterion's label), how much each check is worth relative to the others (weight), the points ceiling per check (max points), and what percentage of the total possible points a party needs to clear the bar (pass threshold). That math is fully computed and shown to you in the editor the moment you type it in.

Follow-on, not yet built: turning a completed audit's raw findings into a rubric-derived score, and automatically enforcing what happens when that score lands below the pass threshold, is future work. The product's own copy says so directly: the rubric editor's intro line reads "A future slice wires auto-decertify when an audit comes in below threshold," and the underlying rubric record itself carries a comment describing the intended behavior, that a party scoring below the pass threshold on an audit is meant to automatically flip from qualified to probation, enforced at the point the audit is submitted, in a slice that has not shipped yet.

For now, treat the rubric as the standard you hand to whoever conducts the audit, human judgment applies the rubric during the audit today, and any resulting change to a party's qualification status (moving them to Probation, Suspended, or Removed) is a manual admin action, not something the rubric triggers on its own.

This is the same pattern as the carrier program's KPI threshold matrix, which has its own auto-decertify on red toggle per metric. Both features declare the rule now (the rubric's pass threshold, the KPI matrix's red band) so the enforcement layer has something correct to read from the moment it ships. See hq-program-detail-view for the KPI matrix's full behavior.

Heads up

Do not rely on the rubric to automatically decertify a vendor today. A party can sit at "Qualified" indefinitely with an audit score well under the pass threshold until an admin notices and manually changes their status. The Approved parties row's negotiated-rate modal is not the path for that, either, it only sets a vendor's monthly rate and tolerance. Treat the pass threshold as the target you are building enforcement toward, not a guarantee already in force.

Why this respects the HQ privacy boundary

The audit rubric judges external parties (vendors, carriers, TPAs, cert bodies, labs, or brokers) that the network has chosen to qualify, not any individual franchisee's business. HQ authors the criteria, and any franchisee enrolled under this program already knows those parties are being vetted against a shared standard, that is the entire point of an approved-vendor list. Nothing on this row exposes a franchisee's margins, job-level financials, or private vendor spend. The one place a franchisee-adjacent number does appear (a negotiated monthly rate on a vendor party) is a rate HQ itself negotiated, not a franchisee's own ledger, and it lives on the Approved parties row, not here. See hq-programs for the full statement of what HQ sees and does not see inside a program.

Best-practice example

A network runs a "Water Mitigation Equipment" vendor-approval program with six approved suppliers. HQ builds a rubric with five criteria: insurance and bonding current (weight 2, max 5), on-time delivery (weight 5, max 5), quality and defect rate (weight 5, max 5), pricing consistency with the negotiated rate (weight 3, max 5), and responsiveness to service requests (weight 2, max 5). Total max points: (2+5+5+3+2) × 5 = 85. HQ sets the pass threshold at 75%, so the live panel reads "≈ 64 pts of 85 max." One supplier's most recent audit comes back at 58 points, below the 64-point bar. Because auto-decertify has not shipped, that gap does not move on its own, HQ has to notice it (from the "Last audit N/100" reading on the party's tile) and decide manually whether to move that supplier to Probation while the shortfall gets addressed.

  • hq-program-detail-view, the full program detail page and every row on it, including how the rubric row fits alongside approved parties, violations, and audits.
  • hq-programs, the Programs catalog: program types, creation flow, and the privacy boundary that governs everything HQ sees inside a program.
  • hq-programs-type-filter-tabs, narrowing the catalog to vendor-approval programs before you click in.
  • hq-programs-draft-deck, the guided three-step flow for standing up a new vendor-approval program from a vendor category.
  • hq-vendors-detail-programs-participation, how a vendor's participation in this program rolls up on its own detail page.
  • hq-vendors-rate-drift, the separate signal a negotiated rate on an approved party feeds, distinct from the rubric.
  • hq-compliance, the network-wide rollup that audit results and violations from this program feed into.

Data sources

  1. 1.the network data (standards.rubric jsonb), the network data. Verinode.
  2. 2.Verinode. Verinode.
  3. 3.the product (updateProgramRubricAction). Verinode.
  4. 4.Verinode. Verinode.
  5. 5.the product (EditRubricModal, CriterionEditor). Verinode.
Was this helpful?