# Evidence Without Taking Control > Source: > Published: 2026-10-07 20:59:03+00:00 A proposed evidence and authority layer for New York municipal water and wastewater teams Matthew Sacks / Unmute1AI (U1ai) · October 7, 2026 New York’s wastewater infrastructure has a problem that is becoming increasingly difficult to solve with conventional monitoring alone. The plants, networks, sensors, controllers, operators, contractors, and emergency procedures already generate enormous amounts of information. The harder problem is determining what that information actually authorizes someone to do. That distinction becomes especially important as cybersecurity requirements increasingly demand documented incident response, asset inventories, network structures, monitoring, reporting, and responsible-official certification. The proposed U1ai approach begins with a deliberately restrictive principle: Intelligence is not authority. Compliance status is not permission to change operational technology. The objective is not to build an AI system that takes over a treatment plant. It is to build an evidence layer around consequential decisions while keeping operational authority with the people and systems legally responsible for the plant. ⸻ The regulatory opening New York’s Department of Environmental Conservation has adopted wastewater cybersecurity requirements affecting SPDES permittees and publicly owned treatment works. Under the adopted requirements, cybersecurity incidents must be reported orally within 24 hours of awareness and in writing within 30 days. POTWs must also maintain emergency planning that addresses cybersecurity incident response, access and authentication procedures, vulnerability management and asset inventory, and written network structure. The first annual certifications are due March 28, 2027, signed by a responsible municipal official. The requirements also establish monitoring and logging obligations for POTWs with a design flow of 10 million gallons per day or greater, subject to specified exceptions involving disconnected or unidirectional networks. That last distinction matters. This is not a reason to throw an AI agent at every municipal water system. It is a reason to create better evidence, accountability, and review around systems where the requirements actually apply. Applicability must be determined plant by plant. The problem U1ai is designed to address A conventional monitoring system might produce: Alert → Operator sees alert → Operator investigates → Operator responds An AI-enhanced system could potentially make that: Detection → Model assessment → Recommended response → Automated action That second architecture creates a dangerous ambiguity. A model can be highly confident and still have no authority to alter an operational state. Likewise, a system can determine that a facility appears to be out of compliance without possessing permission to remediate the underlying operational technology. U1ai therefore proposes a different chain: Indicator → Asset → Assessment → Authorized Action → Verification → Reporting Record The architecture is designed around the separation between knowing and acting. The system can collect evidence. It can correlate evidence. It can identify a potential incident. It can recommend a response. It can document what happened. But the authority to make a consequential operational change remains explicitly governed. A municipal evidence layer The proposed U1ai architecture connects several existing concepts into a controlled evidence and authority workflow. AnnealMesh + PhaseFlow These components provide the proposed intelligence and state-mapping layer. The system can map: Assets Owners Evidence sources Dependencies Incident states Recovery states Relevant decisions Rather than treating an alert as an isolated event, the architecture attempts to establish the surrounding context. What asset generated the signal? What evidence supports the assessment? Who is responsible for the asset? What state is the incident currently in? What action has actually been authorized? That creates a much stronger operational record than simply storing an alert. LEDGER: preserving the decision chain The proposed LEDGER layer is the evidence spine. For each consequential decision, the system would preserve the relationship between: Source → Evidence → Assessment → Approval → Action → Verification The resulting receipt could support incident documentation and certification review. Importantly, the receipt is not itself a regulatory filing. It is evidence supporting the people who are responsible for making and submitting those filings. That distinction should remain hard-coded into the architecture. Sentinel: intelligence does not become authority Sentinel provides the most important boundary. A threat model can recommend: “This asset appears compromised.” It cannot therefore conclude: “I am authorized to shut it down.” Those are fundamentally different statements. The proposed Sentinel architecture evaluates a proposed action against explicit authority. If the required authority does not exist, the action is blocked. If required evidence is missing, the workflow can fail closed. If the system cannot establish that an action is permitted, the absence of permission is treated as a boundary, not an invitation to guess. This is particularly important in operational technology, where an apparently helpful automated intervention can itself become an operational incident. Local resilience matters Municipal infrastructure cannot assume that every critical workflow will have perfect connectivity. A cybersecurity event, network outage, damaged communications path, or isolated plant can create precisely the conditions under which operators still need useful information. The proposed U1ai architecture therefore emphasizes local processing and degraded-mode operation where practical. Ignis + OmniSign These components are proposed to support locally approved: Containment workflows Verification Restoration procedures Operator communications Accessible status information Offline or degraded-connectivity workflows The objective isn’t merely cybersecurity. It is operational continuity. A system that becomes unusable the moment connectivity disappears has a rather unfortunate definition of resilience. Accessibility belongs inside the infrastructure Accessibility should not be bolted onto the system after the cybersecurity architecture is finished. Operators need information in forms they can actually use under pressure. OmniSign’s proposed role is therefore broader than simply translating communication. The architecture could support accessible operator interfaces across visual, textual, speech, and sign-based communication channels, depending on the deployment and validated capabilities. That matters particularly during degraded conditions. When communications become noisy, complicated, or fragmented, the system should reduce ambiguity rather than create another interface operators have to fight. Accessibility is part of operational resilience. The first pilot should be intentionally boring The safest way to test this architecture is not to connect an AI system directly to a live plant and hope humanity has learned something from previous centuries. The proposed first pilot is deliberately constrained: One small municipal POTW One tabletop cybersecurity incident Read-only inputs No autonomous OT control Human review of every consequential decision The objective would be to produce a traceable evidence packet and draft reporting record for official review. The pilot would specifically test: Authority gates Missing-evidence handling Evidence provenance Decision traceability Accessible communications Offline/degraded workflows Verification procedures Reporting-record generation And perhaps most importantly: What failed? A credible infrastructure pilot should actively search for failure modes. If the system cannot establish authority, it should demonstrate that failure. If evidence is incomplete, it should demonstrate that failure. If communications disappear, it should demonstrate that failure. If the model produces a bad recommendation, the architecture should demonstrate that the recommendation cannot silently become an unauthorized operational action. The architecture in one view                     FIELD / UTILITY SIGNALS                              │                              ▼                     ┌─────────────────┐                     │     EVIDENCE    │                     │ Sensors / Logs  │                     │ Asset Records   │                     │ Network State   │                     └────────┬────────┘                              │                              ▼                     ┌─────────────────┐                     │ AnnealMesh /    │                     │ PhaseFlow       │                     │                 │                     │ Asset + State   │                     │ Mapping         │                     └────────┬────────┘                              │                              ▼                     ┌─────────────────┐                     │   ASSESSMENT    │                     │ AI / Analytics  │                     │ Evidence        │                     │ Correlation     │                     └────────┬────────┘                              │                     Recommendation                              │                              ▼                     ┌─────────────────┐                     │    SENTINEL     │                     │ Authority Gate  │                     │                 │                     │ "Is this action │                     │ actually        │                     │ authorized?"    │                     └───────┬─────────┘                             │                  ┌──────────┴──────────┐                  │                     │              NOT AUTHORIZED         AUTHORIZED                  │                     │                  ▼                     ▼               BLOCK               HUMAN / APPROVED                                       ACTION                                          │                                          ▼                                 ┌─────────────────┐                                 │   VERIFICATION  │                                 │                 │                                 │ Did reality    │                                 │ match intent?  │                                 └────────┬────────┘                                          │                                          ▼                                 ┌─────────────────┐                                 │     LEDGER      │                                 │ Evidence Receipt│                                 │ Decision Record │                                 └────────┬────────┘                                          │                                          ▼                                   OFFICIAL REVIEW Figure 1. Proposed U1ai evidence-and-authority architecture. Conceptual illustration only. What this is not The proposal is intentionally bounded. It is not: A deployed municipal system A replacement for SCADA A replacement for cybersecurity controls A replacement for operators A regulatory compliance guarantee An automatic incident-reporting authority An autonomous OT control system Evidence that a utility is currently protected And it should not be marketed as any of those things. The architecture remains a proposal until it is tested in an appropriate environment with utility operators, cybersecurity personnel, engineering teams, and the relevant authorities. Why the distinction matters There is a growing temptation to treat AI confidence as a substitute for institutional authority. That is backwards. A model can say 99.9% confidence. That number does not grant permission. A compliance engine can say noncompliant. That status does not grant permission. A threat detector can say critical incident. That classification does not grant permission. The proposed U1ai model treats those outputs as evidence and intelligence. Authority remains a separate layer. That creates a simple rule: Intelligence recommends. Authority decides. Evidence records what happened. Verification checks reality. For municipal infrastructure, that separation may be more valuable than another system promising to automate everything. A practical starting point for New York The immediate opportunity is not to promise an AI-controlled future. It is to build a small, testable bridge between the information utilities already possess and the evidence responsible officials need to make defensible decisions. Start read-only. Start small. Test the boundaries. Document failure. Keep authority explicit. Then determine whether the architecture has earned the right to move any further. That is a much more credible path toward AI in critical infrastructure. And it fits the central principle of U1ai: Evidence without taking control. Boundary & source note This article describes a proposed U1ai architecture, not a production-validated system, agency-approved deployment, or compliance guarantee. Any implementation would require utility-specific applicability analysis, cybersecurity review, engineering validation, authorization controls, and human/operator oversight. The regulatory statements above reflect the supplied October 7, 2026 source material. The proposal does not extend those wastewater requirements automatically to drinking-water systems, which are subject to separate New York State Department of Health requirements and require their own applicability review.