Optical Incident Journey
Every action waits for change approval, and the next team is chosen from what the last one found.
What it does
A degraded optical service arrives with an alarm signature. The Reasoning Core recommends which team to engage; each action is gated by a change/dispatch approval; after each investigation the core evaluates the incident and either stops (root cause found) or reasons about the best next team and requests the next approval. The path is decided by the LLM, not hardcoded.
How it works
A degraded optical service arrives with an alarm signature; the Reasoning Core decides which team to engage first, one action at a time, with each costly or service-impacting step gated by a change/dispatch approval. After every investigation the core evaluates whether the root cause is found and — if not — reasons about the best next team (top-down: logical → optical → physical) and requests approval for that action. It stops when root cause and remediation are established. The escalation path is decided by the LLM, not hardcoded.
How it's wired
One poll watcher intakes waiting incidents and raises the first change gate. Each approval's intent engages the recommended team, updates the incident timeline, and — if not resolved — recommends and requests the next action (self-chaining through the decision queue).
The team
Tier-1 NOC — correlate alarms, check element/port state and software/config, rule out logical causes; decide whether the fault is logical, optical, or physical.
DWDM / optical-layer specialist — OSNR, pre-FEC BER trend, amplifier gain/tilt, chromatic dispersion / PMD, per-wavelength power; determines whether it is an optical-layer degradation or points to the fibre plant.
Physical layer / field — run an OTDR trace or dispatch to LOCATE a fibre fault (break, macrobend, dirty connector, splice loss) the alarms and optical analysis cannot pinpoint.
Connects to
What it watches
Polls the fault queue for waiting incidents; each approval self-chains to the next recommended action.
Human approval
One consequential step waits for a person's approval before it acts.
What it already knows (2)
Data it carries
1 table
What it shows a human
Ask it
“New incident: OTU4 λ21 Amsterdam ↔ Frankfurt — pre-FEC BER rising 3.1e-3, span loss +3.2 dB, intermittent LOS-P.”
“New incident: 100G λ12 London ↔ Paris — OSNR degraded 2.4 dB, Q-factor falling, no LOS, no protection switch.”
“New incident: OTU4 λ07 Madrid ↔ Barcelona — repeated protection switches, high pre-FEC BER on the working path only.”
“New incident: 400G λ03 Frankfurt ↔ Vienna — gradual OSNR decline across the band, amplifier output power low.”
“New incident: 100G λ18 Milan ↔ Rome — sudden LOS, no optical power received, traffic on the protection path.”
“New incident: OTU4 λ25 Stockholm ↔ Oslo — elevated CD/PMD, sporadic FEC uncorrectable blocks, line-card temperature alarm.”
Before it runs, you'll
- 1Confirm the Optical Fault Intake server at import — it is credential-free, and the answer repoints it if you have your own.
- 2Provision the three teams — NOC Analyst, Optical Engineer, Field Engineer (pure reasoning).
- 3Enable the observation, then approve (or deny) each change gate as it appears and watch the incident timeline fill action by action.
Import into StudioX
- Download the
.sxmfile. - In StudioX → Missions → Import, drop the file.
- Review, finalize, and it's live — chat to it or enable the observation.
Reviews
5.0 (1)Strong use case for dynamic incident orchestration. Having each investigation inform which team gets engaged next, rather than following a fixed escalation tree, feels particularly useful for optical faults where the root cause can cross logical, optical, and physical layers.
8/16/2026