NVEE
An automation platform that ingests network telemetry, attempts bounded remediation, verifies the result, and escalates to a human only when the closed loop fails.
Overview
NVEE is an early-stage attempt at a network automation platform that doesn’t just monitor infrastructure, but resolves what it safely can before a human is contacted for remediation. The version documented here is a prototype — a real front end wired to a deliberately fake backend, built to pressure-test the reasoning model before committing to real integrations.
The problem
Enterprise networks generate constant, low-grade evidence that something is about to go wrong — a link flapping, a device restarting more than it should, a pattern an experienced network engineer would recognize on sight. That recognition rarely gets written down anywhere a system can use it; it lives in whoever’s been staring at that dashboard the longest, and it evaporates the moment they’re not the one on call.
Most monitoring tools are built to surface data, not judgment. They’ll show you the flapping link. They won’t tell you that this particular flapping pattern, on this particular device, has meant “replace it” three times before.
The idea
The hypothesis: separate the parts of network triage that are genuinely mechanical (power-cycle a device, check whether it recovers) from the parts that require judgment (should this device be replaced, escalated, or left alone), and let the system act autonomously on the first while keeping the second fully visible and reviewable. A smart PDU makes the mechanical half literally possible — an automation loop that can’t act on the world isn’t automation, it’s a fancy alert.
How it thinks
Closed-loop remediation — how historical telemetry becomes a model that can reason about, act on, and verify live incidents.
Historical telemetry is normalized and used to train the model. When a live incident occurs, NVEE applies that learned context to reason about the problem, recommend and execute a bounded remediation, then verify the result. Successful remediation closes the loop; failure returns the incident to a human.
In practice
Event remediation workflow — an incident moving from detection through automated triage.
The workflow shown here is the one the real system is meant to run: incidents tiered by severity, automation attempted first, and a clear trail of what was tried and what happened next.
From notebook to product
Hand-drawn notebook sketch of the event ingestion and then auto-remediation concept
Lessons learned
The device health scoring turned out to be more contentious than the automation logic. Two devices with identical failure counts can mean very different things depending on what kind of device they are and where they sit in the network — a flaky access point in a break room is not the same problem as a flaky core switch. Getting that context into a single score without hiding it took longer than building the automation rules themselves.
What’s next
The unresolved question is what happens at the boundary the MVP deliberately avoids: legacy deployments, non-standard designs, the messy real-world networks that don’t look like the greenfield case this was scoped for. We’re still exploring how much of the reasoning model survives contact with an existing network that wasn’t built with any of this in mind.
Product definition, MVP scoping, prototype UX — Andy Markowitz