I Spent Years Doing Fiber Deployment Analysis by Hand. I Built a Tool That Does It in Minutes.

Every long-haul fiber build produces a mountain of test files. OTDR traces at multiple wavelengths, both directions, dozens or hundreds of spans. OLTS tables. Fiber inspection reports. Every crew names their files a little differently. Every OTDR brand exports a little differently. Every project manager wants the same information in a slightly different format.

Somebody has to sort through all of it. Standardize the naming. Fix the identifiers. Check what passes and what doesn't. Catch the errors before they turn into wasted truck rolls. Write it up in plain language a network owner will sign off on.

That's the job of a fiber analyst.

What the job actually looks like

If you've done acceptance or deployment analysis on any real build, you know what I'm about to describe. If you're new to it, this is what the manual version of the work looks like.

You get a folder. Or 20 folders. Or a shared drive nobody has bothered to organize. Inside are files named things like Trace 001.sor, SITE_A_TO_B_1310.trc, field_measurement_final_v3(2).sor, and IMG_20240815_143022.jpg. Some are duplicates. Some are wrong wavelength. Some are from the wrong span entirely. A few have vendor-specific quirks that don't open cleanly in another vendor's software.

Your job is to turn that into a package the network owner will sign off on. Clean naming. Standard identifiers. Consistent structure. A report that reads like a professional wrote it and not a script.

The manual version of this workflow takes hours per project. Multiply by every project a contractor does in a year, and you understand why good deployment work often looks sloppy in the paperwork.

What the tool does

Drop a job's test files onto /analysis. Files, folders, or a .zip of the whole job. Duplicates and messy names are fine. The tool starts analyzing on drop. You can add more files later and they join the same job.

You get back three things:

One repair verdict per fiber. Every fiber in the job gets a card showing pass or fail, the wavelengths tested, span length, total loss, worst reflectance, and any high-loss events. If the tool catches a mismatch between the filename and the file's internal ID, it flags it and offers to update the identifier.

An actionable repair summary. One line per fiber, plain language, ready to copy or export as CSV. Something like:

ALPH-BRVO-L-S F077 — Traces reviewed: 162.149 km span, 32.54 dB total loss, worst reflectance -31.81 dB. High-loss events: 19.513 dB splitter at 19621.020 km, 14.649 dB connector at 16444.819 km, 14.649 dB connector at 24049.409 km. Review recommended.

An AI review of the whole job. Overall assessment, patterns across fibers, dispatch priorities, and things worth a second look. Generated by an AI prompted to write the way a deployment analyst does.

Everything exports to PDF. Everything runs entirely in your browser. Files never leave your device.

Show, don't tell

Here's a real example from a job I ran through the tool. 24 fibers, 48 files, mostly clean. F077 on the ALPH-BRVO route came back with three high-loss events at strange distances: a 19.5 dB splitter at 19,621 km and two 14.65 dB connectors at 16,444 km and 24,049 km.

Anybody reading the raw trace summary would flag those as major faults. But look at the distances. The fiber is 162 km long. You cannot have events at 19,000 or 24,000 km on a 162 km fiber. It's physically impossible.

Here's what the AI review said about it:

The two 14.65 dB connector events on F077 at 16444.82 km and 24049.41 km from ALPH appear to be data anomalies. Distances in the tens of thousands of kilometers are physically impossible on a 162.15 km span. These values likely reflect a unit or parsing error in the source file and must not be used for field dispatch as written.

The 19.51 dB splitter event on F077 at 19621.02 km from ALPH is similarly impossible on a 162.15 km span and is almost certainly a unit conversion error, likely meters reported as kilometers (19621 meters = 19.62 km from ALPH). That distance would place the event near a common enclosure location on the route.

That's the kind of catch that saves a truck roll. Without it, someone dispatches a crew to a location that doesn't exist, or worse, they hand a network owner a report with impossible distances in it and lose credibility on the whole job.

The dispatch priority the tool produced from that:

ALPH-BRVO route, F077 event near 19.62 km from BRVO (probable unit error on the splitter location): Inspect the enclosure closest to 19.62 km from BRVO. A 19.51 dB loss is a catastrophic splitter or connector event. Clean and re-test first. If the event is confirmed, the splitter or mechanical splice at that location needs replacement. Resolving this is the highest-value action on the job.

That's the language an experienced analyst uses when they hand a job off to a field crew. Specific location. Specific action. Specific expected outcome. That's the layer of interpretation that turns raw data into useful field work.

What else the tool caught on that same job

Same job, same run. A few other things the AI review flagged that I would have missed on a fast read:

• The filenames all said ALPH-BRVO, but every trace's internal file ID said BRVO-ALPH. Someone shot from the wrong end and named them backwards. The tool flagged this and warned that all F077 and F078 event distances need to be reversed before field dispatch.
• F077 measured 162 km, and F078, F079, F080 all measured 91 km. All four are labeled the same route. That's a 78% length difference on fibers that should be identical. Something is either mislabeled or on a different physical path.
• Three fibers on a completely different route (CHRL-DLTA) got dumped into the same job folder. The tool noticed they didn't fit the pattern and flagged them separately.
• One reference-list check flagged that no expected-fiber list was uploaded, so it couldn't confirm whether any fibers were missing entirely.

Any one of those catches saves an hour of analyst time. All of them together are what separates a professional acceptance report from a sloppy one.

Privacy

The tool runs entirely in your browser. Files never leave your device. No upload, no server-side processing of the trace data. The AI review is the only step that sends anything (the parsed summary, not the raw trace files) to a language model to generate the narrative. If you're working with sensitive customer data, that architecture matters.

Currently in beta

The tool is live and functional today, but I'm calling it beta for two reasons.

First, I'm still collecting variety. The more file types the tool sees, the better it handles vendor quirks. If you have unusual OTDR formats or vendor exports the tool doesn't recognize cleanly, I want them.

Second, I'm collecting feedback on the reports. Every organization's context is a little different. Some want more detail. Some want less. Some have specific report templates the tool should conform to. The tool gets better with real use.

Beta users get free access while I gather feedback. In exchange, I ask that you tell me what worked and what didn't.

Who this is for

Field technicians who want a faster way to organize trace files and produce a clean deliverable at project close.

Project managers at fiber contractors who spend hours per week reviewing crew work and packaging it for the network owner.

Deployment analysts who do the work I used to do, and want to spend less time on the mechanical parts so they can focus on the fibers that actually need attention.

QA teams at network owners who receive acceptance packages from contractors and want to see them arrive in a consistent, standardized format.

Try it

The tool is at /analysis. Drop your files, run a job, see what you get back. If the output is close to what you need, keep using it. If it needs work, tell me what's wrong and I'll fix it.

I built this because I did the manual version of it for years and I wanted to give that time back to the people still doing it. That's the whole point.

Related: the single-file trace analyzer, the link loss budget calculator, and the CD/PMD testing overview.