The Trace Is the Baseline

The network needs a memory of itself

A fiber network is a physical system long before it is a service, a dashboard, or a ticket. Glass leaves a hut, passes through trays and closures, bends around real things in the ground or on poles, crosses connectors and splitters, and eventually reaches a customer, cabinet, cell site, or handoff. Software sees that world through identifiers: routes, jobs, spans, fibers, ports, tasks, ECOs. The field sees it through light.

That means the most important artifact after construction or repair is not always the status update. It is the remembered measurement. What did this link look like when we accepted it? How much insertion loss did the end-to-end path have? Where did the OTDR see splices, connectors, splitters, bends, and the far end? Which wavelength was used? From which end? With what launch cable? Under which pass/fail thresholds?

If those answers are only trapped in a PDF package, a file name, or a technician’s local instrument export, the network forgets itself. The next emergency callout starts from a worse place than it should: a NOC knows service is impaired, a contractor knows roughly where the route goes, and everyone starts rebuilding the baseline under pressure.

This cairn is about treating fiber test evidence as product data. It is not a tutorial on how to operate an OTDR. The Fiber Optic Association, TIA, EXFO, VIAVI, and field technicians have better material for that. The product question is narrower and closer to Osprey Strike: what should software remember so construction closeout, emergency repair, customer assurance, and future troubleshooting all work from the same physical baseline?

Acceptance is different from visibility

There are two nearby ideas that software teams tend to blur: acceptance and visibility. Acceptance asks whether the installed cable plant meets the designed requirement. Visibility asks where the link’s physical features and problems are. They overlap, but they are not interchangeable.

Public TIA guidance summarizes optical fiber field testing in tiers. Tier 1 includes insertion-loss testing with an optical loss test set and verification of length and polarity. Tier 2 adds an OTDR trace. In plainer language: Tier 1 is the end-to-end performance check, and Tier 2 is the location-aware picture of the path.

The distinction matters because an OTDR is not simply a better power meter. FOA is blunt on this point: OTDRs work indirectly from backscatter and reflections, while a source and power meter or OLTS measures the loss of the cable plant in a way that correlates directly with the transmitter-to-receiver path. The OTDR can show where things happen; the OLTS-style test is the acceptance-grade loss check for many standards-driven installations.

The exact contract language matters. OSP, enterprise, PON, long-haul, data center, and customer-specific scopes can ask for different test sets, wavelengths, directions, and reports. The product pattern is not “always require every test.” It is “make the required evidence explicit for this scope.”

For an operational product, that split creates a useful model:

If software stores only “pass” or “complete,” it throws away the difference between these questions. If it stores only a trace attachment, it may preserve visibility without proving acceptance. The better object is a test-evidence record that can hold both.

OTDR traces are maps with caveats

The attractive thing about an OTDR trace is that it feels like a map. A pulse goes down the fiber, backscatter and reflections return, and the instrument draws a distance-based picture. Events appear where connectors, splices, bends, splitters, or breaks change what comes back. For a long route with many splice points, that picture is invaluable.

But a trace is a measurement under conditions, not an objective photograph. Pulse width trades resolution for reach. Averaging reduces noise but takes longer. Longer wavelengths can reveal stress that shorter wavelengths miss. Launch and receive cables make the near-end and far-end connectors measurable; without them, dead zones hide things we care about. Backscatter differences between fibers can make a splice appear as a “gainer” in one direction and a loser in the other, which is why bidirectional testing and averaging matter for trustworthy splice-loss interpretation.

That is exactly where product design matters. A closeout package can say “OTDR attached” and still be operationally thin. A useful system asks enough questions to make the attachment comparable later:

graph TD
  A[Test Evidence Record] --> B[Scope]
  A --> C[Measurement Context]
  A --> D[Results]
  A --> E[Artifacts]
  B --> B1[Route Segment]
  B --> B2[Fiber or Strand]
  B --> B3[Direction]
  C --> C1[Wavelength]
  C --> C2[Instrument]
  C --> C3[Launch and Receive Setup]
  C --> C4[Test Settings]
  D --> D1[Loss]
  D --> D2[Length]
  D --> D3[Event Table]
  D --> D4[Pass or Fail]
  E --> E1[Trace File]
  E --> E2[Report PDF]
  E --> E3[Technician Notes]

The exact fields can evolve, and early versions can be humble. The important decision is to stop treating test output as an opaque blob. The trace file, report PDF, and technician notes are attachments to a record; they are not the record itself.

Baselines turn emergency work into comparison

Emergency repair is expensive because uncertainty is expensive. In When the Fiber Goes Dark, the core problem is coordination: the NOC sees alarms, the OSP contractor needs to roll a crew, and status moves across organizational boundaries under time pressure. Test baselines reduce a different kind of friction: physical uncertainty.

If the accepted baseline says a route had expected events at known distances, normal cumulative loss, and no unexplained reflection between two closures, then today’s test has something to argue with. The technician is not merely asking “what do I see?” They are asking “what changed?” A new reflective event may point to a damaged connector. A shifted far end may indicate a break. A higher loss at a known splice location may turn a broad patrol into a targeted inspection. A bend-sensitive wavelength difference may suggest stress rather than a clean cut.

This is not magic diagnosis. It is disciplined comparison. EXFO’s PON testing guidance makes the same practical point for construction and troubleshooting: an initial trace can act as a template, and later out-of-band troubleshooting traces can be compared against it to locate anomalies and event-loss changes. FOA says the same thing more generally: installation traces become the reference that makes later analysis easier.

The product lesson is simple: every accepted link should leave behind evidence that future incident response can retrieve by route, fiber, customer, service, span, closure, or ECO. If the baseline exists but cannot be found in the moment, the network may as well have forgotten it.

The artifact should be structured

A PDF is a presentation format, not a product model. It is useful because humans can open it, review it, sign it, and attach it to a closeout package. It is insufficient because software cannot reliably answer operational questions from a folder of PDFs: which strands failed? which tests are missing? which traces correspond to this span? which baseline should today’s ECO compare against? did the technician test both directions? did the result exceed the designed attenuation budget?

The minimum useful artifact is a structured record with attachments. It does not need to parse every OTDR vendor format on day one. It needs to preserve the facts that shape workflow.

Vendor trace formats are a real integration topic. The architecture does not have to start there. A manually entered event table plus original attachments is already more operationally useful than an unclassified upload.

This is a familiar pattern from Boundary Objects for Operational Software. A boundary object carries enough meaning across groups that each group can do its work without pretending they share the same whole worldview. Fiber test evidence is exactly that kind of object. The field technician sees a measurement procedure. The OSP project manager sees closeout quality. The NOC sees a future troubleshooting reference. The customer sees assurance. The software needs to preserve enough structure that all of those meanings survive.

Closeout is a product workflow

Closeout is where physical truth and workflow truth meet. A crew can be done splicing before the evidence is reviewed. A trace can be attached before it is accepted. A link can pass at one wavelength and still need a required second wavelength. A repair can restore service while leaving documentation incomplete. Each of those states means something operationally different.

That is why “complete” is too blunt for test-driven closeout. The Last False Complete argued that field workflows need a soft-complete state before they earn the right to be done. Test evidence gives that idea teeth. A task might be field-complete, evidence-submitted, evidence-rejected, retest-required, accepted, or baseline-updated. The final state is earned by satisfying the evidence rules for the work type.

stateDiagram-v2
  [*] --> WorkInProgress
  WorkInProgress --> FieldComplete
  FieldComplete --> EvidenceSubmitted
  EvidenceSubmitted --> EvidenceAccepted
  EvidenceSubmitted --> EvidenceRejected
  EvidenceRejected --> RetestRequired
  RetestRequired --> EvidenceSubmitted
  EvidenceAccepted --> BaselineUpdated
  BaselineUpdated --> Closed

This state model also makes partial truth visible. If a cable repair restored service but the OTDR trace is missing, the NOC should know the service state and the evidence state separately. If the insertion-loss test passes but the OTDR event table shows an unexpected high-loss splice, the workflow should not collapse that into a cheerful green check. If a contractor uploads a report for the wrong strand, the issue is not merely a bad attachment; it is a failed identity match.

For OSP operations, these distinctions matter because closeout artifacts become the next team’s starting point. The person reviewing customer acceptance, the person investigating a repeat outage, and the person deciding whether a contractor must roll back out are all downstream readers of the same evidence.

What this means for Osprey-shaped systems

Osprey Strike already has the bones of an evidence-aware operational system. The existing model cares about ECO lifecycle, tenant boundaries, event streams, projections, dispatch status, Render integration, and the gap between field work and NOC visibility. Physical test evidence is a natural next object, not a separate document-management side quest.

The key is to attach evidence to the right operational entities:

1. ECO evidence - traces, loss tests, photos, and notes gathered during emergency investigation and repair.
2. Route or segment baseline - accepted tests for a physical span, closure pair, splitter leg, or handoff path.
3. Fiber or service evidence - strand-level or customer-facing proof where the unit of assurance is narrower than the route.
4. Closeout package evidence - grouped artifacts for project acceptance, contractor review, and customer handoff.

That shape lets the same artifact do multiple jobs. An ECO trace can prove what changed during an incident. Once accepted, it may update the baseline. A construction closeout trace can become the future comparison target. A rejected report can remain in the audit trail without pretending it is valid evidence.

This does not require exposing sensitive customer data in a broad knowledge base. The product record can reference service context with tenant-aware permissions while the cairn-level pattern stays generic.

The architecture should also separate evidence ingestion from evidence interpretation. Ingestion answers: did we receive a record, does it match the work, is it reviewable, and where are the artifacts? Interpretation answers: what does the trace mean, did the event table change, and does it pass the rule set? Teams often delay the first because the second is hard. That is backwards. A structured evidence ledger makes later automation possible; an opaque folder of reports makes later automation expensive.

Discussion Prompts

• For ECO closeout, what is the smallest test-evidence record that would prevent a false complete: attachment only, direction/wavelength metadata, event table, pass/fail thresholds, or all of the above?
• Where should a baseline live in an Osprey-shaped product: on route segments, fibers/strands, customer services, ECOs, or a separate evidence ledger linked to all of them?
• Which comparison would be most valuable first: "today's trace vs accepted baseline," "submitted evidence vs required closeout checklist," or "contractor report vs designed loss budget"?

What the team should take away

1. Acceptance and visibility are different. Loss testing proves the link meets a budget; OTDR traces show where physical events and faults live. Useful products preserve both meanings.
2. Baselines are operational memory. A construction or repair trace becomes valuable again when a future ECO can compare against it.
3. Attachments are not enough. PDFs and trace files need structured identity, measurement context, results, provenance, and review state around them.
4. Closeout should be stateful. Field-complete, evidence-submitted, evidence-accepted, retest-required, baseline-updated, and closed are different claims.
5. The first system does not need to understand every trace. It needs to make the evidence findable, comparable, reviewable, and connected to the operational workflow.

References

1. FOA Reference: OTDRs - Practical grounding for what OTDRs measure, where traces help, why launch/receive cables matter, and why bidirectional comparison is important.
2. TIA FOTC summary of TSB-140 - Public summary of optical fiber field-testing tiers, documentation, and loss-budget acceptance concepts.
3. VIAVI: Tier 2 Fiber Optic Certification - Vendor explanation of Tier 2 testing as deeper root-cause and location visibility beyond basic pass/fail certification.
4. EXFO: OTDR Testing Services - Overview of OTDR testing as a field workflow for fixed, cable, contractor, and network-lifecycle contexts.
5. EXFO: OTDR PON Testing Application Note - Useful source for construction-time traces, out-of-band testing, and comparing troubleshooting traces against initial templates.
6. FOA Reference: Outside Plant Fiber Optic Installation - Installation-oriented context for OSP documentation, testing, and closeout expectations.