Pathworks Engineering — Remote Engineering, FTTx and Energy
← Back to blog
OSP & FTTx··8 min read

Fiber Splice Schedule QA: Nine Checks Before Field Release

A splice schedule can look complete and still create field stoppages. This practical QA checklist covers continuity, cable identities, duplicate assignments, closures, splitters, revision control and field usability before release.

Pathworks Engineering Team

A splice schedule can be complete on paper and still fail in the field.

The problem is rarely a missing row. More often, the schedule disagrees with the route drawing, uses inconsistent cable identities, assigns fibers twice, omits pass-through fibers, or leaves the splicer to interpret how a branch should be built. Those errors create stoppages at closures, consume spare fibers, and make final testing and as-built reconciliation harder than necessary.

A good QA review treats the splice schedule as part of one controlled design package, not as a standalone spreadsheet. Before release, it should be checked against the geographic design, fiber topology, cable schedule, enclosure plan, naming standard, and construction assumptions.

This practical checklist explains the checks that matter most.

1. Confirm every cable identity before reviewing fiber assignments

Start with the cables, not the individual fibers.

Every feeder, distribution, drop, backbone, or lateral cable in the splice schedule should have one unambiguous identity. That identity should match every other issued document where the cable appears.

Check the following:

  • Cable ID and description
  • Origin and destination
  • Nominal fiber count
  • Cable type where relevant
  • Route drawing or GIS feature ID
  • Closure, cabinet, terminal, or panel connection
  • Direction of travel through the network

A schedule that calls a cable “FDR-01” while the route drawing calls it “FEEDER-A” forces the field team to decide whether the two labels refer to the same asset. That should be resolved during design.

Cable identities should also remain stable through revisions. If a route change requires a new cable segment, use the client's change-control rules instead of quietly reusing an existing identifier for a different physical asset.

2. Test continuity from the source to every downstream endpoint

Fiber continuity is the central QA check.

Follow each assigned fiber from its source through every splice point to its destination. Do not review one closure at a time without checking the complete path. A locally correct splice can still create a broken end-to-end circuit.

For each service path, confirm:

  • The source fiber exists in the upstream cable
  • The same assignment reaches the intended closure
  • Every intermediate splice is represented
  • The downstream fiber exists in the outgoing cable
  • The path reaches the correct splitter, terminal, cabinet, building, or panel
  • No segment reverses or changes identity without explanation

A simple continuity matrix can help. List the logical service path in one direction and compare it with the splice schedule closure by closure. This is particularly useful where the network branches repeatedly or where multiple cables with similar counts share the same route.

Pass-through fibers require the same care as active branches. If fibers continue through a closure without being cut, the documentation should state that clearly. If they are cut and respliced, the schedule should show the connection explicitly.

3. Check for duplicate, missing, and out-of-range assignments

A splice schedule should never allocate the same fiber to two incompatible destinations.

Run a structured check for:

  • Duplicate incoming fiber assignments
  • Duplicate outgoing fiber assignments
  • Fibers assigned outside the cable's stated count
  • Gaps that conflict with the intended allocation plan
  • Active assignments placed inside reserved ranges
  • Spare fibers shown as active elsewhere
  • Fibers marked abandoned or unavailable but reused downstream

Color coding can help reviewers scan the schedule, but it should not be the only control. The underlying fiber numbers and cable IDs must remain clear when the document is printed in grayscale or exported to another system.

Reserved and spare fibers should be intentional. Label the purpose where the client standard permits, such as growth, restoration, business service, mobile backhaul, or future splitter capacity. A generic “spare” label is sometimes adequate, but a defined reservation is easier to protect through later revisions.

4. Reconcile the schedule with the physical closure design

Logical fiber assignments must fit the physical enclosure.

For every closure, cabinet, terminal, or panel, verify:

  • The planned cable count is within the enclosure configuration
  • Entry and exit cables are identified correctly
  • Splice quantities are realistic
  • Tray allocation follows the client's standard
  • Splitters, connectors, pigtails, and pass-through fibers are represented
  • Slack and access assumptions are practical
  • The closure identifier matches the route drawing

A schedule may be logically correct but physically awkward. For example, an assignment can force related fibers across several trays when the client's practice is to keep a cable or service group together. The result may still work optically, but it increases installation time and makes later fault isolation harder.

Reviewers should also distinguish fusion splices from connectorized interfaces. A port assignment at an ODF, FDT, FAT, splitter module, or equipment panel should not be documented as though it were simply another closure splice.

5. Align splitter, port, and customer-facing assignments

In PON networks, the splice schedule often connects the outside plant to a splitter or terminal allocation. That relationship must agree with the logical design.

Check:

  • Splitter identifier and ratio
  • Input fiber assignment
  • Output port range
  • Distribution cable and fiber assignment
  • Terminal or service-area relationship
  • Spare splitter ports
  • Reserved or unavailable ports
  • Any cascade between primary and secondary splitters

The schedule should make it possible to trace a splitter input back toward the headend and a splitter output forward toward the served area. If a separate port schedule exists, compare the two documents before issue.

For point-to-point services, the same principle applies. Verify that the fiber pair, panel port, customer or site identifier, and far-end termination all describe one consistent circuit.

6. Review naming, revision, and field usability

Technical correctness is not enough if the schedule is difficult to use.

A field-ready document should provide:

  • Clear document title and project reference
  • Revision number and issue status
  • Date and responsible discipline
  • Consistent cable and enclosure names
  • Defined direction or orientation
  • Legible column headings
  • Notes for special splices, pass-throughs, reversals, or exceptions
  • Page numbering where the schedule spans multiple sheets
  • Space or process for recording field changes

Avoid unexplained abbreviations. A term that is obvious to the design team may not be obvious to a subcontract splicer joining the project later.

The schedule should also support redlining. Field teams need a controlled way to record changes when site conditions differ from the issued design. Without that process, the network may be built correctly while the record remains wrong.

Use a cross-document QA sequence

The strongest review sequence moves from the network level to the individual splice:

1. Confirm the approved topology and service areas.

2. Confirm cable routes, cable IDs, and fiber counts.

3. Confirm closure, cabinet, terminal, and panel locations.

4. Trace end-to-end continuity.

5. Check duplicate, missing, reserved, and out-of-range fibers.

6. Reconcile splitter and port assignments.

7. Review physical enclosure practicality.

8. Check naming, revision control, and field readability.

9. Issue the schedule with the same revision status as the related drawings.

This sequence prevents a common QA mistake: spending time correcting spreadsheet formatting before confirming that the network logic is sound.

What a controlled splice package should contain

Depending on the project, the final splice package may include:

  • Fiber topology or single-line diagram
  • Cable and fiber schedule
  • Closure-by-closure splice schedule
  • Splitter and port allocations
  • ODF or panel terminations
  • Route drawings or GIS references
  • Enclosure details where required
  • Revision history
  • Field redline instructions
  • Test and acceptance references

These documents should behave as one package. If a change is made to the topology, the affected schedules and drawings should be revised together.

Reducing splice-documentation backlog

Splice documentation is often delayed because it sits between several teams: network design, GIS or CAD production, construction, splicing, testing, and closeout. Clear inputs and acceptance criteria make the work easier to control.

A defined package can specify the source drawings, cable list, naming convention, output template, QA checklist, reviewer, and required delivery date. That structure allows supplementary engineering capacity to be added without changing the client's standards or document controls.

Pathworks Engineering supports fibre topology, splice schedules, cable and port documentation, CAD/GIS production, redline conversion, as-builts, and QA/QC. For teams managing a documentation backlog, a useful first step is one bounded route or closure package with agreed inputs and acceptance checks.

FTTxFiber SplicingSplice ScheduleOSP DesignQA/QCFiber DocumentationAs-BuiltsNetwork Closeout