One Advice Gap: Two Tools, Two Very Different Results

You’re a water and wastewater utility in the US.

You have the August 2025 Water-ISAC Cybersecurity Fundamentals for Water and Wastewater Utilities in hand.

Pair it with the January 2024 Federal Roles and Resources for Cyber Incident Response, Water and Wastewater Systems Sector (CISA/FBI and EPA) guide and the November 2023 FEMA Planning Considerations for Cyber Incidents framework and you have a solid foundation for building a plan for responding to incident with ICS.

What you don’t have yet is the plan itself.

This is the Advice Gap: the distance between receiving good guidance and turning it into a best practice your organization will actually adopt, sign, and operationalize.

Across critical infrastructure, it’s a real thing. And in the WWS sector specifically, it’s the widest because of how resource-constrained they are.

Good guidance exists, backed by real, independent sector initiative and community engagement. Getting from that guidance to an adopted plan is the part that needs help.

This post tests whether AI tooling can close the Advice Gap.

The Water-ISAC Fundamentals guide rightly focuses Fundamental 1 on addressing “the inability to promptly and efficiently contain, mitigate, and communicate about cybersecurity incidents, emergencies, or disasters [which] could result in significant operational disruption.” That’s the right problem statement. The question is how a utility turns it into an adopted plan.

I approached this from a “what’s available to me” perspective, giving both tools the same instruction:

Develop an ICS-Specific Incident Response Plan for Aliquippa Municipal Water Authority using the attachments as source.

Both tools received the same source material. The gap between the two outputs had less to do with the underlying language model and more to do with what surrounded it: the context, the structure, the guardrails, and the workflow.

The rest of this post walks through why that matters, organized around three things that adoption requires and that guidance alone can’t provide.

The Aliquippa Municipal Water Authority is not a customer or affiliated with Cabreza. To the incredible people at AMWA, nothing performed or represented here is intended to be a validated representation of your org, technology or otherwise. Information used during this exercise was acquired through public data retrieval only.

With Cabreza, the tool automatically ran an OSINT tool and pre-populated a digital twin of AMWA before I touched anything. The content generation workflow’s template builder preselected the Plan type, each of the sections, and pulled in NIST 800-82r3 and CSF context from the OSINT build. It also pulled in IEC 62443, which I removed after noticing only 3 total mentions of 62443 in the Water-ISAC 12 Fundamentals guide. I selected AWWA G430 and G440 as alignment standards, Ultronics OEM from Technologies, and configured tone, length, and from/to role settings before running the generation.

With Claude, I opened a new chat, loaded the same three guides, but hit a max image count error. So I kept the Water-ISAC and FEMA guides and gave it the same prompt.

The most important takeaway from this comparison:

I could have given Claude more context. But I didn’t have more context when using Cabreza. Cabreza had it and offered it.

With a frontier model, the quality of the output depends entirely on the quality of what the user provides. The user has to know what frameworks to reference, what alignment standards apply, what structure the plan should follow, and how to articulate all of that in a prompt.

Cabreza brought role, technology and sector-specific context, pre-built standard, regulatory and framework alignment, and structured the workflow to the generation.

The gap between the two outputs was less about the underlying language model and more about what surrounded the model: the context, the structure, the guardrails, and the workflow.

With a frontier model, the user is the context.

With Cabreza, the tool already knows information about the organization before the user begins.

The OSINT build pre-populates a digital twin with organizational and technology attributes that directly inform the plan. Behind that, Cabreza continuously updates a backend library of sector-specific context, free from vendor bias, covering standards, regulations, frameworks, controls, technology domains, and audience considerations. The user doesn’t need to assemble this context manually.

If the user doesn’t know whether to reference IEC 62443, the output may or may not include it. Whether the output references the right standards should depend on the tool’s knowledge of the sector, not on the user’s ability to name them in a prompt.

For a Facility Manager who is the CISO for an hour a week, it’s unreasonable to expect otherwise.

An ICS-Specific Incident Response Plan needs to be traceable to authoritative sources, leave room for organizational input, and map to the standards, regulations, and frameworks the organization is committed to. I’ve seen more shelfware deliverables than I’d like to admit, and the one thing they all have in common is that they weren’t written to be followed.

Cabreza’s output uses the seeded organizational and technology attributes to directly reference the utility’s real-world history and operational context. It includes a full RACI matrix (structurally unappealing in PDF, but exactly what an adopted IR plan requires) and it attributes content directly to independent, reputable, authoritative sources, with no third-party vendor plugs or web-scraped sponsored content.

Generated content in Cabreza becomes new, authored, timestamped context within your instance.

Whoa, wait a second. Is that the beginning of a program?

Generations are sectional. Pre-save editing, section selection, and sharing are all sectional. You don’t have to prompt full versions over and over. You choose your tone, your from/to roles, and your length, because they directly affect the output (which affects whether it gets adopted or not).

Content gets fully filterable tags, can be shared between instance members and viewers, and can be assigned statuses: Draft, In Review, or Approved. You can copy content out by section or all at once, gather feedback, edit, and save back through the same pane.

One more dimension that matters for adoption in critical infrastructure: if a utility can’t trust the tool with its operational data, the plan never gets built.

Cabreza is not a wrapper around a frontier model. LLM usage is limited, railed, boundaried, and instance-specific. There’s an in-app redaction studio (also available as a community standalone) for analyzing and scrubbing source material before loading it. Water utilities that can’t risk having operational context trained into a public model need these protections before any content generation begins.

The reasonable pushback is: couldn’t you have given Claude more context for a comparable result?

Possibly. But why should I?

Why should I put effort, time and cognitive load into gathering context to feed to a chatbot when there’s a smarter, more programmatic alternative solution?

With Cabreza I can upload any context point, whether it’s an advisory, inventory, existing plan/procedure/policy, new staffing plan, EAP from the state, doesn’t matter. That then becomes my user and organizational overarching context, not just a file for a chatbot.

The underlying language model in both cases is capable of producing a solid plan if given the right inputs. The question is who provides those inputs.

Most water and wastewater utilities can’t afford to outsource the work of turning guidance into best practice to consultants.

And regardless of the person or their role, no one should be expected to become a prompt engineer who can coax a frontier model into producing a plan that maps to NIST 800-82r3, aligns with AWWA G430 and G440, and accounts for the specific operational realities of their facility.

Critical infrastructure’s industrial assets, environments, and challenges are fundamentally different from IT. The networks, consequences, people, and their responsibilities are different. A tool that requires the user to bridge all of those differences in a prompt isn’t solving the problem.

The point of this comparison isn’t that Claude can’t produce a better output with better prompting. The point is that the prompting itself requires the expertise that most utilities don’t have.

Closing the Advice Gap means the tool meets the operator where they are, not the other way around.

Using LLMs for process, governance, communication, and planning within critical infrastructure sectors is actually one of the better use cases for AI when it comes to protecting industrial systems and processes.

The outputs are documents and plans, not inline code running on controllers or sitting passively on a network. That’s what makes this a reliable application of the technology.

But a frontier model with no context, no guardrails, and no workflow is not the same as a purpose-built tool that meets operators where they are.

The Advice Gap in water and wastewater is real, and it’s the widest of any critical infrastructure sector. Most utilities receive the same advisories, the same fundamentals guides, the same CISA and FEMA resources. The utilities with a path from receiving guidance to producing, adopting, and maintaining best practices their organizations will actually follow are the ones with the greatest impact.

A frontier model can help you draft. A purpose-built tool can help you adopt. That’s what Cabreza was built for.