Operating model

You state intent. Evo executes it as an approved change.

The device is asked whether it took. If it did not, you know quickly — and you can reverse it. This is the operating model, in the language an engineer already has: subnets, DHCP scopes, DNS, IPAM, inventory, ports, VLANs, drift, blast radius, approved change.

01

One place to work

You sign in to EvoConsole — the only customer way in. From there you see the site: devices, ports, prefixes, DHCP, DNS, IPAM, and what is in sync versus what has drifted. Telemetry and provisioning are different jobs; health is not mixed into the page where you are about to change a subnet. Evo is present as a colleague in that same console — ask it to investigate, to propose, and, when policy allows, to act.
02

An approved change, every time

Nothing of consequence is a fire-and-forget CLI paste. A change moves through a fixed sequence, and partial failure is not left half-done — compensating actions run in reverse order.

  1. 01

    Validate

  2. 02

    Snapshot

  3. 03

    Apply

  4. 04

    Verify

  5. 05

    Record

Refusals are expensive — a colleague who often says “I can’t” gets worked around. A refusal has to be a real limit, stated once, with the nearest thing Evo can do offered alongside it. A trunk that reports as an access port is not guessed into an access-VLAN change. The product declines, and tells you why.

03

The device is the source of truth

Vendor documentation is a hypothesis. The switch is the measurement. Discovery reads the live box, and candidates for a change are built from that read — not from a template that assumed the last engineer left things tidy. If someone changed a switch outside EvoEther, the next discovery shows drift; EvoEther does not silently overwrite it. Where docs and the device disagree, the device wins — that is how Evo avoids the one failure mode it can still have: trusting something that was never true.
04

DHCP, DNS, and IPAM move together

A prefix is not three tickets in three tools. When a site takes a subnet, the intent is one approved change: the prefix is owned, DHCP can serve it, DNS can name it. Runtime services commit first; the inventory of record follows. Correct runtime with stale docs is recoverable — the other way around is an incident.

in syncdriftnot provisioned— networking states, not confidence scores.
05

Switches: Cisco and Juniper, for real

Ports, VLANs, trunks, descriptions, admin up/down, and device rename go through the same approved-change path, not a vendor’s separate GUI. Today that is Cisco IOS-XE and Juniper Junos, over the standard management protocol those platforms already speak. Both are tested on real hardware. A third vendor is honest work, not a checkbox. Evo-managed switches are Evo-managed: the next change happens here, so the ledger and the rollback stay attached to the port.
06

Evo, unprompted

A colleague does not wait to be asked. Evo watches health, syslog, and drift. When something is worth an engineer’s attention, it says so — rarely enough to matter. An observation nobody acts on trains people to ignore observations, so saying something obliges saying it well. When you ask Evo to look, it cites what it used and can propose the change. You still approve.
07

The appliance stays sealed

Evo holds the privilege on its own host because Evo is staff. You do not. Updates arrive as a signed package; unsigned or tampered packages are refused. You never need a shell to change the management address or to pull a compliance report — those are console work. Root on the appliance is a CoNetworked event, not a customer workflow.
08

If the WAN dies

The box in the rack keeps serving DHCP and DNS. Intent that could not be delivered waits. Cloud-assisted does not mean cloud-dependent for the forwarding plane. Dark edition never needed the WAN in the first place.
What this is not

Not Ansible with a nicer theme

Playbooks do not read the port back and freeze a rollback as a first-class act.

Not a single-OEM controller

Not a vendor controller you use for one OEM and abandon for the next.

Not an LLM that invents a VLAN

Inference without a device read is how midnight changes become outages.

Walk the pipeline with us

We demonstrate the change pipeline on live Cisco and Juniper hardware. Availability follows the lease and the edition.

Request a briefing