Mirav Vigil — Autonomous L1 NOC for IP/MPLS Networks

The 2 a.m. problem

Most L1 work is
the same 20 minutes,
over and over.

A LinkDown fires. An engineer opens a jump-host session, SSHes to the router, reads the LAG, reads per-member optical power, reads the event log, checks the peer, cross-checks the optical NMS and the circuit inventory — then writes three lines into the ticket and escalates. Twenty minutes of keystrokes that are identical every single time.

And roughly half the time, the fault had already cleared before anyone looked.

Alarm volume doesn't scale with headcount. The queue grows; the night shift doesn't.
Evidence gets collected late. By the time an engineer logs in, the optical reading that would have proved a fibre cut has already settled.
Triage quality varies by who is on shift. The same alarm gets three different RFOs from three engineers.
Escalations arrive thin. L2 re-does the L1 collection because the ticket doesn't carry the raw output.
Noise is indistinguishable from signal until somebody spends the twenty minutes.

What Vigil does

Five steps. No human
in the loop until the decision.

Vigil runs the L1 playbook the moment the ticket appears — not when someone gets to it.

01 · INGEST

Watch the queue

Polls the ITSM fault queue, parses the alarm subject into a structured fault, and suppresses duplicates and storms.

02 · COLLECT

Read the device

Jump-host SSH to the router. Up to 70 read-only commands, chosen by alarm type, scoped to the alarm window — plus SNMP and ping from the NMS vantage.

03 · CORRELATE

Cross-check

Parses CLI into typed objects and cross-checks against optical NMS, circuit inventory and backbone topology. Flags OSS-vs-device mismatches.

04 · DECIDE

Write the verdict

Root cause, confidence grade, per-layer OK/WARN/CRIT breakdown, what evidence was missing, and the L2 queue to dispatch to.

05 · VERIFY

Watch to recovery

Re-probes on backoff, records the outage window down→up, promotes chronic flappers, and flags when a ticket is safe to close.

Mirav Vigil triage report for a LinkDown fault: link details, outage window, physical port status, optical power table showing a dark member port, interface errors, event log timeline, and the RFO verdict with confidence. — A complete Vigil triage report for a LinkDown fault — evidence first, verdict last, every line traceable to the command that produced it. (Demo data; hostnames and circuits anonymised.)

Evidence → verdict

It shows its
working.

Vigil never asserts a root cause it can't point at. Every verdict names the reading that drove it, and every reading names the command that produced it. When the evidence is thin, it says so and grades itself LOW rather than guessing.

Graded confidence — HIGH / MEDIUM / LOW on every verdict, so your team knows what to trust and what to look at.
Named evidence gaps — "per-member optical was not collected" is a finding, not a silent hole.
Raw output retained — the exact CLI responses are stored with the ticket for audit and for L2.
Feedback loop — engineers accept, correct or reject each verdict; the corrections tune the logic.

Close-up of a Vigil report: optical power table showing a member port at −40.00 dBm marked DARK, event log timeline, and the RFO section reading 'Verdict F1, Confidence MEDIUM — all measured members optically dark with TX present, so fibre cut or DWDM span fault, not a local SFP'. — Dark RX with healthy TX across every member → fibre/DWDM span fault, not a local SFP. Stated with the numbers that prove it.

Why network teams say yes

Read-only is not a policy.
It is enforced in code.

The fastest way to lose a production network is an agent that can type. Vigil cannot.

🔒

Fail-closed allow-list

Every command is prefix-matched against an explicit read-only allow-list before it reaches the transport. Anything not on the list is refused — including anything a model might invent.

🚪

No new way in

Vigil reaches devices the way your engineers do: through your existing jump host, with your existing credentials and ACLs. No new inbound path to the network.

✍️

It never closes your tickets

Vigil marks a fault recovered in its own state and recommends closure. Writing to the ticket system stays a human decision — by design, and blocked at the integration layer.

🏠

Runs inside your network

A single small VM in your own environment. Device evidence and ticket data never leave your perimeter.

🧾

Full audit trail

Every command issued, every byte returned, every verdict and every engineer correction is stored and queryable.

👤

Humans stay in charge

Vigil produces a recommendation. Dispatch, remediation and closure remain your team's call — with better information in front of them.

Coverage today

Nine alarm types,
each with its own diagnostic logic.

These nine account for the overwhelming majority of L1 fault volume on an IP/MPLS backbone. Each has a purpose-built analyser — not a generic prompt.

Alarm family	What Vigil decides	Share of volume
LinkDown · LAG port add-fail	Fibre/DWDM span cut vs near-end SFP or patch vs admin-down vs chronic flap — using per-member optical power on both ends.	`30%`
BGP peer state change	Normal churn vs peer-local fault vs an underlay link failure that removed the route to the peer.	`25%`
SNMP / node unreachable	Genuinely down vs reachable-and-false-alarm — probed from the NMS vantage, not from the agent.	`25%`
Service site down Epipe · VPLS · EVPN-VPWS	Local access-circuit fault vs transport/LSP vs a remote PE that stopped advertising the EVI.	`16%`
Hardware removal SFP · card · PSU	Confirms the removal against device and system alarms, and flags lost redundancy as a risk.	`4%`

Volume shares from 1,753 tickets ingested in the live deployment. Transport, command sets, parsers and diagnostic logic are separate layers, so the platform is vendor-pluggable by design.

What changes

The shift stops
collecting.
It starts deciding.

Vigil doesn't replace your NOC. It removes the part of the job that was never judgement in the first place — and hands your engineers a fully evidenced starting point instead of a blank ticket.

The single biggest win is the noise. In the live deployment, 47% of investigated faults had already self-recovered or were transient by the time triage ran. Vigil identifies those with the evidence to prove it — before anyone is woken up or a field engineer is dispatched.

Faster time-to-evidence. Optical readings and event logs are captured while the fault is still live, not after it settles.
Consistent RFOs. The same alarm produces the same reasoning every time, on every shift.
Escalations that arrive complete. L2 opens a ticket that already contains the raw CLI, the timeline and the reasoning.
Fewer unnecessary dispatches. Self-cleared and false-alarm faults are identified with proof, not assumed.
Institutional memory. Every fault, every verdict and every engineer correction is retained and searchable.
A record you can audit. Exactly what was run, what came back, and why the call was made.

Getting started

A pilot you can judge
on real tickets.

Read-only means the pilot is genuinely low-risk: worst case, Vigil is wrong in a report nobody acted on.

WEEK 1

Connect

One VM inside your network. Read-only credentials on your existing jump host. Read access to the fault queue.

WEEK 2

Shadow

Vigil triages live tickets in parallel with your L1 shift. Nothing is written anywhere. You compare.

WEEK 3–4

Tune

Your engineers accept or reject each verdict. Thresholds, evidence sets and dispatch routing are tuned to your network.

THEN

Adopt

The shift starts working from Vigil's report instead of a raw alarm. You decide what, if anything, it is allowed to act on.

Scope, by design: Vigil is a triage and diagnosis system. It does not push configuration and it does not close your tickets — which is precisely why network and security teams approve it in weeks rather than quarters. Everything it produces is a recommendation with the evidence attached. Remediation is a separate conversation, with its own guardrails.

Questions we always get

The honest answers.

Is this an LLM guessing at my network?

No. The diagnostic logic is deterministic code — per-alarm-type analysers with explicit thresholds, scoring and evidence rules. The same inputs always produce the same verdict, and you can read exactly why. Language models are used where language is the problem, not to decide whether your fibre is cut.

What happens when it's wrong?

Nothing breaks — because it can only write into its own report. Wrong verdicts are visible, graded by confidence, and correctable: engineers reject or amend them from the ticket view, and those corrections feed back into tuning. We would rather ship a verdict marked LOW than a confident guess.

Does our data leave our network?

No. Vigil runs on a VM inside your environment. Device output, ticket content and credentials stay within your perimeter.

Which platforms does it work with?

Vigil is layered so that the transport, the command sets, the parsers and the diagnostic logic are independent of each other — a new platform is a command-set and parser exercise against the same engine, not a rebuild. The current production deployment runs on Nokia SR OS. Tell us your mix and we'll scope it with you.

How is this different from our existing NMS or correlation engine?

Your NMS tells you a port went down. Vigil logs into that port, reads the optical power on every LAG member, reads the peer, reads the event log around the alarm, checks the circuit in inventory, and tells you whether it is a fibre cut, a dirty patch, a flap that already cleared, or a remote PE problem — and who should get it. It is the step after correlation, not a replacement for it.

What does a pilot cost us in effort?

One VM, read-only credentials on an existing jump host, read access to the fault queue, and about an hour a week of an L1 engineer's time to mark verdicts right or wrong. That's the whole ask.

The ticket is already
triaged when your
engineer opens it.

Most L1 work is
the same 20 minutes,
over and over.