The challenge
Brenda Noriega runs Noriega Risk Partners with a heavy construction book, which means contract review is not an occasional task. It is the job. Construction contracts arrive with insurance schedules attached, and somebody has to read the schedule against the insured's actual program to confirm compliance before anything gets signed.
The work resists shortcuts because the requirements do not sit in one place. They hide in the insurance section, in exhibits and schedules, in indemnification clauses, and in references to protocols like OCIP and CCIP. A clause reading "subcontractor shall maintain the coverages described in Exhibit C" means Exhibit C is now a requirements document too. On the other side, the coverage evidence is just as scattered: a monoline insured might carry standalone general liability, auto, and umbrella policies on three different carriers, and real coverage lives across declarations pages, endorsement schedules, and carrier-branded wrap endorsements that bundle twenty or thirty component forms under a single number.
Then there are the traps that make this genuinely hard rather than merely tedious. CG 20 10 and CG 20 37 look nearly identical and cover different triggers, one for ongoing operations and one for completed operations. An additional insured endorsement does not imply primary and non-contributory coverage; that language has to be explicit. A waiver of subrogation on general liability says nothing about workers compensation. Same form number with a different edition date can mean materially different language.
In Brenda's words: "I often have to sift through multiple contracts and review against the insurance program to make sure the insured is compliant."
The solution
Contract Compliance was built to do that reading, and to be checkable at every step, because a compliance tool an agent cannot audit is a tool they cannot defend.
It runs as two passes. The pre-check takes the contract and the insured's policies and answers whether the coverage actually contains what the contract demands. The post-check takes the drafted certificate against the same contract and answers a different question: whether the certificate's own text faithfully reflects what was required. Those fail in different ways. A certificate can show a limit the underlying policy does not carry, leave the additional insured box unchecked, or fall back on the generic ACORD cancellation language that has no teeth. Catching certificate defects before submission is a separate problem from verifying the policy behind it, so the system treats them separately.
The output is deliberately not pass or fail. Every extracted requirement gets one of four statuses. MET and NOT_MET mean what they say. AMBIGUOUS means the coverage might satisfy the requirement but the language is buried, references a form without full text, or otherwise needs a carrier confirmation, and it comes with the specific question to ask. POSSIBLE_SCOPE_MISMATCH is advisory, for a requirement that does not appear to fit the work being performed, like pollution liability on interior cabinetry, and it exists so an agent has grounds to push back on a third-party reviewer.
That AMBIGUOUS status is the design decision that matters most. A system that forces every finding into a binary either invents gaps that turn out to be accepted coverage or quietly marks things met that were never verified. Both destroy trust, and the second one destroys it silently. An agency's E&O position is strongest when ambiguous findings get resolved to met or not met by a documented carrier call, so the engine's job is to surface the question with a specific next step rather than prejudge an answer only the carrier can give.
The overall verdict is then mechanical rather than judgment. Any NOT_MET makes the report non-compliant. Any AMBIGUOUS with no gaps makes it partial, which reads as "verify, then you are clear." Advisories never change the verdict. Same inputs, same rule, every time.
AI architecture
The analysis runs on Claude Opus at temperature zero, so the same contract and the same policy produce the same requirement set rather than a different reading each time it runs. If the primary path fails, the job falls through a chain on Amazon Bedrock rather than failing in front of the customer, and every fallback is logged.
Documents are handed to the model as native PDF blocks and read visually, not flattened to text first. That matters for this work specifically, because ACORD 25 certificates and endorsement schedules carry meaning in their layout: which box is checked, which section a line sits in, what the Description of Operations actually says.
Citation discipline is the part that makes the output auditable. Every finding carries the contract language and the coverage language verbatim, copied from the source, with the form number, section, or endorsement identifier included where it is visible. If the supporting language does not exist in the document, the field is set to null. The model is instructed never to reconstruct a citation from memory, because an agent takes these into calls with carriers, insureds, and auditors, and one invented quote ends the tool's usefulness permanently.
The form logic is where the domain knowledge concentrates. Form numbers get normalized across notations, so CG 2010 and CG 20 10 04 13 are understood as the same form. Beyond notation, a difference between the required form and the one in evidence is classified rather than guessed at: forms with disjoint scope, like an ongoing-operations additional insured against a completed-operations one, or an auto AI against a general liability AI, resolve to NOT_MET, because no reading gets you from one to the other without a new endorsement. Forms with overlapping scope, like a blanket additional insured against a named one, resolve to AMBIGUOUS with the carrier question attached. The system is also explicitly barred from extracting requirements the contract never made, which is the failure mode that turns a compliance report into noise.
Accuracy is treated as an engineering problem with a harness behind it. The suite runs hand-labeled document fixtures through the real production prompt against the same model, scored with regex and numeric checks only, no model grading another model, so a score change always traces to a specific prompt, model, or fixture change rather than to a judge's mood. Every run is archived before scoring, and a free validation pass over every case runs as a hard gate in CI. That harness today covers the comparison engine rather than this module, and extending it to contract compliance is the obvious next step.
The results
Brenda's account of what the platform does is the one that matters, because she is checking its work against her own reading of the same contracts every day.
On policy comparison: "I love how it does policy comparisons as an actual risk advisor. It can find the coverage gaps and explain why it's a coverage gap based on the operations of the business." That second clause is the harder half. Naming a gap is pattern matching. Explaining why it is a gap for this insured, given what this business actually does, is the part that makes a finding usable in a client conversation.
On the module this study is about: "I greatly appreciate the contract comparison tool. I often have to sift through multiple contracts and review against the insurance program to make sure the insured is compliant. Producer HQ saves me so much time."
Her verdict, from a principal owner whose book makes contract review a daily obligation rather than an occasional one: "Producer HQ has been a game changer."