AI Adoption GuideInsuranceIssue
Endorsement language drafting
LLM drafts endorsement wording for coverage changes, formatted for approval and dispatch.
Insurance processQuoteUnderwriteBindIssueBillServiceRenewClaim
By Don, DoneThat’s AI coach · updated
What a usable endorsement draft contains
A usable draft names the requested coverage change and cites the form-library edition that would carry it. That pair is the quality bar. Counsel or underwriting still approves the wording. The draft is not issued, not bound, and not dispatched until a human signs it.
The model is a drafting assistant in front of issuance. It does not choose coverage. It does not invent a manuscript clause when the library has no parent form. Empty stays empty. Wording that reads well but cannot point at an edition is not ready for the approval queue.
What the draft must show:
- The requested change, in the requester's terms and in coverage terms (party, interest or limit, effective date if supplied).
- The parent form identifier and edition from the carrier's form library, or an explicit blank where no parent exists.
- A header that the text is a draft pending underwriting or counsel approval.
- No issuance stamp, no dispatch language, and no "attached and made part of" clause that would only be true after issue.
If those four are present, a reviewer can accept, edit, or reject without reconstructing the model's homework.
Load the change request and the form library together
Do not draft from the request alone. Load the change packet and the form library in the same pass, then write.
The change packet is whatever your shop already captures: broker email, underwriting worksheet, agency portal note, or a structured endorsement request from the policy admin system. Policy administration platforms (Guidewire, Duck Creek, Sapiens, Majesco, and peers) hold the in-force policy, the transaction type, and often a pointer to the form set. Treat them as the system of record for what is on the policy today, not as a license to generate new clause text.
The form library is the second source: the editioned bureau, company, or manuscript inventory your filing and product teams maintain. Matching is not a fuzzy resemblance to an additional-insured grant. The requested change must map to a form code and edition valid for this product, state, and policy period. When superseding editions exist, use the edition that belongs on this contract, not the newest file on a shared drive.
Load order:
- Identify the in-force form set and edition dates from the policy, not from memory.
- Read the requested change as a coverage instruction (interest, party, location, limit, exclusion, or condition).
- Search the library for a parent form that already expresses that instruction for this product and jurisdiction.
- If a parent exists, pull that edition (or the carrier's approved variant) into the drafting context.
- If no parent exists, stop the wording path. Record the miss. Do not fill the clause body.
A request-only prompt often yields a complete-sounding paragraph with no form code and no edition date. That is a draft with no library cite, the first failure mode. Reject it on sight and send it back to the load step.
When the request is a coverage the filed program does not contemplate, do not stretch a nearby form. Route it as a coverage exception before anyone writes clause text. That is the same discipline as non-standard coverage routing: unusual asks leave the standard drafting path.
Cite the edition, or leave the wording blank
Once request and library are in context, the model drafts. Every non-blank draft must cite the form identifier plus edition (and jurisdiction or product variant if the library distinguishes them). The endorsement body should track the parent form: schedule items filled from the request, boilerplate left as the filed edition states it.
Leave blanks when the library is silent. If there is no parent form for the requested change, the clause body stays empty. The output can still restate the request, name the search that failed, and flag the file for manuscript review by counsel or product. It must not invent a manuscript clause to look finished.
Inventing a manuscript clause is the second failure mode. It shows up as original prose that resembles filed language, with no form code, no edition, and no approved variance trail. That text gets treated as company manuscript, then issued, then found in an audit or a claim. No parent form means no clause body.
Illustrative example. A mid-term request asks to add a landlord as additional insured on a commercial package, premises liability only, effective the lease date on the worksheet. The load step finds the in-force general liability coverage part and a company additional-insured form for managers or lessors of premises, with a dated edition filed for the state. The draft returns the requested change (landlord named, premises address from the worksheet, premises-only grant), a cite to that form and edition, schedule fields filled from the request, and a header that the text is pending underwriting approval. If the library had no lessors form for this product, the same run would return the request restated, a library-miss note, and a blank clause body. It would not compose a custom additional-insured paragraph to be helpful.
Reviewers should confirm the cite matches a form on this policy's library slice, schedule values come from the request rather than a guessed name or address, and a blank body is a documented library miss rather than a dropped cite. A blank with a documented miss is a quality pass. A filled body with no edition is a fail.
Underwriting approves; the draft does not issue
Counsel or underwriting still approves. The model does not auto-issue. Treating the draft as issued is the third failure mode.
The draft is work product in a pending endorsement transaction. It is not an issued form, not a binder, and not correspondence to the agency or insured. Stamping it onto the jacket, assembling a full contract package, or sending it because the wording looks right skips the control that makes the quality outcome real.
Approval is a person reading the requested change against the cited edition and either accepting the draft as wording to issue, editing within the filed form (schedule corrections, named-insured style, premises description), rejecting the library match and sending the item to manuscript or product, or declining the coverage change. Until one of those happens, keep the transaction unissued.
Do not let a completed-looking clause trigger automated policy document assembly. Assembly is for approved forms and schedules. Feeding it an uncited or unapproved draft is how invented language reaches the insured. After approval, check issued pages against the approved draft, the cited edition, and the request. That check is issuance accuracy verification, not a second drafting pass.
Keep the header explicit (draft, not issued, pending underwriting approval) so completeness is not mistaken for authority.
Where drafting stops and the mid-term transaction begins
Endorsement language drafting is one station, not the whole mid-term change. If the request is outside the filed program, route it before this station writes a clause. If it is a standard change with a library parent, draft here, approve, then let the mid-term transaction carry effective date, premium, and dispatch. The operational sibling is mid-term endorsement processing agent: processing moves the endorsement through the policy admin system. Drafting only prepares wording for that move.
Do not collapse the two. A processed endorsement with no edition cite is still a quality miss. A cited draft that was never approved is still unissued on purpose.
Load request and library together. Cite the parent edition on every non-blank draft. Leave the clause empty when the library has no parent, and do not invent manuscript. Underwriting or counsel approves; nothing auto-issues from the model. Reject drafts with no library cite, and reject any path that treats a draft as issued.
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