1. Introduction

An inline amplifier hut on a long-haul corridor takes a 2 dB hit because a connector backed off during a maintenance window, and the question that matters at 03:00 is not "is the link down" — it is not down — but "which of the eighty wavelengths riding that fiber are now within a decibel of their forward-error-correction threshold, and what happens to each of them if the protection switch fires and dumps them all onto the alternate route." A network operations engineer cannot answer that by measurement without disturbing live traffic, and cannot answer it from a planning tool that still believes the network looks the way it did at turn-up three years ago. The thing that can answer it is a model of the network that has been kept current against the network's own telemetry, and that can be asked a hypothetical question and return a per-lightpath quality-of-transmission estimate. That is the optical network digital twin, and the hypothetical question is the what-if.

The term "digital twin" has been diluted by a decade of marketing across manufacturing, smart cities, and industrial IoT, to the point where it now sometimes means nothing more than a dashboard. In optical transport the term has a sharper, testable meaning, because the physical layer of an optical network is governed by analytical equations — amplified spontaneous emission accumulates a known way, nonlinear interference scales with launch power a known way, and the receiver's bit error rate maps to a generalized signal-to-noise ratio through a transponder's measured back-to-back curve. A twin that gets these wrong is falsifiable within a decibel, and a what-if answer that is wrong by a decibel is the difference between a service that closes and one that does not. This is why the optical twin is one of the few places where the digital-twin concept survives contact with engineering scrutiny.

This article is about the what-if specifically — not the visualization layer, not the inventory database, but the predictive query and the machinery that makes its answer trustworthy. The structure follows the dependency chain: what the twin is, what it is built from, the physics that lets a query be answered at all, the calibration that keeps the model honest, and then four classes of what-if query that operators actually run in production and research today — provisioning, restoration, soft-failure localization, and margin recovery. The standards that are converging on this — at the IETF, ITU-T, OIF, and the IOWN Global Forum — close the article, along with an honest accounting of where the models still break.

2. What a Twin Is, and Is Not

The distinction that does the most work is between a simulator and a twin, and it is not a difference of sophistication — a simulator can be more physically detailed than a twin. The difference is the starting state and the direction of data flow. A simulator starts from a clean design: a topology you draw, fiber parameters you type, amplifier noise figures from a datasheet. It answers questions about a network that may not exist yet, or that exists only as the designer imagined it. A twin starts from the network as it is right now, ingesting live OSNR readings, per-channel power, pre-FEC bit error rate, and amplifier gain profiles, and it reconciles its internal model against those measurements continuously. The defining property is that the model is never more than seconds to minutes behind the physical network's actual state — including the accumulated aging, splice degradation, filter narrowing, and environmental drift that no datasheet captures. This distinction between a simulator and a digital twin is the one operators most often get wrong when evaluating products.