ChatGPT will invent a test-square count. That’s a file-killer.

A desk reviewer does not kick a file back because the writing is ugly. They kick it back because a number they cannot verify is sitting where a finding should be. “Eight hail strikes per hundred square feet” looks like a finding. If that eight was never counted on the roof, it is a fabrication — and a plausible one is worse than a blank.

Generic writing tools will fill a missing count. They are built to produce a complete paragraph. A complete paragraph that invents a test-square number is a file-killer.

The blank the model cannot stand

You already know the input that produces this. The memo is thirty seconds of the drive home:

Roof’s got a bunch of hail hits up top. Gutters are dinged. Some water in the bedroom.

There is no slope. There is no test square. There is no count. A person writing the file by hand would have to either go back up, or write that the count was not taken. A general-purpose model does not do either of those things. It finishes the sentence.

Give that memo to a generic model and ask for a hail-loss narrative. You will get something that reads like this — not because the model is reckless, because completeness is the point of the product:

Inspection of the north slope documented approximately eight hail strikes per one hundred square feet within the test square, with associated granule loss and mat bruising consistent with a recent hail event.

Eight is a reasonable-sounding number. North is a reasonable-sounding slope. Test square is the right vocabulary. None of it was in the notes. The model borrowed the shape of a real file and supplied the facts a real file would have.

That is the failure mode. Not a wrong tone. A number that did not happen.

Why “eight” is worse than saying nothing

A missing count is a kickback. An invented count is a liability.

A reviewer who sees [count not documented] or a visible placeholder can send the file back for the number. That is annoying. It is also honest. The adjuster still owns the finding.

A reviewer who sees “eight hits per square” and a photo that does not support eight — or no test-square photo at all — has two reads, and both are bad:

• The count is made up. The rest of the file is now in doubt, including the parts you did document.
• The count is real and the photos are incomplete. Re-inspect.

Either way the file does not clear. If it does clear, you have put your name under a number you did not measure. You sign the report. The tool does not.

This is the same bucket as numbers a reviewer can’t stand behind. Adjectives bounce a file. A fake precise number can get it paid — until someone checks the square.

Side by side, same memo

Same thirty seconds. Same missing count. Two write-ups.

What you said

Roof’s got a bunch of hail hits up top. Gutters are dinged. Some water in the bedroom.

What a generic model tends to write

Hail impacts were observed on the north roof slope at a density of approximately eight strikes per one hundred square feet. Granule loss and bruising of the shingle mat were noted across the field of the slope. Gutters at the front elevation exhibit denting consistent with hail. Interior water staining in a bedroom is consistent with intrusion through a compromised roof covering.

It named a slope. It invented a density. It decided the gutters were hail. It tied the bedroom to the roof. None of that was in the memo. It reads like a file.

What the report should say when the count is not there

Hail impacts were observed on the roof covering [ADJUSTER TO CONFIRM: affected slopes and impact counts]. Gutters show denting [ADJUSTER TO CONFIRM: elevation, extent, functional condition]. Interior water damage was noted [ADJUSTER TO CONFIRM: room, extent, and measurements].

Every bracket is a trip you can still take, or a line you type from the photos you actually have. Nothing in that paragraph can be used against the rest of the file.

The difference is not style. It is whether the tool is allowed to prefer a finished sentence over a true one.

The test that tells you which tool you have

Run this on any writing tool you are considering, including ours. Use a memo that names no slope and no count. Read the first paragraph of output.

• If it contains a number that was not in the memo, the tool will write fiction when you are tired. Do not use it on a file you will sign.
• If it refuses the number and shows the gap, you can edit. The failure is visible.

LossNarrative is built so the second thing happens. If a count, measurement, or date is not in the photos, the memo, or the typed field data, the report writes [ADJUSTER TO CONFIRM]. It will not pick eight to sound finished.

That is not a slogan. It is the only safe default for a report a licensed adjuster signs. The typed test-square count always wins when it exists; when it does not exist, the report has to say so. How to take a square that survives review is here. This piece is about what happens when the square never made it into the notes and the software decides to help.

What to do on the roof so the model has nothing to invent

The software problem is downstream of a capture problem. If the count is in the file, there is nothing to fabricate.

• Chalk a 10-by-10 on every slope, including the clean ones. Zero is a count.
• Say the number out loud: “north slope test square, eleven hits.” Then type it.
• Shoot the locator, the full square, the close-ups. A count without those three frames is a number a reviewer can still throw out.

Ten minutes. The on-roof routine is the whole sequence. Do that, and a writing tool — ours or anyone’s — has facts to use instead of a hole to fill.

If you want to see a narrative that stops at the notes, the unedited hail sample was generated from six photos and a 90-second memo. Where the notes did not include a quantity, the scope table says so. LossNarrative will write the report. It will not invent the square.