Record
The as-built sentence is not the attribute
A summary can sound like a record and still leave the feature unchanged.
A service line in the GIS is a set of attributes and a geometry. Material. Diameter, when the source has one. Status: active, retired, abandoned in place. The main it came from, the meter it serves. A field packet and a LocusView as-built are how those attributes get permission to change. The sentence someone writes about that work is a third thing. It can point at the attribute. It cannot replace it.
I learned the distinction by catching it in close-out notes. A comment would say the service was updated. The feature still showed steel. The packet showed polyethylene, with the old steel abandoned in place and capped at the main. “Updated” had described a hope about the database, not a value in it. The sentence was grammatical. The attribute was unchanged. QA does not accept the sentence as evidence that the attribute moved.
What a summary throws away
Models collapse this distinction quickly because they are built to summarize. A summary wants one subject and one verb. An as-built wants several fields that are allowed to disagree with the feature currently on the map. When a draft says the as-built documentation has been fully updated to reflect the latest field conditions, it has performed the summary and skipped the comparison. There is no material, no status, no packet identifier, and no statement of what the map still shows. The paragraph is about documentation in general. The job was about one service.
I mark that draft SOR, because no source is named, and INV if “fully updated” asserts a post that did not happen. The repair puts the attribute back in charge. Name the object the way the system names it. Name the source. Name the conflict if there is one.
The map feature still shows the retired steel stub. The field packet shows a PE service replaced to the meter. The LocusView as-built is in the packet and is not posted.
Three sentences, because three facts were being asked to share one verb. I would rather be plain than make them agree before the records agree.
Status words are not narratives
There is a second collapse. People, and models, promote a status value into a story. Abandoned in place has a physical meaning: the old pipe stays in the ground, usually capped at the main, and it is not the active service. A draft will turn that into a sentence about legacy infrastructure being retired as part of a replacement program. “Legacy” and “program” are not on the packet. Abandoned in place is. I mark the promotion TERM, and I put the value back. If the reader needs to know the old pipe was capped at the main, that clause comes from the packet too.
This matters for training data. If the corrected sample says “the replacement program modernized the service,” the model has been shown that a status code is an invitation to narrate. The next draft will narrate again, with a different program name. The attribute never gets a stable sentence. I keep the repair boring on purpose. Boring is how the value survives a second edit.
Geometry is the part prose drops
A mapper often cannot post from words alone, and prose is where the offset disappears. “East of the property line” is not a coordinate, but it is a check. If the as-built gives a station or an offset, the sentence for the mapper should carry that figure exactly as given, or it should refuse to invent one and tell the mapper to read the as-built. A coordinator may not need the offset in the first sentence. She may need to know the post is waiting on a comparison. The attribute list does not change because the audience did. The order does. I mark a mixed note AUD and split it, rather than delete the offset from the only version.
I use a small test when I edit. Cover the GIS and read only the paragraph. Could a skeptical coworker recreate the attribute change, or at least know which attributes are in dispute? If the answer is no, the paragraph is a caption without a figure. Then do the reverse. Look only at the attributes. Does the paragraph add a claim they do not support? Dates are the usual extra. A model likes to say the work was completed recently. Recent is not an installation date. If the packet has a date, use that date. If it does not, do not supply one to make the note feel current.
The sentence has a smaller job
None of this requires a literary style. The best repair is often less readable to a general audience and more readable to the person who will touch the feature. That is the correct trade. An as-built sentence that a stranger finds elegant, and a mapper cannot post, is a failed sentence. I came to AI text from the other direction: years of refusing to let a comment outrun a packet. I am not asking a model to write like a person with taste. I am asking it to keep the attribute, the source, and the sentence in their separate jobs.
When I build a training example from this, I include both layers. The bad layer is the summary that sounds like a record. The labels are usually SOR, with TERM or INV where a status word was upgraded. The repair quotes the attributes in ordinary words and stops. I do not add a closing line about data integrity. Integrity is the result of the check. It is not a sentence in the note. If the note needs a last line, the last line is the action: hold, or post, and the packet id either way.
Before I accept a paragraph about an as-built, I list the attributes it claims to change. If I cannot list them, the paragraph is not ready. The feature will still show what it showed this morning.