How loud silence can be.

Matthew Sacks — Thu, 08 Oct 2026 23:51:09 +0000

Before U1ai, I worked on an ambulance.

Emergency medicine teaches you quickly that communication isn't a courtesy. It's triage. Every call starts with questions: Where does it hurt? What happened? Can you hear me? Every answer changes what you do next.

And sometimes there are no answers. A patient who can't speak. A patient who can't hear you. A patient whose way of communicating doesn't fit the script you've been trained to follow.

In the back of that ambulance, with the lights flashing and the minutes counting, you learn something most people never have to: silence is loud.

It fills the truck. It fills the space between a question and an answer. And the person inside that silence is still trying to tell you something.

That never left me.

It's why I started building Unmute1AI (U1ai), an accessibility-first AI platform working to break communication barriers for Deaf, hard-of-hearing, and neurodivergent people through real-time sign language translation, voice synthesis, and privacy-first, on-device AI.

But accessibility is only half the equation. Security matters just as much.

I'm also developing U1si-q, our security-focused approach to governing AI actions. The principle is simple: AI may interpret a signal, but interpretation is not authorization. An AI system should never confuse understanding what someone means with having permission to act on their behalf. Actions require explicit, accessible consent.

Because accessibility without autonomy isn't accessibility. And privacy shouldn't be the price someone pays to be understood.

I'm autistic, and I'm building with the understanding that communication doesn't look the same for everyone. People shouldn't have to mask, adapt to rigid systems, or fight to make themselves understood just to participate in the world around them.

I'm also the author of The Signal Between Silence, a novel about hearing loss, connection, and everything that goes unheard.

For me, these aren't separate projects. They're different expressions of the same belief: everyone has something to say, even when the world doesn't know how to listen.

That's why I'm building U1ai.

Not just to make technology smarter, but to make communication more human, more secure, and accessible to the people technology has too often left behind.

Evidence Without Taking Control

Matthew Sacks — Wed, 07 Oct 2026 20:59:03 +0000

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.

DEV Community: Matthew Sacks

How loud silence can be.

Evidence Without Taking Control