TrustLayerLabCoverageFit · the suitability layer · live
CoverageFit finds the gaps where risk lives.
The coverage exists. The documents have been received. The policy has been reviewed. CoverageFit uses your coverage requirements and your vendor’s policy to determine if the coverage fits the requirements. It tells you where it does, where it does not, and gives you control of an auditable process to resolve questions and issues.
Why it matters
Changing the focus of risk management.
Today the risk function spends its hours on the paperwork question: did the paper arrive, does it match the template. Verification answers that at scale, and it is most of the job today. What a certificate cannot answer is whether the coverage fits the work, and that is the question that decides a claim.
CoverageFit moves the attention. The reading and the fit judgment run on their own, the paperwork load falls away, and the risk manager’s time moves to the question that actually prevents a loss. It allows risk managers to focus on higher value work that requires their expertise and be more effective at managing risk.
A roofer works above three stories under a policy that excludes height work. The certificate passes; the claim is denied. That gap is only visible when the coverage is read against the job.
A generic $1M GL requirement is not wrong, it is just generic. Read against the trade, it tightens to match the real risk of that work.
When the reading is automated and the judgment is surfaced, one risk manager can stand behind a bigger, higher-exposure vendor set without adding headcount.
Quality inputs produce quality outputs.
Leveraging your requirements and the documents that already exist in the workflow creates the inputs that CoverageFit needs to give you the result you need.
- lives in
- the vendor record and the signed contract, documents the hiring company already holds
- enters
- when the admin, or the Procore / CMiC / Vista sync, creates the engagement
- becomes data
- the reader extracts it from the contract, attribute by attribute, each with a source and a confidence. No risk questionnaire.
- if missing
- an unknown attribute stays unknown on the record; the judgment never guesses around it
- lives in
- the insurance exhibit attached to that contract, or the company's standing vendor requirement (a platform record) when no bespoke exhibit exists
- enters
- at signature with the contract, or once, when the risk team sets the company standard
- becomes data
- an exhibit is read by the same reader, clause by clause, citations kept; a company standard is already structured data with its own provenance
- if missing
- the company standard stands in, and the gap between the standard and the actual work is itself a finding. The nightlife-venue engagement below runs on exactly this.
- lives in
- the vendor's policy documents
- enters
- through the document request: collection, with Fill & Sign for what needs signing
- becomes data
- PolicyReview's reading: page-cited coverage effects, live in the demo below
- if missing
- no policy, no judgment. The record shows collection incomplete and the chase continues automatically.
In this demo, the vendor’s policy is read live from a real filed form. Each scenario’s requirement summarizes a real, published exhibit, and the job and certificate limits are set per scenario so every run is repeatable.
1Who is hiring, and for what?
what every judgment is measured againstStart here, because a document is not suitable on its own. It is only suitable for a specific job and requirement, so those come first. In production this is your own account and vendor records; the platform already knows who you are and what you are hiring. For the demo, pick an identity to stand in.
- The job
- roofing subcontractor · construction · tear-off and re-roof, work at height
- read from the engagement’s contract
- The requirement it was hired under
- $1M/$2M GL incl. products-completed operations · $1M auto · $2M/$4M umbrella · additional insured + waiver of subrogation
- Requirement exhibit · PDFInsurance requirements for vendors and contractors (real, published) · the document this run is checked against
Both of these are readings too: the same reader, pointed at two documents the platform already holds. The demo pins them so every run is reproducible. Watch the full workflow, animated →
2The vendor’s documents arrive
The roofing subcontractor’s submission
Real filed forms, standing in as this engagement’s documents. Switch the scenario in step 1 and the submission changes with it.
- Loading sample forms…
Specimen forms from carriers’ public filings with state insurance regulators. Run one to read it and judge it against the engagement above.
Or play the vendor
Upload a policy PDF as the roofing subcontractor’s submission for this job. Same pipeline, same transparency.
Demo environment: use specimen forms or redacted documents only. Do not upload real policies or certificates. Uploads land in a public demo store, and intake is capped hourly.
Your form is read into coverage facts and judged inside the engagement set in step 1, under the same versioned rules as the samples. If no rule in scope speaks to your form, the run says so.
3Read, then judged for your engagement
Run a form. The whole pipeline appears here, stage by stage: the fingerprint, the queue, the reader and its instructions, the reading, and the judgment against your engagement.