Manage-o-MATIC — MoM, for short — is what we’re researching to help the small business owner keep on top of his own network. When something breaks, he’s stuck with one of two options: a managed provider who sees the problem and decides what’s worth telling him, or no provider and no idea what’s wrong. Either way, he’s not in the room — someone else knows more about his network than he does.
MoM is our attempt to change that: the same plain-language read on the network, for him and his provider, built from the same evidence. No provider on hand? That reporting layer is what he’s got instead. This is a research brief, not a product promise — the goal is a network that’s easy to manage, self-healing, and self-reporting, so he can handle routine maintenance and compliance paperwork himself, without a translator. This post is a field update on how close we actually are.
What MoM makes of it, live →
The specific device, named
Beyond blinking lights
A green icon is not an answer. We are trying to connect the meaning behind the numbers: what changed, what it affects, what is still unknown, and what a responsible next step could be.
MoM doesn’t stop at the alert. It reads the wireless controller’s actual configuration and turns it into plain English — including what it can’t yet prove.
Current Wi-Fi generation
MDR-AP and FYR-AP (NWA130BE). These access points are Wi-Fi 7 hardware with 2.4, 5, and 6 GHz capability.
Crimson Crisp
WPA3_PSK on 5 GHz and 6 GHz.
quit_touching_me
WPA2_PSK on 2.4 GHz.
Not set up right now
The controller reports no enabled SSID marked as a guest network. Active networks use a captive portal; that’s separate from guest-network isolation.
No review waiting
Nebula reports no managed-device firmware items needing attention.
What this does not prove
The current source shows current controller settings. It cannot yet prove guest isolation, channel quality, roaming, or per-device firmware versions from this feed.
The equipment behind the numbers
The lab, right now
We are testing this with an OPNsense firewall, Red Hat Linux systems, and deliberately accessible Zyxel Nebula cloud-managed equipment. The firewall and Red Hat Linux systems provide the Internet-edge, server, monitoring, and evidence layers; Nebula provides cloud-managed Wi-Fi, managed-device, and client evidence. The point is to prove useful operations with equipment that does not require an enterprise-only budget.
The visibility gap, named plainly
One reporting system
Each environment already has ways to speak. We are building a practical reporting layer around six purpose-built collectors — one apiece for the firewall, the Linux servers, backups, cloud-managed Wi-Fi, and the network’s overall health — each one talking to its own environment over a supported path: key-controlled SSH, a REST API, or another vendor-provided management interface. The aim is to normalize what they see into o-MATIC Server, where it can be processed and reported in one plain-language view.
Compliance belongs in that same conversation. We are researching reporting built around the frameworks that matter to the business, rather than forcing every business into a generic checklist. The report should preserve its source, confidence, and coverage gaps—not hide how an answer was reached.
“MoM catches it, we approve it, the system carries it out.”
Working now
What works today
This list is live in our lab today — not a roadmap.
- Live controller-reported Wi-Fi, managed-device, and client evidence.
- OPNsense firewall, Red Hat Linux server, and Internet-edge health evidence from supported collection paths.
- Current network and maintenance reporting, with limits left visible.
- On-demand posture and compliance evidence reports—not a certification.
- Named, approval-backed maintenance work orders for supported actions.
What’s next
What we are trying next
The approve-and-execute pattern already works one layer down. MoM flagged those 19 pending updates on Stallion, the operator approved the work order, and our maintenance worker applied them off that approval — no reboot even needed. That’s the real, already-true version of the story we eventually want to tell about the firewall: MoM catches it, we approve it, the system carries it out. We are not there yet with the firewall. Our monitoring account can see the firewall today but is deliberately blocked from writing to it — a security boundary, not an oversight — so it cannot yet even tell us whether a firewall update is waiting. Closing that visibility gap comes first, before any approval workflow can exist on top of it.
- Extending the proven approve-and-execute pattern to the firewall, once it can report its own update state.
- Proactive reporting that explains why a signal matters, not just that it exists.
- Safe, bounded repair candidates that can be reviewed before anything changes.
- Mac and Windows as the next operating-system lanes.
- Other management platforms that expose useful APIs, with each integration earning its own evidence, security boundary, and supported-action contract.
- Easier-to-manage and self-healing behavior only where evidence, safety, and authority genuinely support it.
Not there yet
What is not there yet
We do not yet prove root cause from incomplete telemetry, map every wired port or unmanaged endpoint, verify every backup restore, or repair a network without a supported action and the right approval. Those are open research and engineering problems. We will publish what works, what does not, and what still needs to be earned.
Curious how the pieces fit together?
See what o-MATIC Server does →