When a fiber cable is cut, the first question is simple: which customers and services just lost their connection? Answering it depends on knowing exactly where the cable runs, where it is joined, and which fibers carry what. For many operators, that knowledge sits in drawings: route maps, joint diagrams, and panel layouts, some of them decades old.
Drawings cannot be searched or checked by software. AI can read them and turn them into structured records, but only if it learns from drawings labeled by people who understand fiber networks. Fiber route map digitisation is the labeling work behind that. This post explains what the labels need to capture and why the work calls for network knowledge.
Operators use several kinds of drawings, and each one answers a different question.
A single labeling guide for all three would blur their differences. Each needs its own element list, its own examples, and its own reviewers.
A route map is drawn on top of a base map of streets and buildings. The telecom elements include cable segments, ducts, poles, access chambers, cabinets, and joint closures.
Network diagram annotation on these maps means labeling each element, tracing each cable from end to end, and capturing the details written beside it: cable identifier, number of fibers, and length.
Clutter is the main difficulty. The same base map may show roads, water pipes, power lines, and other utilities. Annotators must pick out only the telecom layer, and they must know the difference between a telecom duct and a similar-looking line from another service. Scale and position also matter, because a map is only useful if its elements can be placed in the real world.
A splice diagram shows a joint where cables meet. Inside it, individual fibers from one cable are connected to fibers in another, and some are left unconnected as spares.
Splice diagram labeling captures which incoming fiber joins which outgoing fiber. Fibers are identified by number and often by color code, so annotators must read both and link them correctly.
The tolerance for error is close to zero. If one connection is wrong, a path traced through the network leads to the wrong place. A model trained on imperfect splice labels will invent connections that do not exist, or miss ones that do.
At the end of a route, fibers terminate on panels in exchanges and cabinets. Panel diagrams show ports, numbered in rows and columns, and which cable and fiber each port connects to.
Numbering schemes differ between sites and equipment. Some count along rows, others down columns. Front and rear views may use different numbers. Annotators need the numbering rule for each panel type, written down with examples, because a port label read the wrong way is simply a wrong answer.
Every important element in a fiber network has an identifier: a cable, a joint, a duct, a port. These identifiers are what let a drawing be matched to inventory records and to other drawings.
For this reason, transcription has to be exact. A zero and a capital O, or a one and a capital I, can be indistinguishable in a drawing, and the wrong guess breaks the match. Guidelines should set out the identifier formats the operator uses, so annotators can check what they read against the expected pattern.
They should also say what to do when an identifier is unreadable. A flagged gap is better than a plausible-looking guess.
Drawings do not all show the same thing. Some show a design: what was planned. Others show as-built: what was actually installed, which may differ from the plan. Some show routes that were never built at all.
Each element needs a status label that says what it is. Mixing planned and as-built elements in one dataset teaches a model to trust a cable that was never laid. When a drawing does not say its status, annotators should mark it as unknown, and a specialist should decide.
Most operators also keep inventory databases of their network assets. In principle, drawings and databases agree. In practice, they often do not.
Digitisation projects can use the database as a cross-check, comparing extracted data with what is on record. Where they disagree, annotators should flag the difference and not quietly correct one to match the other. A mismatch may mean the drawing is out of date, the database is wrong, or the extraction made an error. A person with network knowledge decides which.
People who have worked in outside plant engineering, fiber planning, or network records read these drawings differently. They know how cables, joints, and panels fit together, recognize the conventions used by an operator, and understand why a single wrong connection matters. They can tell when a drawing and a database disagree for a good reason, and when they disagree because something is wrong.
They also write the rules that keep a large team consistent: element lists, identifier formats, numbering schemes, and status labels. This matches Globik's approach of using verified domain experts for work that depends on judgment. For telecom network records AI training data, that knowledge decides whether a digitised network can be trusted in an outage.
Before a fiber diagram project starts, a team can settle five things:
Digitised fiber records are only as good as the labels behind them. Exact identifiers, correct fiber-to-fiber connections, clear status labels, and honest handling of mismatches turn old drawings into a network that can be queried. If you are working on network records, you can talk to our team about your network records. Strong splice diagram labeling and route map labeling depend on people who understand fiber networks.
It is the labeling of fiber route maps and diagrams so AI can turn them into structured, searchable network records.
One wrong fiber connection leads a traced path to the wrong place, so the labels must be exact.
They link drawings to inventory records, so each one must be transcribed exactly or flagged if unreadable.
Planned routes may never have been built, and mixing them with installed ones makes the data misleading.
Annotators should flag the mismatch for a specialist, not quietly change one to match the other.
