Checklist
Nine checks that decide whether a payment releases. Run them before the money moves, not when the audit asks why it did.
A payment run is the one moment subcontractor compliance has consequences. This checklist is ordered the way the work actually happens: requirements first, then evidence, then judgment, then the decision. Each item is one check, what it means, and how it fails.
Confirm the coverage types, minimum limits, additional insured terms, and endorsement requirements have been pulled out of the subcontract into an explicit, current list — before any certificate is compared against anything. Failure mode: requirements live in contract prose, so every reviewer compares against a different memory of the clause.
Every subcontractor in the payment run has a certificate of insurance on file, received within the current policy period, legible, and complete, with every required line present. Failure mode: a renewal was never requested, and the file holds the certificate from two policy periods ago.
The lines the contract requires are the lines the certificate shows: general liability, auto, workers compensation, umbrella, as specified. Failure mode: the certificate is present and looks fine, but a required line was never bound — presence is not coverage.
Each per-occurrence and aggregate limit is checked numerically against the contract minimums, line by line. Failure mode: limits were skimmed rather than compared, and a million-dollar requirement is being met by a half-million-dollar policy — the classic gap that a claim turns into a dispute.
The additional insured box names the parties the contract requires, and the endorsement forms the contract calls for are attached and match. Failure mode: the box is checked but the actual endorsement is absent, or the wording covers less than the contract assumes.
Each policy period spans the period of performance, including warranty obligations where the contract extends them. Failure mode: the certificate is current today but expires mid-project, and nothing schedules the renewal check — the gap opens in silence.
Each discrepancy found above is an explicit item: what is missing, who resolves it, by when, and through which path — corrected certificate, policy change, or approved waiver. Failure mode: exceptions live in email threads, where ownership decays and deadlines are aspirational.
The payment releases because the state is compliant, or holds because it is not — as a rule, not as a per-run judgment call. Failure mode: the payment releases because the schedule is tight and someone vouches for it, and the exception becomes a fact discovered later.
For every decision there is a record of who checked what, against which requirements, when, and what they concluded — sufficient to replay the decision later. Failure mode: the process worked, but the evidence of it working is a spreadsheet cell, which is to say there is none.
Run manually, this checklist is a recurring act of discipline — and the failure modes above are what discipline looks like at scale. Kernos runs each check as a rule: requirements are objects extracted from the contract, certificates are parsed and compared by the rules engine, exceptions carry owners and deadlines through a seven-state approval flow where the initiator cannot self-approve (enforced server-side), and every decision lands in an append-only audit chain. The step-by-step procedure shows the same sequence as a workflow; the platform overview shows what runs underneath.