Every service line inventory has an unknown column, and every unknown eventually needs a story. Records get the easy ones; the rest require someone to look. As replacement planning matures, the verification of unknown service lines has become its own discipline, with a toolkit that runs from archival work to vacuum excavation. This is a survey of the methods systems are using and the tradeoffs among them.
Start with paper
Records review remains the cheapest classification per line when the records exist. Tap cards, plumbing permits, meter installation records, construction-era standards, and subdivision plats can all carry material information, and installation dates alone can support strong inferences where local code history is well documented. The weaknesses are equally familiar: records reflect what was installed, not what was later repaired or partially replaced, and record quality tends to be worst exactly where lead is most likely, in the oldest parts of the system.
Look where looking is cheap
Visual verification at accessible points, typically the meter pit or the point of entry into the building, upgrades a records inference to an observation at low cost. Field crews and, in some programs, customers themselves can identify material by color, sheen, and hardness, supported by the traditional scratch test and magnet check that separate lead from galvanized steel and copper. The limitation is structural: a service line has a utility side and a customer side, and either can have been replaced independently of the other. An observation at one point is evidence about that point, not about the whole line.
Dig where you must
Excavation remains the reference method. Potholing with vacuum excavation exposes the line at one or more locations with modest surface disruption, and some programs pair verification with replacement mobilization so a confirmed lead line can come out in the same visit. Costs vary widely with depth, surface restoration, and traffic control, which is why excavation is generally reserved for lines that records and visual inspection cannot resolve, and why site selection matters so much.
Models prioritize; agencies decide
Statistical and machine learning approaches have earned a place in most large verification programs, and it is important to be precise about what that place is. A well-built model, trained on verified outcomes and local covariates like installation era and neighborhood construction history, tells a program where unknowns are most likely to be lead so field resources go there first. Whether a model output may ever reclassify a line without physical evidence is a policy question, and primacy agency acceptance of statistical classification varies. Programs should get that answer in writing before building a strategy around it.
The workflow is the product
Verification generates data, and data handling is where programs quietly succeed or fail. Field observations need structured capture, photographs need consistent framing, and conflicting evidence needs an adjudication rule rather than an argument. Because inventories are public documents, every classification should be traceable to its evidence. As we argued in our analysis of the inventory as a system of record, the reputational cost of a wrong public answer exceeds the regulatory cost of a slow one.
Customer interaction deserves equal design attention. Much of the customer-side evidence sits inside private homes, which means scheduling, consent, and communication scripts are part of the verification toolkit. Programs that explain why the utility wants to see the basement plumbing, and what the homeowner gets in return, report better access than those that lead with regulatory citations. Where customer self-reporting is used, a photograph requirement with simple instructions materially improves reliability over a bare checkbox.
There is no single correct sequence through these methods, but successful programs share a shape: exhaust the paper, verify opportunistically wherever a crew is already on site, target excavation with a model, and treat every touchpoint as a chance to retire an unknown. The unknown column never resolves itself. It is worked down, line by line, by programs built to remember what they learn.