Fiber Splice Documentation Software: Why Every Fault Still Starts With Opening a Can

Why splice records decay faster than any other network data

A splice record is created once, in the worst possible conditions, by the person least able to file it. A splicer is in a bucket or a vault, in weather, with a fusion machine, a tray full of 144 fibres in colour coded buffer tubes, and a paper cut sheet that was printed before the design changed. The assignment gets marked on that sheet. The optical time domain reflectometer traces get saved to the test set, then copied to a laptop at the end of the day, then emailed as a zip file with a name like north_route_final2.

Two years later a customer circuit goes down. Somebody needs to know which strand at which closure carries that circuit and what the splice looked like when it was accepted. The cut sheet is in a filing cabinet or a photo on a phone that has since been replaced. The traces are in an email nobody can find, or in a folder on a laptop belonging to a contractor you no longer use. So a crew rolls, and they open the can, and they trace it by hand at overtime rates in the middle of the night. That is the actual cost of bad splice documentation, and it recurs for the entire life of the plant.

The reason this decays so much faster than other network data is that nothing else in the network is created at the exact moment when documentation is hardest. Conduit and structures get surveyed. Equipment gets provisioned through a system that will not let you skip fields. Splices get recorded by a tired person with cold hands, and every downstream system assumes somebody typed it in later. Somebody usually did not.

The fault call that proves the point

An enterprise customer on a lit service reports total loss at 2am. The network operations centre shoots an OTDR from the terminal and sees an event at roughly 4.6 kilometres. Roughly, because the launch fibre length was not recorded and the refractive index setting on the test set may not match what was used at acceptance.

Now the questions start. What is at 4.6 kilometres, a closure or a slack loop. If it is a closure, which strand is that circuit on inside it, and which buffer tube. Was that strand spliced by your crew or the contractor who did the 2021 extension. What was the acceptance loss on that splice, so you know whether it has degraded or was always marginal. Was anyone working in that vault this week.

With good records that call is a ten minute triage and a targeted dispatch. Without them it is a crew opening closures in sequence until they find it, which is how a two hour outage becomes an eight hour one, and how a service level credit gets issued that costs more than the software would have.

What VETRO FiberMap, 3-GIS, EXFO and Viavi actually fail at

These are the tools operators already own, and each is good at its own half of the problem. VETRO FiberMap and 3-GIS are network records platforms. They hold the design, the route, the structures and the strand assignments, and they do that job well. EXFO and Viavi make the test equipment and ship reporting software that turns traces into acceptance documents.

The gap is between them, and it is not a small one. Network records platforms hold the intended assignment, which is the design. What the splicer actually did in the closure at 4pm on a Friday when the design was wrong is a different fact, and it reaches the records platform only if somebody manually reconciles it. In practice that reconciliation happens in batches, months late, from paper, by a person who was not there. The records then look authoritative and are quietly wrong, which is worse than having none, because crews trust them.

Test equipment software has the opposite limitation. It is excellent at the trace and the report. It is not a system of record for your network, so a trace lives as a file rather than as an attribute of a specific splice on a specific strand at a specific closure. Nothing automatically compares today's trace against the acceptance trace on the same fibre, which is the single most useful diagnostic you could have and almost nobody has it.

Neither category handles the contractor boundary. When splicing is subcontracted, the acceptance package arrives as a folder of files and a spreadsheet, in whatever naming convention the contractor uses, often with traces shot in one direction only when your specification required bidirectional. Checking that package is a manual task nobody has time for, so it gets accepted, and the defects surface as faults later.

What a custom splice documentation build has to include

The central object is the splice, not the closure and not the file. A splice record joins an incoming cable, buffer tube and fibre position to an outgoing one, inside a specific tray in a specific closure, performed by a named splicer on a date, with a measured loss and the traces that measured it. Get that atom right and everything else is a query.

Field capture has to be faster than the paper it replaces or splicers will not use it, and if splicers do not use it the project has failed regardless of how good the back end is. That means working offline in a vault with no signal, presenting the cut sheet as the primary screen rather than a form, defaulting sequential assignments so a full tray is a few taps, and letting the splicer record a deviation from design in one action because deviations are the whole point. A photo of the open tray attaches automatically, which is what you will want when somebody disputes the work in three years.

Trace ingestion should be automatic and it should be strict. Traces come off the test set in the standard Telcordia format, and the system should parse them, read the event table, extract the splice events, and match them to the splice records by distance and by fibre identity. Then it applies your acceptance thresholds. Those thresholds are yours, not universal: one operator accepts a bidirectional average that another rejects outright, and both are defensible. A splice that fails your threshold is flagged before the crew leaves the site, which is the entire economic argument for doing this, because a return trip costs many times what the correction would have cost while the closure was open.

Contractor acceptance becomes a workflow rather than a folder. The contractor uploads or captures directly, the system checks completeness against the design, checks direction and settings on each trace, checks thresholds, and produces an exception list. You accept the package or you reject it with specifics, and the acceptance record is permanent. Payment can hang off that, which changes contractor behaviour faster than any conversation.

Reconciliation with your network records platform is the last piece and it should be continuous. As built assignments push into VETRO FiberMap or 3-GIS as they are confirmed, not as a quarterly cleanup. Where the as built differs from the design, the difference is explicit and someone owns closing it. This is also the point at which the historical trace archive becomes a fault tool: given a circuit, show the acceptance trace for every splice in its path, so the technician on a 2am call knows what normal looked like.

What it costs and how long it takes

In Digital Heroes delivery experience, a first release runs $55,000 to $120,000 and ships in 10 to 14 weeks. That covers offline splice capture on a phone or tablet, automatic trace parsing with threshold checking, and strand level search across closures. Splicers use it on live work immediately, which is the only useful test.

A full platform at $140,000 to $300,000 phased over 5 to 10 months adds contractor acceptance workflow with exception handling, bidirectional reconciliation with your network records platform, historical trace comparison for fault support, and reporting for programs that require an evidence package.

What raises the cost here specifically: the number of test set vendors and models in your fleet, because while the trace format is standardised the metadata written into it is not consistent across manufacturers. Ribbon splicing, if you do it, because mass fusion changes the capture model from strand by strand to ribbon by ribbon. Deep integration with a network records platform, which depends heavily on how open that platform's interface is. And the state of your existing records, because migrating decades of paper is a data project with its own budget and you should decide deliberately how far back you go.

What holds it down: capture forward only. Start recording new splices properly from day one and backfill selectively where a route matters. Operators who insist on digitising every historical cut sheet before going live usually never go live.

When buying is the right answer

If you run one in house crew, splice a few hundred fibres a year, and your network records platform already holds assignments your technicians trust, do not build. Tighten the process, standardise where traces are stored, and put the money into a second test set.

Build when several crews or contractors are splicing concurrently, when contractor acceptance packages are being approved without anyone really checking them, when fault triage regularly involves opening closures to find out what is inside, or when you are handing over a build to an owner who will audit the evidence. Those are the conditions where the manual process is not slow, it is unreliable, and unreliable records cost money every time the network breaks.

How to choose a developer for splice documentation software

Ask them to explain how they will match an event in a trace to a splice record. The right answer involves distance with a tolerance window, refractive index and launch fibre handling, fibre identity from the test metadata where present, and a human review queue for the ones that do not match cleanly. If they say they will just parse the file, they have not looked at a real trace from a real crew.

Ask what happens when the design is wrong and the splicer has to deviate. This is the most common event in the field and the hardest thing to model. A build that treats deviation as an error state will be abandoned by crews inside a month.

Ask which network records platforms they have written into, specifically. Reading from a system is easy. Writing as built assignments back into it, without corrupting the design of record, is the part that takes real work and real cooperation from the vendor.

Ask who owns the code and put it in the contract before kickoff. You should hold the repository, the infrastructure accounts and the right to bring in another firm at any point. At Digital Heroes the client owns the code from the first commit, and we would tell you to treat any hesitation on that question as an answer in itself.