Skip to main content
DoneThat

AI Adoption GuideConstructionHandover

Warranty Register Extraction

LLM extracts warranty terms, durations, and conditions from supplier submissions and generates a structured register with expiry alerts.

Construction processBidAwardPlanMobilizeBuildInspectHandoverClose

By Don, DoneThat’s AI coach · updated

Pull the register from the pack, not from a template

The warranty register at handover is a quality artefact: each row is a claim that a named supplier promised a named term, for a named duration, under named conditions, in a named document. If the submission does not state a field, that field stays empty. The extraction task is to copy what the pack says, then stop.

A leftover spreadsheet from the last project is useful for columns. It is not a source. Filling "12 months" because the last joinery package carried that figure is invention. When a new submission has no warranty paragraph, the duration stays blank.

Common project platforms such as Autodesk and Procore already hold the transmittals and close-out PDFs. Extraction reads those files. It does not replace the platform, and a folder named "Warranties" does not prove a term exists. A file with no operative language still yields empty cells.

A commercial lead needs one answer: what cover do we actually have, and where is it written? Anything that cannot survive that question is not a populated cell.

Record the term only when the submission states it

The term is the supplier's promise in the supplier's words. Extract the operative sentence. Add a short label only if the label does not change meaning. "Ten-year materials warranty on the waterproofing membrane" stays that. Do not rewrite it as "standard product warranty" and drop the materials-only limit.

Work the submission in order: identify the product, find warranty or guarantee language, copy the term, copy any stated duration, copy the start rule if one exists, copy conditions and exclusions, attach a cite to each populated field. If a step finds nothing, leave that field empty. Do not back-fill from memory, from another package, or from a default table.

Refuse inventing a 12-month default. Twelve months is a common defects period in some contracts. It is not a universal supplier warranty. Manufacturer letters may be silent on duration, may split materials and workmanship, or may grant nothing until a registration form is returned. A model that always emits "12 months" looks complete and is wrong. Empty stays empty if the submission has no term.

Where two documents in the same package disagree, do not average them. Record both rows with separate cites, or note the conflict and keep durations blank until someone picks the governing text.

Durations and start dates: cite or leave blank

Duration is three pieces: length, unit, and when the clock starts. "Fifteen years" without a start rule is incomplete. "Fifteen years from practical completion" is not the same as "fifteen years from delivery to site" or "fifteen years from the approved installer certificate". Extract only the start rule the cite supports.

Do not start the clock from practical completion unless the cite says so. PC is a convenient project date, not the default for manufacturer cover. Using PC because the handover programme is organised around it mis-states expiry and mixes a supplier warranty with the defect liability period tracking agent. DLP is a contract mechanism between employer and contractor. A supplier warranty is a separate promise. They may run in parallel. They do not share a start date unless the documents say they do.

Do not start DLP from the wrong date and then copy that date into the warranty register. Sectional completion, delayed PC, or a disputed taking-over certificate will poison every warranty row that inherited the wrong trigger. Keep the registers separate. DLP tracking owns contract dates. Warranty extraction owns only dates written in the supplier submission.

If the start event has not happened yet (certificate not lodged, registration not confirmed), record the rule and leave calendar expiry blank. An alert that needs a date must not invent one.

Extract conditions without turning them into cover

Conditions decide whether the term bites: approved installer, maintenance regime, damage by other trades, storage limits, a deadline to register after installation. Extract them as short clauses on the same cite as the term. A fifteen-year duration with the registration deadline stripped off is not the warranty the supplier offered.

Do not elevate a condition into a duration. "Cover continues provided annual inspections are recorded" is not "indefinite". Do not collapse exclusions into a yes/no valid flag. Show the exclusion in words so a later reader can test it against site events.

The O and M manual auto-assembly often reprints the same manufacturer pages. Use that pack as a second place to look for the cite, not as a reason to fill missing durations. A brochure without operative warranty language does not create a term. A duplicate of a letter already cited does not create a second row.

Cite the submission, then decide what may alert

Every populated field needs a pointer a third party can open: file name as stored on the project platform, page or clause, and the quoted span. "See warranties folder" is not a cite. A duration with no cite is not a register entry.

The handover package completeness check asks whether a warranty letter is present. Completeness can flag a missing file. Extraction must not invent the file. When the letter is absent, term, duration, start, and conditions stay empty. That empty row is evidence for subcontractor final payment verification that the paperwork is not there. An invented term would let verification pass on fiction.

An expiry alert may fire only when the row has a cited duration, a cited start rule, a computed expiry that follows from those two, and a cite on each. Refuse alerting on a row with no cite. A reminder that "joinery warranty expires next month" when nobody can open the letter trains the team to trust noise.

If duration exists but the start rule does not, store the duration, keep expiry blank, and do not alert. If the start rule exists but duration does not, do the same in reverse. Partial rows are allowed. Partial alerts are not.

One pack, two products, two honest rows

A single close-out transmittal includes a roofing membrane letter and an ironmongery data sheet.

The membrane letter warrants the membrane for fifteen years from the date of installation on the approved installer certificate, excludes ponding caused by blocked outlets, and voids cover unless the certificate is lodged within twenty-eight days of completion of the roof. Extraction writes term as quoted, duration fifteen years, start rule equal to the certificate date, conditions for ponding and lodging, and a cite to that letter and page. If the certificate is in the pack, the start date can be filled from that cite. If it is not, the start rule stays as text and calendar expiry stays empty. No alert until both pieces are cited.

The ironmongery data sheet lists finishes, load ratings, and maintenance of moving parts. It has no warranty paragraph. Extraction writes empty term, duration, start, and conditions. No 12-month default. No clock from practical completion. No expiry alert. Completeness can still flag that a warranty letter was expected. The register stays honest: cited cover where the supplier wrote it, blanks where they did not, alerts only on rows a commercial lead can open and read.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first