Last week I rejected a closeout package for a 48-fiber backbone. Not because the attenuation readings were bad—they were actually fine. I rejected it because the as-built note said: “When was this cable ready for service ()?” with empty parentheses.
You might read that as a documentation slip. A missing date. The tech should have filled it in. But I've been reviewing test packages long enough to know the empty parentheses aren't the problem. They're a symptom.
The surface question is “When?” The deeper question is “What does ready mean?”
I'm a quality/compliance manager at a telecom testing company. I review every field test report before it reaches a customer—roughly 200 packages a year. If I remember correctly, our Q1 2024 audit found that 11% of accepted packages had no clear statement of what “ready for service” meant. That number shouldn't have been possible.
Ready is not a timestamp
It's tempting to think a cable is ready at the exact moment the last splice is closed. But “ready for service” is a condition, not an event. The condition is: it meets the acceptance criteria defined before testing began. Those criteria change with every project. A campus backbone might accept a 0.5 dB splice loss. A long-haul link might require 0.15 dB. If you don't define the criteria first, the “ready” date is just an opinion.
I still kick myself for not making this point on my first big outside plant project. We signed off a feeder cable because the overall loss looked good. We never asked whether the acceptance threshold in the contract matched the measurement settings. Seven months later, a margin issue showed up. If I'd pushed for a documented “ready” definition then, we'd have saved weeks of arguments.
The measurement settings decide the answer
An OTDR trace is not a neutral fact. It depends on pulse width, wavelength, index of refraction, averaging time, and launch conditions. On the same cable, an OTDR EXFO FTB 400 can produce a trace that passes at 1310 nm and another that fails at 1550 nm. Which one proves readiness? The one that matches the contract. That's why “when was this cable ready for service?” can't be answered by looking at a screen.
Also, a single-direction trace can hide splice problems. It's tempting to think one OTDR pass is enough. But a splice that looks acceptable from one end can look 0.4 dB worse from the other end. Per TIA-526-14-B, installed single-mode fiber should be verified with a light source and power meter for end-to-end loss, not just an OTDR. An OTDR is the right tool for locating events and checking splice quality, but it's not the entire proof package.
What “C300” taught me
Take C300, a 12-fiber campus run we accepted last year. The completion report said “ready for service” with a date—or rather, two dates that didn't match. The trace from the OTDR EXFO FTB 400 was dated Wednesday. The signature block said Friday. When I asked which date was the actual ready date, nobody could explain the gap. The tech said the cable was “probably ready” on Wednesday. Maybe. But “probably” doesn't belong in an as-built record.
The field note “When was this cable ready for service ()?” wasn't a typo. It was a confession. The person filling out the report didn't know what evidence would answer the question, so they asked it instead. To be fair, they weren't being lazy. They were following a template that had asked the same question for years.
The cost of an unverifiable answer
When a cable fails later, the first question is: “Was it ready when we accepted it?” If your only answer is a date and a signature, you have nothing. If you have the full record—test procedure, thresholds, trace file, bidirectional data, sign-off—you can defend the decision.
A missing “ready” definition cost us a $22,000 redo in 2024. We pulled a crew back, re-tested the route, and re-negotiated the handover date. The fix wasn't more testing. It was writing down the acceptance criteria before the testing started.
In an emergency, the instinct is to shorten the process. But the thing people should be willing to pay for isn't speed—it's certainty. A dated, incomplete handover is not faster. It's just delayed risk. I've seen a $400 rush inspection turn into a $15,000 claim because the rushed report didn't match the physical plant.
The numbers said the cable passed. My gut said the report was too tidy. I went with my gut and found a bend that the event map didn't flag. It wasn't magic—the comment field mentioned “re-terminated twice” and the spec required zero splices in that segment. My gut was just the first thing to notice the contradiction.
How to answer the question honestly
First, stop asking “when was this cable ready for service ()?” and start asking “what proves it was ready?”
- Define acceptance criteria before the first test. Put them in the contract.
- Use the right tool and settings. An OTDR EXFO FTB 400 gives you high-resolution traces, but only if the module, pulse width, and range are matched to the link.
- Save source trace files, not screenshots. The metadata in the trace file is part of the evidence.
- Test bidirectionally when standards require it, and document both directions.
- Date the report when the condition is met—after all acceptance criteria are satisfied, not when the last splice was closed.
Todd Pepsi, a field engineer I worked with on an older project, put it bluntly:
“Don't ask when it was ready. Ask what would make it not ready, and show me that didn't happen.”
An applications engineer from EXFO America made the same point with a trace. They said the trace file is a starting point, not a conclusion. You have to connect the trace to the acceptance threshold, the measurement procedure, and the sign-off date. Without that chain, “ready” is just a word.
Bottom line: “ready for service” is not a clock event. It's a claim backed by evidence. If you use an OTDR EXFO FTB 400, let the trace file start the story. Add the thresholds, the settings, the bidirectional measurements, and the sign-off. Then you can answer the question with confidence.
