Warranty entries, one per product.
The Warranty Compiler is the Trueleveler engine that builds one warranty entry per product from approved submittals and purchase orders. Aggregates approved submittal_revisions and procurement_items for the project, then composes one warranty entry per manufactured product with term_months (spec-stated, manufacturer-published, or industry-standard), start date aligned to substantial completion, conditions, and exclusions. Persists each entry to the warranties table for the closeout package. Flags unmatched submittals for PM follow-up.
Try it now
Warranty Compiler runs on your approved submittals and POs and needs a free account (no card). It has no sample data yet, and the no-signup demo only levels bids.
248 installed products. One warranty register.
A typical mid-size CRE project installs 200–400 distinct manufactured products. Each has its own warranty — spec-stated, manufacturer-published, or industry-standard. Closeout day, the owner expects all of them listed in one matrix with terms, expirations, and claim contacts. Most GCs build this by hand the week before delivery and miss 15–25% of products.
Warranty Compiler reads every approved submittal and every procurement_item in the project's tables and matches them in three tiers, most certain first: a confirmed link if the submittal was pushed to procurement directly, then a real manufacturer+model match when both sides have that data, then AI-assisted description/CSI matching as the fallback for whatever's left. Three-tier term resolution: spec-stated term wins, manufacturer-published term is fallback, industry-standard term is last resort. Start dates default to the project's substantial completion date, editable per warranty if a specific product's clock should run from a different date instead. Each entry persists to the warranties table that Closeout Builder reads.
From submittal approval. Through warranty period.
Warranty Compiler is built to run repeatedly — not once at closeout. The first run, mid-project, is the most valuable because it catches the gaps while you still have leverage with the subs.
- First mid-project run — 60–75% installed. Surfaces submittals approved without warranty PDF attached. PM chases the sub to upload before final pay app withholding becomes the leverage point.
- Monthly before closeout — new submittals approved each month, new POs issued. Compile keeps the warranty register current.
- Substantial completion — final compile feeds Closeout Builder. Warranty matrix is rendered, terms confirmed, claim contacts validated.
- Warranty period — persisted entries become a live tracker. T-90 / T-30 / T-0 day expiration alerts fire from this register.
Nothing. The project already has it.
Server-side aggregation engine. The trigger button replaces an upload form — everything's already in the project's tables.
Approved revisions
submittal_revisions table. Each row carries the approved cut-sheet, the spec section it satisfies, and any warranty PDF the sub attached at approval. When the cut-sheet states a manufacturer and model, the engine extracts them (quoted from the text, never guessed) to power the real match below.
Purchase orders + deliveries
procurement_items table. Each PO carries quantity, supplier, delivery date, and manufacturer/model when the PM entered them. Matches to submittals in order of certainty: a Push-to-Procurement link first, then manufacturer+model when both sides have it, then description/CSI matching as the fallback.
Substantial completion date
Default warranty start for every product on the register. If a specific product's clock should run from a different date instead, edit that one warranty's start date directly; it's a manual PM call, not an automated per-spec resolution.
One row per product. Source-tagged term.
Sample compile output for a 14-story office build, showing the three-tier term resolution and the unmatched flag for PM follow-up:
Persisted warranty entries grouped by manufacturer, term + conditions per product with source attribution, unmatched-submittals list with the suggested PM action per item, and the matrix Closeout Builder consumes directly. Industry-standard terms are explicitly flagged so the PM verifies the high-stakes ones (chillers, switchgear) by phoning the manufacturer.
Submittals + POs in. Closeout matrix out.
Warranty Compiler is the inflection point between the project-phase trackers and the closeout deliverable. It reads from two trackers, persists to one table, feeds one downstream engine.
- Submittals — supplies approved submittal_revisions with cut-sheet + warranty PDF attachments. The CSI spec section tells the engine which warranty terms section to check.
- Procurement — supplies purchase orders + delivery dates that confirm the submitted product was actually bought. Matched via a Push-to-Procurement link, a real manufacturer+model match, or description/CSI matching, most certain first.
- Closeout Builder — consumes the persisted warranties for the package's warranty matrix section. Carries-data badge fires on this chain.
- Closeout package — the deliverables booklet renders the matrix as a bound section with one row per product, sorted by spec section.
Things everyone asks first.
What if the manufacturer warranty PDF wasn't attached at submittal approval?
The engine still composes the entry using the manufacturer-published or industry-standard term, but flags the row as "warranty PDF missing." The unmatched list surfaces the gap for PM follow-up. Best practice: chase the sub to upload before closeout day. Worst case: the matrix carries the term but the owner can't see the original document.
How does it handle multi-tier warranties (parts + labor + extended)?
Today, one product gets one tracked term and one expiration date — when the spec lists a shorter labor term alongside a longer equipment term, the engine resolves a single term for the matrix rather than tracking each separately. Structured multi-tier warranties (separate labor / equipment / extended entries, each with its own date) are on the roadmap, not built yet.
What about installed-by warranties (workmanship)?
Workmanship warranties come from the installing sub's contract, not from the manufacturer. v1 of Warranty Compiler handles manufacturer warranties; workmanship warranties are pulled from contract_review at closeout time as a separate matrix section in Closeout Builder. v1.1 will merge both into one unified register.
Does it integrate with manufacturer warranty registration portals?
v1 doesn't auto-register on the manufacturer's portal — that varies too much by brand (Carrier, Trane, Schlage all have different flows), and registration happens after the product is actually installed, which is information no submittal or PO can supply ahead of time. Registering each product is on the PM, done directly with the manufacturer. Bulk auto-registration is on the v4.2 roadmap.
How are unmatched submittals different from unmatched POs?
Unmatched submittal = approved cut-sheet with no confirmed PO counterpart (no Push-to-Procurement link, no manufacturer+model match, and no plausible description/CSI match either). Often a substitution that was approved but never procured. Unmatched PO = procurement record with no approved submittal match. Often a small-quantity buy without formal submittal flow. Both flag separately so the PM resolves the right gap.
How exactly does the submittal-to-procurement match work?
Three tiers, most certain first. (1) If the submittal was pushed straight to a procurement item via the "Push to Procurement" action, that pairing is used as-is — no guessing. (2) Otherwise, if both the submittal and a procurement item have a manufacturer and model on file, the engine does a real, code-level match (case-insensitive, whitespace-trimmed) — not an AI guess. Submittal manufacturer/model come from AI extraction off the cut-sheet text (quoted, never invented; blank when the text doesn't state one); procurement manufacturer/model are PM-entered on the item, since purchase orders don't carry them as structured fields. (3) Whatever's left after tiers 1 and 2 falls back to AI-assisted description/CSI/vendor-text matching, the same best-effort matching this engine always did. On a project where submittals and POs haven't been tagged with manufacturer/model yet, most matches still land in tier 3 — tiers 1 and 2 get stronger as more of the project's data is populated.
Run it on a live project. See what's missing.
If your project is 50% installed, Warranty Compiler will surface every approved submittal without a manufacturer warranty PDF in 30 seconds. That's the list to give your subs before final pay app withholding becomes the conversation.
Try Free for 14 Days →