Data center water questions now reach utilities through many channels. A developer may open with a call to a planning office, a council member may raise the topic at a public meeting, and a reporter may file a records request for the same correspondence weeks later. Each contact can produce a document, and each document can be asked for again. For a utility, the central question is less whether a request is reasonable and more whether staff can show, months afterward, who asked for what, when, and what was sent in reply.
The sector is paying attention. Water Finance and Management recently pointed readers to an American Water Works Association release on the subject, described in its coverage as a report to help utilities navigate these conversations. The Water Finance and Management item on the AWWA report on water system considerations for data center development notes that the subject "continues to occupy discussions across the water sector," which is a fair description of the pressure on records staff as well as planners. The report's direct value to a records officer is indirect. It gives the planning and engineering teams a shared vocabulary, and shared vocabulary reduces the chance that two desks release two different numbers for the same project.
Separate the Estimate From the Answer
Most disputes about data center water start with a number that was accurate for one purpose and then quoted for another. A developer's stated demand is usually a planning target, not a commitment the developer has agreed to hold. A staff load estimate may rest on assumptions about cooling design, operating hours, and seasonal peaks that have not yet been reviewed. An adopted service condition is a different document again. Each has a different status, and each can be superseded.
The log should therefore record the status of every figure it touches. Useful labels are draft, staff estimate, under review, adopted, and transmitted. A figure marked transmitted in September may later be replaced by a revised estimate in October. Without the label, the later figure looks like a contradiction rather than an update, and the utility is left explaining a change it did not announce. The label also protects the staff. A reply that says a number was a draft estimate at the time it was sent is a defensible statement, provided the file shows it.
Keep a Single Official File
Copies travel. A memo sent to a developer reaches a council packet, a consultant's proposal cites it, and a newspaper quotes it from a public meeting recording. Each copy may be accurate for its moment and still be wrong for the next reader. The practical control is to name one holder of the official file and one backup. That holder decides which version is the record, keeps the transmittal dates, and approves any figure before it leaves the building.
There is a tradeoff. A single holder slows responses, and a backup who is never trained becomes a bottleneck when the holder is away. Utilities facing a steady stream of inquiries often find the workable compromise is a short approval list for water figures, with a standard response for questions that only ask about process. The list should be written down before the first inquiry arrives, because the pressure to answer quickly is highest when the question is most sensitive.
Write the Log Before the First Call Returns
A usable log is simple. Each entry should carry the date received, the channel, the requester's organization and role, a plain summary of what was asked, the figures in the file at that moment with their status labels, the person who approved any reply, what was sent and when, and the follow-up date if one was promised. Staff should record facts only. Comments about the requester's motives or the project's merits belong elsewhere, because a log is itself a record and may be requested.
Retention and review rules depend on state law and on the utility's own records schedule, so the staff should confirm those obligations with the utility's counsel before setting the policy. The log is most useful when it is reviewed on a fixed cadence, such as monthly, by someone who was not part of the original exchanges. That review catches promised follow-ups that slipped, figures that were superseded without a label, and inquiries that were answered on different desks with different numbers.
The point of the log is not to slow the utility's answers. It is to make each answer traceable to a status, a date, and an approver. A utility that can show that trail is in a much stronger position when the next request arrives, whether it comes from a developer, a council member, or a reader who has never attended a meeting.