Differentiator

Source-grounded extraction: every field shows the span it came from

Provenance here means field → document → page → character span. If the model cannot point at the slip, it must not fill the limit. Gaps become a chase list. Conflicts stay visible. Files stay in the tenant.

Provenance, on this site, is not a brand word. It is a field contract: every emitted value points at a document, a page or cell, and a character span. If the model cannot point at the slip, it must not fill the limit. Gaps become a chase list. Conflicts stay visible. Unverifiable text is not a third kind of success. It is a refusal.

That contract is what source-grounded extraction names in one sentence. This page is the long form: how a field is stored, how the fictional ACME Construction pack behaves, how gap differs from conflict and from unverifiable, why a ChatGPT treaty summary is a different product, what a read-only mailbox actually grants, and where Reinsure-8B sits in the loop. The glossary term is provenance. The queue of missing evidence is a chase list.

Field, document, page, span

An extracted field is not a string in a spreadsheet. It is a record.

• The field name the pack template expects: named insured, period, occurrence limit, deductible, TIV, attachment, hours clause, currency.
• The value, when there is one, stored as typed data rather than as a sentence.
• The source document: Slip.pdf, SOV.xlsx, LossRun.pdf, the covering email if that is truly where the only copy lives.
• The page, sheet, or cell: page 2, sheet Structure cell C7, the total row on the SOV.
• The character span or cell range: the exact snippet the value was copied from.
• A status: traced, gap, conflict, or unverifiable.

No span, no value. That is the whole rule. Confidence scores may exist in the product UI for operators who want a second look. They are not a licence to emit a limit. A high-confidence hallucination is still a hallucination. The product refuses the field and writes a gap.

Spreadsheets are first-class sources, not second-class PDFs. A TIV that lives in a total row must cite the sheet and the cell. A limit that lives only in a broker covering email must cite that email as the document, which is usually a reason to chase the slip rather than to trust the email. Operators already know covering emails drift. The pack should not pretend otherwise.

The same record is what an underwriter reviews. They do not re-key the limit into the workbench from a summary paragraph. They open the span, confirm the page, and accept, reject, or chase. That is how source-grounded extraction is defined for this product. It is also why a public chatbot paste is the wrong architecture: the paste has no tenant, no pack template, and no stored span.

Worked example: ACME Construction Ltd

The public inspector uses one fictional file so the site does not need a live client pack. ACME Construction Ltd, domain acme.example, property facultative. You can walk the fields in the sample pack inspector. The story on this page is the same file, written out.

The broker mailbox receives a zip. Slip.pdf page 1 names the insured ACME Construction Ltd and the period 1 January 2026 to 31 December 2026. Slip.pdf page 2 states an occurrence limit of USD 10,000,000 any one occurrence, and a TIV of USD 42,000,000. SOV.xlsx lists locations. The total row sums to USD 47,100,000. Page 4 of the exported SOV PDF, or the extra row in the workbook, is a warehouse that does not appear on the slip schedule. There is no hours clause in any document in the pack. There is no as-at date on the SOV.

Here is what the pack must do, field by field.

Named insured is traced. Document Slip.pdf, page 1, span ACME Construction Ltd. Period is traced to the same page. Occurrence limit is traced to page 2, span USD 10,000,000 any one occurrence. Those fields are ready for an underwriter to accept.

TIV is a conflict. Slip.pdf page 2 says USD 42,000,000. The SOV total row says USD 47,100,000. Both spans are stored. The pack does not emit a single TIV. It does not average 44.55 million. It does not pick the SOV "because schedules are more detailed" and bury the slip. The extra warehouse is part of the same conflict: a location exists on one document and not the other. That is evidence, not a cleanup task for the model.

Hours clause is a gap. No span in the pack. The field value is empty. The chase list carries an item: hours clause required, not found in Slip.pdf or the wording excerpts. SOV as-at date is a gap of the same kind. A stale or undated schedule is not a dated schedule.

A weaker system does something else. It completes the hours clause from a similar construction risk. It restates TIV as "approximately USD 45 million." It drops the warehouse because the slip schedule was shorter. At bind, nobody can show what was offered. At loss, the warehouse is either a coverage fight or a silent extra location in the accumulation view. The provenance contract exists to make that failure visible at intake, not at the claim.

Brokers assembling the outbound version of this file should start on the brokers hub. Reinsurers seeing it inbound should still get the same spans. The pack is the shared object. The mailbox is not.

Gap versus conflict versus unverifiable

Three statuses get collapsed in demos. They are not the same, and treating them as one "exception" bucket is how an underwriter stops trusting the queue.

A gap has no span. The pack template requires the field. No document in the file contains it. The correct behaviour is an empty value and a chase item that names the field, the reason it matters, and which document would usually carry it. Hours clause not found. As-at date not found. Unsigned slip. Missing loss run. A gap is honest absence.

A conflict has two or more spans that cannot both be true for the same field. Slip TIV versus SOV TIV. Occurrence limit on page 2 versus a different figure in the covering email. Named insured legal name on the slip versus a trading name on the SOV. The correct behaviour is to store every span and to refuse to pick a winner. Averaging is a lie. "Using the latest file" is a lie unless the latest file explicitly amends the earlier one and you can cite the amendment. Conflicts stay visible until a human chooses, or until a new document supersedes with its own span.

Unverifiable is different again. Text is present, but it cannot be tied to a field the template knows, or the page is unreadable, or the table is an image with no recoverable cells, or the clause is a manuscript scribble that does not map to a typed value. The correct behaviour is not to guess. It is to mark the region unverifiable and to chase a readable copy. Unverifiable is not a traced field with low confidence. It is a refusal to emit.

If you only have a binary — extracted or failed — you will either fill gaps with invented values or dump conflicts into failed and lose the evidence. The three-way split is the product. Chase lists are the queue of gaps, unresolved conflicts, and unverifiable regions that block a quote or a booking. That is the chase list in operational language, not a narrative summary of the file.

Why this beats a ChatGPT treaty summary

A treaty wording is fifty pages of definitions, attachments, exclusions, hours, reinstatements, and claims procedures. A general model asked to "summarise this treaty" will produce a fluent page. Fluency is the hazard. Summaries drop exclusions. They collapse a reinstatement formula into the word reinstatement. They restate an attachment from a heading and miss the manuscript carve-out on page 37. Binders then argue about what was said, not about what was written.

Citation is the product. A useful extraction of a treaty is a set of fields — attachment, limit, hours, reinstatement, territory, class, inception — each with a page and a span, plus a gap list for what the wording does not actually say. That is slower to read than a summary, and that is the point. Underwriters and accountants need the clause, not a paraphrase.

The same failure shows up on facultative slips. Ask a public model for the limit on a pack that contains two figures and it will pick one, or blend them, and speak in a complete sentence. Ask it for a hours clause that is not in the file and it will often supply a market-standard 72 hours. That is not assistance. That is AI hallucinating treaty terms. Mystery-shop any vendor by handing them a redacted slip with a torn schedule and asking for the TIV. If they answer with a number and no span, they have failed the contract this page describes.

A ChatGPT-style summary also has the wrong data path. Pasting a wording into a public endpoint is not tenant-scoped ingest. It is an export. Even a private GPT-style workspace that stores chats is not a pack: there is no field template, no conflict object, no chase list, no audit of who accepted a span. Reinsurance operations software can call a model. It cannot be a model with a prompt.

Reinsure-8B does not get a pass on this rule because it is domain-native. A domain model that emits an unsourced attachment is still unsourced. Pair the model with stored spans or you are back to summaries with better jargon.

Read-only mailbox

Brokers and reinsurers already live in email. The honest version of connect-your-inbox is a read-only grant: Microsoft 365 or Gmail, scoped to one mailbox or one folder, revocable from the same consent screen that created it. The connector copies submissions that arrive. It does not send mail as you. Write-access is a different trust boundary and a different product conversation.

Read-only mailbox ingestion is the short definition. The marketing site still does not take live client packs. The inspector on this website is the ACME sample. Production ingest is tenant-scoped. Every read belongs on an audit trail. If security review wants to see the grant, show the grant: read-only, one mailbox, revoke anytime. If they want you to forward packs to a vendor address, that is a different architecture and usually the wrong one.

Read-only does not mean the model may fill gaps because "the email implied the limit." The covering email is a document. If it is the only source, cite it and usually chase the slip. If it conflicts with the slip, it is a conflict. The mailbox is a transport. Provenance is still field to document to page to span.

Reinsure-8B in this loop

Reinsure-8B is the insurance-native small language model in the stack. It can be called via API or deployed in a customer environment. It is a model, not a system of record, and not a substitute for the pack. The loop is inbox to documents to extracted fields with spans to chase list to human accept or reject. The model proposes spans. The pack stores them. The underwriter decides.

Sovereignty matters for some buyers: weights in their environment, files in their tenant. Others start on an API. Neither mode allows unsourced numbers. Canonical model copy lives on the Reinsure-8B page and should stay aligned with the public model card. Do not treat a blog statistic as the model card. Do not treat this provenance page as a benchmark. This page is the field contract.

If a deployment wants to fine-tune on proprietary wordings, that happens inside the tenant on files the customer already holds. The marketing path does not train on live client packs uploaded through this website. That sentence is load-bearing for security review.

What operators actually review

The review surface is not a chat log. It is a pack.

• Traced fields with a click-through to page and span.
• Conflicts with both values and both sources, not a merged number.
• Gaps grouped as a chase list, named by field and missing document.
• Unverifiable regions that need a better scan, not a braver model.
• An audit of who accepted a field, who sent the chase, and which document version was in force.

That is the same object whether the buyer is a broker building an outbound pack or a reinsurer triaging inbound. The brokers hub is the outbound view. This page is the reason both views can share a file without sharing a hallucination. If you only remember one line: field, document, page, span — or it does not go in the pack.