Lead Service Line Inventory Software: Turning Handwritten Tap Cards Into a Defensible Public Inventory

Why the lead inventory is a records problem wearing a software costume

A distribution manager at a city water department opens a drawer of tap cards. Handwritten, index card size, one per service connection, going back to the 1920s. Some say lead. Some say galv. Some say a word nobody can read. Some cards exist for addresses that were demolished in 1974. The billing system has 62,000 active accounts and a service line material field that was populated once, in 2003, by someone who is retired. The GIS has service line stubs drawn as straight lines from the main to the parcel centroid, which is cartography, not evidence. The state wants an inventory, the federal rule wants unknowns eliminated over time, and every household on the lead or unknown list has to be told.

The market around this is real and mostly competent. BlueConduit does statistical prediction of service line material. 120Water and Trinnex leadCAST handle inventory and programme management. Esri holds the geography. Any of them will get a mid-sized system through an initial submission. What none of them solves is the part that actually consumes your year: reconciling four record sets that disagree, at parcel level, with an evidence trail strong enough that when a resident's attorney asks why their home was classified as non-lead, you can show the card, the dig photo, and the date.

The rule timeline is public and worth stating plainly. The Lead and Copper Rule Revisions required water systems to prepare an initial service line inventory by October 16, 2024. The Lead and Copper Rule Improvements, finalised in October 2024, carry a compliance date in 2027 and a general expectation of replacement over roughly ten years, with inventory updates and customer notification obligations running throughout. Your specific duties come from your state primacy agency, not from a blog, and they vary. What does not vary is the operational reality: this is a decade-long records and construction programme, and the software you pick in year one is the software you live in for ten.

Problem 1: four record sets that disagree, and no rule for who wins

You have tap cards, plat books, permit records, the customer information system, the GIS, work order history from the last twenty years, and whatever the meter shop knows. They conflict. The card says lead, the 1998 work order says the service was replaced during a main job, the CIS still says unknown, and the meter reader remembers copper at the meter but the meter is inside the basement so that says nothing about what is buried in the yard.

Off-the-shelf inventory tools accept a material value per parcel. That is the output, not the work. They generally have no opinion about how you got there, which means the reconciliation logic ends up in a consultant's spreadsheet and the resulting inventory is a number without a parentage. Two years later someone asks how a specific address was determined and the answer is a file share.

What a custom build does: make evidence a first class record. Each service connection accumulates evidence items, each with a source, a date, a material assertion for the utility side or the customer side, a confidence, and a link to the scan or photo. Then a deterministic rule set you define decides the classification and shows its reasoning: a verified dig beats a work order, a work order beats a tap card, a tap card beats a CIS field that nobody has touched since 2003. When a rule changes, everything reclassifies and you can see exactly which addresses moved and why. That reasoning trail is the whole deliverable, and it is the part no packaged tool will hold for you in your own hierarchy.

Problem 2: predictive modelling is only as honest as your own verification digs

Statistical prediction is legitimate and useful. Given enough verified connections, install year, neighbourhood, main material and parcel characteristics, a model will tell you which unknowns are most likely to be lead, which is how you avoid digging 3,000 holes at random. BlueConduit built a real business on exactly this and the approach works.

The failure is in how it gets used. A model trained on another city's data, or on your data before you had a representative verification sample, produces confident numbers that are wrong in a specific direction, and the direction matters because a false non-lead classification is the one that ends up in a newspaper. Verification digs also have to be selected to inform the model, not just to clear the easiest addresses, and utilities routinely dig where the crew was already working, which biases the sample.

What a custom build does: treat the model as a tenant in your system rather than the system itself. Predictions are stored as evidence with a version and a confidence, never as a material determination, and the interface always shows a predicted classification differently from a verified one. Verification sampling is planned by the system to reduce uncertainty where it is highest, and every completed dig feeds back into recalibration. The number you report to the state is then traceable to a model version and a training set that existed on a specific date, which is the only way that number survives scrutiny.

Problem 3: half the pipe is not yours and you still have to classify it

The customer-owned side is where inventories go to die. You need to know the material between the curb stop and the building, on private property, for tens of thousands of homes, and you have no records because you never installed it. So you send letters, run a self-reporting form, ask crews to look during meter work, and dig where you can.

The self-reporting route works better than people expect and worse than the vendor demos suggest. Residents will do a scratch-and-magnet test if the instructions are genuinely simple and the form works on a phone in one minute. They will not do it if the form asks them to create an account. Response rates in the programmes we have supported climb sharply when the letter carries a parcel-specific link and the form is three questions with a photo upload.

What a custom build does: a public-facing self-report flow with no login, tied to the parcel by a token in the mailing, that accepts a photo and produces an evidence item with a lower confidence than a crew verification. Then a review queue where staff confirm or reject based on the photo, because a resident photographing a galvanised nipple on a copper line is common. The same build handles consent for replacement on private property, which becomes the binding constraint later in the programme and which almost nobody plans for in year one.

Problem 4: the inventory is a live document with legal deadlines attached

The inventory is not a report you file once. It updates as digs happen, it triggers customer notification when a classification is lead, galvanised requiring replacement, or unknown, and notification has its own timing requirement. Systems above a size threshold have to publish it in a form the public can search. Every one of those obligations has a date attached and a paper trail expectation behind it.

What a custom build does: notification is generated by classification change, with a record of what was sent, to which address, on what date, by what method, and what came back undeliverable. The public-facing inventory is published from the same data rather than exported and uploaded, so it cannot drift from the internal record. Undeliverable mail becomes a work queue rather than a pile. When the state asks for proof that a household was notified, it takes a search rather than a records request to your own mailroom.

Problem 5: replacement is a construction programme the inventory has to drive

Once replacement starts, the inventory becomes the work list. Blocks get bundled for efficiency, contractors get assigned, consent has to be in hand before anyone touches private property, funding sources have their own reporting, and the disturbed-line flushing and filter distribution obligations follow each replacement. Utilities that treated the inventory as a compliance filing discover in year two that they now need a construction management system and the inventory tool cannot become one.

What a custom build does: replacement packages assembled from the inventory with geographic bundling, consent status, and funding source tagged per address, then pushed to whatever work order system you already run rather than replacing it. Completion feeds back as verification evidence, which closes the loop between construction and inventory automatically. Grant and state revolving fund reporting is generated from the same records, which is the difference between a two-day report and a two-week one.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the shape. A focused first release covering record ingestion and reconciliation with an evidence trail, per-parcel classification with a rule set you control, the public inventory, and the notification list runs $50,000 to $110,000 and ships in 10 to 14 weeks. A full programme platform adding field verification workflow with mobile capture, model calibration on your own digs, resident self-reporting, consent tracking, replacement bundling and funding reporting runs $120,000 to $300,000 phased over 5 to 10 months.

What pushes cost up: the volume and condition of paper records, because digitising 60,000 handwritten tap cards is a real line item and handwriting recognition on 1930s cursive needs human review at a rate you should budget honestly. Integration with an older customer information system, which is often the hardest technical part of the whole project. Any requirement to write into an existing Cityworks or similar work order system rather than alongside it. And multiple pressure zones or acquired systems with separate record conventions, which effectively multiplies the reconciliation work.

What keeps cost down: start with the addresses that drive notification obligations, meaning lead, galvanised requiring replacement, and unknowns in your oldest service areas. The confirmed non-lead population can be reconciled later at leisure.

Build versus buy, and when buying is right

Buy if you serve fewer than roughly 15,000 connections, especially if your system was built after 1988 and your records are in reasonable shape. 120Water and Trinnex leadCAST are built for exactly this and will get you compliant for a fraction of a custom build. Buy also if your inventory is nearly complete and your remaining work is replacement scheduling, since that is closer to standard construction management.

Build when two or more of these are true. You serve above roughly 40,000 connections with a large unknown population. Your records are paper, contradictory, and span more than one acquired system. You already run substantial GIS and work order infrastructure that a packaged tool would duplicate badly. Your replacement programme is a named capital line worth tens of millions and will run for a decade, which means the software is an asset, not a subscription. Or your state has submission requirements that the packaged tools support awkwardly, which is more common than the vendors admit.

Our position: the inventory itself is not a hard piece of software. The hard part is that you are building the evidence base for a ten year, publicly scrutinised programme touching every household you serve, and the classification logic behind it should belong to you rather than sit inside a vendor's model. If you will be running this in 2035, own it.

How to choose a developer for lead service line software

Ask them how a single address gets classified. If the answer is a material field, they are building a spreadsheet with a map. If they describe evidence items with sources, confidences, and a precedence rule you can change, they understand what you are actually buying.

Ask how they distinguish a predicted classification from a verified one everywhere in the interface and in every export. Any ambiguity there is a future news story.

Ask what they have integrated. Older customer information systems, Esri, and municipal work order platforms are three different problems, and the CIS is usually the one that eats the schedule. Ask for the specific product and version.

Ask how they will handle 60,000 scanned cards, and expect an honest answer that involves automated extraction with human review rather than a claim about accuracy.

Ask who owns the code and the data before kickoff. You should own the repository, the cloud accounts, and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, which matters on a programme measured in decades.

Start by pulling fifty addresses where your records disagree and walking a developer through how you would resolve each one. Your answers to those fifty are the specification.