The challenge
Brenda Noriega runs Noriega Risk Partners with a heavy construction book, so contract review is not an occasional task. It is the job. Construction contracts arrive with insurance schedules attached, and somebody has to read each schedule against the insured's actual program 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, in indemnification clauses, and in references to protocols like OCIP and CCIP. A clause reading "subcontractor shall maintain the coverages described in Exhibit C" makes Exhibit C a requirements document too. The coverage evidence is just as scattered: a monoline insured might carry general liability, auto, and umbrella on three different carriers, with real coverage spread across declarations pages, endorsement schedules, and wrap endorsements that bundle twenty or thirty 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. The 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. A compliance tool an agent cannot audit is one they cannot defend.
It runs as two passes. The pre-check reads the contract against the insured's policies and answers whether the coverage contains what the contract demands. The post-check reads the drafted certificate against the same contract and answers a different question: whether the certificate's own text reflects what was required. Those fail in different ways. A certificate can show a limit the policy does not carry, leave the additional insured box unchecked, or fall back on generic ACORD cancellation language with no teeth. Catching certificate defects is a separate problem from verifying the policy behind them, so the system treats them separately.
The output is deliberately not pass or fail. Every requirement gets one of four statuses. MET and NOT_MET mean what they say. AMBIGUOUS means the coverage might satisfy the requirement but needs a carrier confirmation, and it comes with the specific question to ask. POSSIBLE_SCOPE_MISMATCH is advisory, for a requirement that does not fit the work being performed, like pollution liability on interior cabinetry, so an agent has grounds to push back on a third-party reviewer.
AMBIGUOUS is the design decision that matters most. Forcing 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 does it silently. An agency's E&O position is strongest when ambiguous findings get resolved by a documented carrier call, so the engine surfaces the question with a next step rather than prejudging an answer only the carrier can give.
The overall verdict is mechanical. Any NOT_MET makes the report non-compliant. Any AMBIGUOUS with no gaps makes it partial: verify, then you are clear. Advisories never change the verdict. Same inputs, same rule, every time.
AI architecture
The analysis runs on a frontier large language model. Requirement decomposition is canonical and the overall verdict is a mechanical rule over the findings, so those parts reproduce exactly, every run. The platform does not claim the model layer itself is deterministic. Temperature zero is widely assumed to buy that, and in our own testing it did not: we recorded opposite readings on byte-identical input. So reproducibility is earned in the mechanical layers, and model output is validated against a schema and verified against the source document rather than trusted to repeat itself. If the primary path fails, the job falls through a chain on Amazon Bedrock instead of failing in front of the customer, and every fallback is logged.
Documents reach the model as native PDF blocks, read visually rather than flattened to text. That matters here 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 makes the output auditable. Every finding carries the contract language and the coverage language verbatim, with the form number, section, or endorsement identifier where visible. If the supporting language does not exist in the document, the field is set to null. The model is never allowed to reconstruct a citation from memory, because agents take these quotes 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. A real 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, resolve to NOT_MET, because no reading bridges them 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 barred from extracting requirements the contract never made, the failure mode that turns a compliance report into noise.
Accuracy is treated as an engineering problem with a harness behind it. Hand-labeled document fixtures run through the real production prompt against the same model, scored with regex and numeric checks only, no model grading another model. A score change always traces to a specific prompt, model, or fixture change. 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; extending it to contract compliance is the obvious next step.
The results
Brenda checks the platform's work against her own reading of the same contracts every day, so her account is the one that matters.
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." The 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 does, is what 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 for whom contract review is a daily obligation: "Producer HQ has been a game changer."
What it looks like
