{"slug": "evidence-without-taking-control", "title": "Evidence Without Taking Control", "summary": "Unmute1AI (U1ai) has proposed an evidence and authority layer for New York municipal water and wastewater teams that separates intelligence from operational control, so AI can collect, correlate and document evidence without holding authority to change operational technology. The proposal responds to New York Department of Environmental Conservation wastewater cybersecurity requirements for SPDES permittees and publicly owned treatment works, including 24-hour oral and 30-day written incident reporting, emergency planning, and monitoring obligations for plants with a design flow of 10 million gallons per day or greater. First annual certifications are due March 28, 2027, signed by a responsible municipal official.", "body_md": "A proposed evidence and authority layer for New York municipal water and wastewater teams\n\nMatthew Sacks / Unmute1AI (U1ai) · October 7, 2026\n\nNew York’s wastewater infrastructure has a problem that is becoming increasingly difficult to solve with conventional monitoring alone.\n\nThe 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.\n\nThat distinction becomes especially important as cybersecurity requirements increasingly demand documented incident response, asset inventories, network structures, monitoring, reporting, and responsible-official certification.\n\nThe proposed U1ai approach begins with a deliberately restrictive principle:\n\nIntelligence is not authority. Compliance status is not permission to change operational technology.\n\nThe objective is not to build an AI system that takes over a treatment plant.\n\nIt is to build an evidence layer around consequential decisions while keeping operational authority with the people and systems legally responsible for the plant.\n\n⸻\n\nThe regulatory opening\n\nNew York’s Department of Environmental Conservation has adopted wastewater cybersecurity requirements affecting SPDES permittees and publicly owned treatment works.\n\nUnder 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.\n\nThe first annual certifications are due March 28, 2027, signed by a responsible municipal official.\n\nThe 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.\n\nThat last distinction matters.\n\nThis 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.\n\nApplicability must be determined plant by plant.\n\nThe problem U1ai is designed to address\n\nA conventional monitoring system might produce:\n\nAlert → Operator sees alert → Operator investigates → Operator responds\n\nAn AI-enhanced system could potentially make that:\n\nDetection → Model assessment → Recommended response → Automated action\n\nThat second architecture creates a dangerous ambiguity.\n\nA model can be highly confident and still have no authority to alter an operational state.\n\nLikewise, a system can determine that a facility appears to be out of compliance without possessing permission to remediate the underlying operational technology.\n\nU1ai therefore proposes a different chain:\n\nIndicator → Asset → Assessment → Authorized Action → Verification → Reporting Record\n\nThe architecture is designed around the separation between knowing and acting.\n\nThe system can collect evidence.\n\nIt can correlate evidence.\n\nIt can identify a potential incident.\n\nIt can recommend a response.\n\nIt can document what happened.\n\nBut the authority to make a consequential operational change remains explicitly governed.\n\nA municipal evidence layer\n\nThe proposed U1ai architecture connects several existing concepts into a controlled evidence and authority workflow.\n\nAnnealMesh + PhaseFlow\n\nThese components provide the proposed intelligence and state-mapping layer.\n\nThe system can map:\n\nAssets\n\nOwners\n\nEvidence sources\n\nDependencies\n\nIncident states\n\nRecovery states\n\nRelevant decisions\n\nRather than treating an alert as an isolated event, the architecture attempts to establish the surrounding context.\n\nWhat asset generated the signal?\n\nWhat evidence supports the assessment?\n\nWho is responsible for the asset?\n\nWhat state is the incident currently in?\n\nWhat action has actually been authorized?\n\nThat creates a much stronger operational record than simply storing an alert.\n\nLEDGER: preserving the decision chain\n\nThe proposed LEDGER layer is the evidence spine.\n\nFor each consequential decision, the system would preserve the relationship between:\n\nSource → Evidence → Assessment → Approval → Action → Verification\n\nThe resulting receipt could support incident documentation and certification review.\n\nImportantly, the receipt is not itself a regulatory filing.\n\nIt is evidence supporting the people who are responsible for making and submitting those filings.\n\nThat distinction should remain hard-coded into the architecture.\n\nSentinel: intelligence does not become authority\n\nSentinel provides the most important boundary.\n\nA threat model can recommend:\n\n“This asset appears compromised.”\n\nIt cannot therefore conclude:\n\n“I am authorized to shut it down.”\n\nThose are fundamentally different statements.\n\nThe proposed Sentinel architecture evaluates a proposed action against explicit authority.\n\nIf the required authority does not exist, the action is blocked.\n\nIf required evidence is missing, the workflow can fail closed.\n\nIf the system cannot establish that an action is permitted, the absence of permission is treated as a boundary, not an invitation to guess.\n\nThis is particularly important in operational technology, where an apparently helpful automated intervention can itself become an operational incident.\n\nLocal resilience matters\n\nMunicipal infrastructure cannot assume that every critical workflow will have perfect connectivity.\n\nA cybersecurity event, network outage, damaged communications path, or isolated plant can create precisely the conditions under which operators still need useful information.\n\nThe proposed U1ai architecture therefore emphasizes local processing and degraded-mode operation where practical.\n\nIgnis + OmniSign\n\nThese components are proposed to support locally approved:\n\nContainment workflows\n\nVerification\n\nRestoration procedures\n\nOperator communications\n\nAccessible status information\n\nOffline or degraded-connectivity workflows\n\nThe objective isn’t merely cybersecurity.\n\nIt is operational continuity.\n\nA system that becomes unusable the moment connectivity disappears has a rather unfortunate definition of resilience.\n\nAccessibility belongs inside the infrastructure\n\nAccessibility should not be bolted onto the system after the cybersecurity architecture is finished.\n\nOperators need information in forms they can actually use under pressure.\n\nOmniSign’s proposed role is therefore broader than simply translating communication.\n\nThe architecture could support accessible operator interfaces across visual, textual, speech, and sign-based communication channels, depending on the deployment and validated capabilities.\n\nThat matters particularly during degraded conditions.\n\nWhen communications become noisy, complicated, or fragmented, the system should reduce ambiguity rather than create another interface operators have to fight.\n\nAccessibility is part of operational resilience.\n\nThe first pilot should be intentionally boring\n\nThe 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.\n\nThe proposed first pilot is deliberately constrained:\n\nOne small municipal POTW\n\nOne tabletop cybersecurity incident\n\nRead-only inputs\n\nNo autonomous OT control\n\nHuman review of every consequential decision\n\nThe objective would be to produce a traceable evidence packet and draft reporting record for official review.\n\nThe pilot would specifically test:\n\nAuthority gates\n\nMissing-evidence handling\n\nEvidence provenance\n\nDecision traceability\n\nAccessible communications\n\nOffline/degraded workflows\n\nVerification procedures\n\nReporting-record generation\n\nAnd perhaps most importantly:\n\nWhat failed?\n\nA credible infrastructure pilot should actively search for failure modes.\n\nIf the system cannot establish authority, it should demonstrate that failure.\n\nIf evidence is incomplete, it should demonstrate that failure.\n\nIf communications disappear, it should demonstrate that failure.\n\nIf the model produces a bad recommendation, the architecture should demonstrate that the recommendation cannot silently become an unauthorized operational action.\n\nThe architecture in one view\n\n                    FIELD / UTILITY SIGNALS\n\n                             │\n\n                             ▼\n\n                    ┌─────────────────┐\n\n                    │     EVIDENCE    │\n\n                    │ Sensors / Logs  │\n\n                    │ Asset Records   │\n\n                    │ Network State   │\n\n                    └────────┬────────┘\n\n                             │\n\n                             ▼\n\n                    ┌─────────────────┐\n\n                    │ AnnealMesh /    │\n\n                    │ PhaseFlow       │\n\n                    │                 │\n\n                    │ Asset + State   │\n\n                    │ Mapping         │\n\n                    └────────┬────────┘\n\n                             │\n\n                             ▼\n\n                    ┌─────────────────┐\n\n                    │   ASSESSMENT    │\n\n                    │ AI / Analytics  │\n\n                    │ Evidence        │\n\n                    │ Correlation     │\n\n                    └────────┬────────┘\n\n                             │\n\n                    Recommendation\n\n                             │\n\n                             ▼\n\n                    ┌─────────────────┐\n\n                    │    SENTINEL     │\n\n                    │ Authority Gate  │\n\n                    │                 │\n\n                    │ \"Is this action │\n\n                    │ actually        │\n\n                    │ authorized?\"    │\n\n                    └───────┬─────────┘\n\n                            │\n\n                 ┌──────────┴──────────┐\n\n                 │                     │\n\n             NOT AUTHORIZED         AUTHORIZED\n\n                 │                     │\n\n                 ▼                     ▼\n\n              BLOCK               HUMAN / APPROVED\n\n                                      ACTION\n\n                                         │\n\n                                         ▼\n\n                                ┌─────────────────┐\n\n                                │   VERIFICATION  │\n\n                                │                 │\n\n                                │ Did reality    │\n\n                                │ match intent?  │\n\n                                └────────┬────────┘\n\n                                         │\n\n                                         ▼\n\n                                ┌─────────────────┐\n\n                                │     LEDGER      │\n\n                                │ Evidence Receipt│\n\n                                │ Decision Record │\n\n                                └────────┬────────┘\n\n                                         │\n\n                                         ▼\n\n                                  OFFICIAL REVIEW\n\nFigure 1. Proposed U1ai evidence-and-authority architecture. Conceptual illustration only.\n\nWhat this is not\n\nThe proposal is intentionally bounded.\n\nIt is not:\n\nA deployed municipal system\n\nA replacement for SCADA\n\nA replacement for cybersecurity controls\n\nA replacement for operators\n\nA regulatory compliance guarantee\n\nAn automatic incident-reporting authority\n\nAn autonomous OT control system\n\nEvidence that a utility is currently protected\n\nAnd it should not be marketed as any of those things.\n\nThe architecture remains a proposal until it is tested in an appropriate environment with utility operators, cybersecurity personnel, engineering teams, and the relevant authorities.\n\nWhy the distinction matters\n\nThere is a growing temptation to treat AI confidence as a substitute for institutional authority.\n\nThat is backwards.\n\nA model can say 99.9% confidence.\n\nThat number does not grant permission.\n\nA compliance engine can say noncompliant.\n\nThat status does not grant permission.\n\nA threat detector can say critical incident.\n\nThat classification does not grant permission.\n\nThe proposed U1ai model treats those outputs as evidence and intelligence.\n\nAuthority remains a separate layer.\n\nThat creates a simple rule:\n\nIntelligence recommends. Authority decides. Evidence records what happened. Verification checks reality.\n\nFor municipal infrastructure, that separation may be more valuable than another system promising to automate everything.\n\nA practical starting point for New York\n\nThe immediate opportunity is not to promise an AI-controlled future.\n\nIt is to build a small, testable bridge between the information utilities already possess and the evidence responsible officials need to make defensible decisions.\n\nStart read-only.\n\nStart small.\n\nTest the boundaries.\n\nDocument failure.\n\nKeep authority explicit.\n\nThen determine whether the architecture has earned the right to move any further.\n\nThat is a much more credible path toward AI in critical infrastructure.\n\nAnd it fits the central principle of U1ai:\n\nEvidence without taking control.\n\nBoundary & source note\n\nThis 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.\n\nThe 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.", "url": "https://wpnews.pro/news/evidence-without-taking-control", "canonical_source": "https://dev.to/matthew_sacks_cfcdb8d71f2/evidence-without-taking-control-4m7k", "published_at": "2026-10-07 20:59:03+00:00", "updated_at": "2026-10-07 21:17:18.893631+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy", "ai-agents"], "entities": ["Unmute1AI", "U1ai", "New York Department of Environmental Conservation", "Matthew Sacks", "AnnealMesh", "PhaseFlow"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/evidence-without-taking-control", "markdown": "https://wpnews.pro/news/evidence-without-taking-control.md", "text": "https://wpnews.pro/news/evidence-without-taking-control.txt", "jsonld": "https://wpnews.pro/news/evidence-without-taking-control.jsonld"}}