Mirav Vigil · How it works

Built like network
software, not like a
chatbot.

Vigil is a deterministic diagnostic engine wrapped in an agentic loop: perceive the fault, collect evidence under hard safety constraints, correlate it, decide, and keep watching until the fault clears. Here is exactly how each part works.

Architecture

One VM. Your jump host.
Nothing else changes.

Vigil sits beside your existing operations stack and reaches devices on exactly the path your engineers already use.

Sources

ITSM fault queueNetwork fault tickets, polled read-only
Optical NMSSpan alarms, A/Z optical state
Circuit inventory & topologyCircuit records, backbone link map
↓

Mirav Vigil — one VM inside your network

OrchestratorPoll loop · dedup · storm suppression · worker pool · recheck
Read-only guardFail-closed allow-list · per-device rate limiting
CollectorAlarm-type command sets · window-scoped log retrieval
ParsersCLI text → typed port · optical · LAG · service · BGP · log objects
Diagnostic analysersPer-alarm-type root-cause logic · scoring · gap detection
Evidence storeSystem of record + raw output audit trail
↓ read-only SSH · SNMP · ping ↓

Your existing access path

Jump hostYour credentials, your ACLs, your audit
IP/MPLS routersCore · aggregation · access
↑

Output

Triage report portalVerdict · confidence · evidence · dispatch · feedback widget
No inbound path is created. Vigil originates every connection outbound to the jump host. Nothing in your network needs to reach Vigil, and Vigil needs no credentials your NOC does not already have.
The loop

Perceive · act safely ·
decide · verify.

The agentic part is the loop, not the guesswork. What happens inside each step is ordinary, inspectable engineering.

StageWhat actually happens
PerceiveThe fault queue is polled continuously. Alarm subjects are parsed into a structured fault — host, port, LAG, service id, BGP peer, circuit — and matched against open work so duplicates and alarm storms collapse into one investigation instead of fifty.
Act safelyA command set is selected for the alarm type and every command is checked against the read-only allow-list before it leaves the process. Vigil connects through your jump host, paces itself per device, and retrieves event logs scoped to the alarm window — falling back to rotated log files when the in-memory buffer has already wrapped.
CorrelateRaw CLI is parsed into typed objects, then cross-checked against optical NMS state, circuit inventory and backbone topology. Contradictions between what the OSS believes and what the device reports are raised as explicit findings rather than silently resolved.
DecideA per-alarm-type analyser produces a root cause, a confidence grade, a per-layer OK/WARN/CRIT breakdown with the source command for each line, the evidence that was missing, and the queue the ticket should be dispatched to.
VerifyOpen faults are re-probed on exponential backoff. Vigil records the outage window (down → up), promotes repeat offenders to chronic-flap, and flags when a fault has demonstrably cleared and the ticket is safe for a human to close.
Diagnostic depth

What "root cause"
actually means here.

One worked example. The same rigour applies to each of the nine alarm families.

A LinkDown on a 100G backbone LAG

  • Read the LAG — admin vs operational state, and how many members are actually up.
  • Read optical power on every member, not just the one in the alarm. RX and TX separately.
  • Apply the discriminator. RX dark with TX healthy on all members means the span lost light — a fibre cut or DWDM fault, not a local transceiver. One dark member out of four means a near-end SFP or patch.
  • Resolve the far end from topology, not from the interface description — descriptions go stale and mislabel the peer.
  • Read the event log around the alarm timestamp to establish the actual down and up times, and whether this is one event or the twentieth flap this week.
  • Cross-check the optical NMS. If the transport layer reports no alarm on the A/Z ends, that contradiction goes into the report as a finding.
  • State the verdict with its evidence — and grade the confidence by how many independent sources agreed.
Vigil report close-up showing the optical power table with a member port at −40.00 dBm marked DARK, the event log timeline, and the resulting verdict with confidence grade.
The same logic, rendered: the reading, the timeline, then the verdict — in that order.
Why this matters commercially. "LAG down" sends a field engineer. "All members optically dark with TX present" sends the right field engineer, to the right span, with the right spare — or tells you it's the transport provider's problem, not yours.
Safety model

Four constraints, all of them
enforced in code.

  • Fail-closed command allow-list. Commands are prefix-matched against an explicit read-only list before reaching the SSH transport. The default outcome for anything unrecognised is refusal, not permission.
  • No write path to the ticket system. The integration is read-only at the client layer. Vigil records recovery and closure-readiness in its own state; writing to your ITSM remains a human action.
  • Rate limiting per device. Vigil will not hammer a CPU-constrained router, and a storm of alarms on one node does not become a storm of sessions.
  • Everything retained. Commands issued, raw responses, the verdict, and any engineer correction — all stored and queryable for audit.

Typical read-only surface

Vigil's collectors use around 70 distinct read-only commands, selected by alarm type. Nothing that changes state is in the vocabulary:

show port … opticalshow lag … detail show service id … baseshow service id … sap show router bgp summaryshow system alarms show log log-id 99show chassis snmpwalk sysNameping

No configure. No admin. No clear. No shutdown. Not permitted, not reachable.

Evidence model

Why the report is
the product.

A verdict nobody can check is worth nothing at 2 a.m. Vigil's output is structured so an engineer can agree or disagree in seconds.

🎯

Verdict + confidence

One root cause, graded HIGH / MEDIUM / LOW by how much independent evidence agreed. Vigil says "insufficient evidence" when that is the truth.

🩺

Per-layer breakdown

Each diagnostic layer — reachability, physical, optical, LAG, service, BGP, hardware — reports OK / WARN / CRIT / NO DATA, with the command that produced it.

🕳️

Named evidence gaps

Missing evidence is a first-class finding, not an omission — including who or what would need to change for the gap to close next time.

⏱️

Outage window

Actual down and up timestamps derived from device event logs, anchored to the alarm — plus how many times this link has flapped in the window.

🚚

Dispatch recommendation

Each root-cause category maps to a queue — transport, routing, hardware, field engineering — so the escalation is pre-routed.

🔁

Engineer feedback

Accept, needs-improvement or reject, with a structured reason. Corrections are retained and drive tuning of thresholds and evidence sets.

What we need from you

The whole ask.

ItemDetail
ComputeOne small Linux VM inside your network — 2 vCPU / 4 GB is comfortable for a national backbone's L1 volume. No GPU.
Device accessA read-only account reachable through your existing jump host. No new firewall rules inbound to the network.
Fault queueRead access to the network fault queue in your ITSM. Write access is deliberately not requested.
Enrichment (optional)Read APIs for optical NMS, circuit inventory and backbone topology. Vigil works without them; it works considerably better with them.
PeopleAbout an hour a week of an L1 engineer marking verdicts right or wrong during the tuning period.
Next

See what it writes
into a real ticket.

A complete triage report, section by section, with the reasoning annotated.

See a real triage report → Book a walkthrough