TrustLayerLabThe build · CoverageFit
What is ready, where the work is, and how to deliver.
CoverageFit already runs against real documents, but this is a POC. This is the honest inventory of what is required to deliver a production-quality product a customer will pay for.
Where it stands today
Production Improvements
Runs today
- The reading. Real filed policy forms are read live into structured data. A read costs cents.
- The judgment. Coverage is compared to the requirement and the job, and the gaps are flagged. Deterministic, not a guess.
- The dollar limits. The limits the certificate shows are compared to the limits the requirement demands, and a shortfall is flagged with the difference stated in dollars.
- The ruling. A reviewer confirms, refutes, or waives each flag with a written reason, kept on the record.
- The pipeline. A real job queue and database with retries and recovery. This part is production-grade.
For production
- Read the full policy packet. The reader reads any document it is given; the demo ships single filed specimen forms because those are the documents that are public. A customer's real policy is a packet, the declarations page plus its forms, and production assembles that packet into one picture of coverage.
- Trade and state coverage. The demo judges a handful of construction trades in a few states. Production learns each new trade and state, proven on real policies, before customers there rely on it.
- Read any customer's requirement format. The demo reads the three published exhibits it ships with. Production reads whatever exhibit format a customer actually uses.
- The front end and integrations. The screens a customer signs into, the accounts and permissions behind them, the project-system connection, and the notice to accounts payable. Detailed in the plan below.
The plan
Four phases, about five months to a pilot.
Each phase ends at a named milestone: a thing the product can do that it could not do before. The bars overlap because the work does, and the durations differ because the work differs; the driver behind each estimate is in the table.
Delivery timeline
Duration~5 monthsPhases4 + contingencyPilotweek 18
Accuracy baseline◆
Live inputs◆
Full-policy read◆
Pilot◆
wk 0wk 3wk 9wk 13wk 18wk 20
| Phase | Weeks | What it delivers | What drives the estimate | Complete when |
|---|---|---|---|---|
| Prove the reading | wk 1-3 | Run the reader across TrustLayer's real policy documents. Set the accuracy baseline, and block any change that lowers it. | A narrow scope: an eval harness and a labeled document set. This is measurement work, not invention, which is why it is the shortest phase. The only requirement is access to the documents in week one. | The reading has a measured accuracy number on documents it has never seen, and a written list of the formats it cannot read yet. |
| Live inputs, any format | wk 4-9 | Read the requirement from any customer's exhibit format, not only the three published exhibits the demo ships with. Pull the job from the vendor record and the project sync, and capture the facts that live in drawings, height and hot work, with one question at setup. | The widest input variance in the plan: every customer writes its exhibit differently, and the formats are discovered, not designed. The range covers the unknown formats, not the known work. | A judgment runs on a new customer's own documents with no hand setup. |
| Whole-policy judgment | wk 9-13 | Assemble the full policy packet, the declarations page plus its forms, into one picture of coverage. The dollar-limit judgment already runs; the packet supplies the declarations-page numbers that feed it. | The known-hard product problem, kept narrow: packet assembly and form precedence, how an endorsement overrides the form beneath it. It starts at week 9, once the live-inputs work has settled the reading; it does not wait for the front end. | A vendor's complete policy produces one judged picture of coverage, including limits. |
| Front end and integrations | wk 6-18 | The screens a customer signs into (the risk manager's queue, the broker's ruling screen), the accounts and permissions behind them, and one integration: Procore, CMiC, and Vista are the project systems construction customers already run, and the connection pulls each vendor and job from them so nothing is re-typed. The finance step needs no integration; an unresolved flag sends a notice to accounts payable before the vendor is paid. | The longest track, and the least uncertain. The screens, accounts, and permissions are standard build. It runs in parallel because it does not depend on the reading work, and its pace is set partly by the project-system connection, which involves an outside party. | A pilot customer runs it with their own broker, and an unresolved flag raises a notice at accounts payable before payment. The pilot begins. |
The estimates come from the experience of building this POC: one builder directing AI agents produced the pipeline, the reading engine, and the front end shown in the demo, and the build assumes the same approach. That is why the go-to-market’s engineering line is a ceiling, not a required headcount: a conventional small team fits under it, and this approach runs well under it. Weeks 19 and 20 are contingency. One rule holds through every phase: a change that lowers reading accuracy on documents the system has never seen does not ship.
The risks
Risks, and how the plan manages them.
- Reading accuracy on documents it has not seen.Today the reader is proven on public filed specimen forms, a limited set. The fix is TrustLayer's own library: hundreds of thousands of real policy documents to measure against and learn from. Give the reader that catalog and accuracy becomes a measured, improvable number instead of a hope.
- Outside parties set part of the pace.Document access needs TrustLayer, and the project-system connection needs Procore, CMiC, or Vista cooperation. The phases are ordered so the work that needs no one else runs first; a late dependency moves dates, not the order of the work.