Dark Fiber IRU Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the contract repository trap catch so many IRU projects?

The brief almost always arrives in the same words: get our indefeasible right of use agreements into a system. That sentence describes a filing project, and a filing project is what gets delivered. Six months later every agreement is scanned, tagged, dated and searchable, renewal alerts fire on time, and nobody can still tell a sales engineer which strands on the route between two markets are unencumbered.

The failure is specific to this asset class. An indefeasible right of use, usually shortened to IRU, is not a service contract with a renewal date. It is a property style interest in named physical fibres, prepaid decades ago, running twenty or thirty years, with a recurring maintenance charge and a set of rights attached to a piece of glass in the ground. What you need in a system is not the document. It is the encumbrance: this counterparty holds these strands, on this segment, from this splice point to that one, until this date, under these terms.

Scope drifts toward the document because the document is easy. It exists, it uploads, and progress is visible in a weekly demo. The encumbrance is hard, because it has to be reconciled against plant records that were never built to carry a commercial obligation, and that reconciliation is slow contested work that produces nothing worth showing for several weeks.

The fix is an acceptance test written before anyone quotes. Pick one real route. The system must return, on a single screen, the total fibre count per segment, lit usage, encumbered strands, the agreement encumbering them and the expiry. If a proposal cannot explain how that screen gets populated, it is a contract repository proposal in different clothing, and you will pay a second time for the part you actually wanted.

What goes wrong when legacy IRU agreements get abstracted?

Abstraction is the process of reading each agreement and encoding its terms as structured data. On IRU portfolios it is the single largest line in the budget, and it is the line most often priced as data entry when it is closer to legal review.

The exhibits are the reason. A 2009 agreement describes strands 25 through 36 on the segment from a named handhole to the north side of an interstate crossing. Since then the route has been spliced, a span was relocated for a road widening, a regeneration site was added and one section's fibre count changed during a cable replacement. The handhole reference may not exist in any current record. Then there are amendments that changed the strand count, an assignment that changed the counterparty, and a side letter that quietly capped the escalator.

Three failure patterns show up repeatedly:

• The abstractor guesses at an ambiguous segment reference and nobody records that it was a guess, so a soft answer becomes hard data.
• An exhibit that cannot be mapped to current plant is skipped, which creates an empty encumbrance, which the availability screen then reports as free capacity. This is worse than having no system at all.
• Amendments are filed as documents but not applied to the abstracted record, so the system holds the original terms with more authority than the amended ones.

The fix is a two pass process with an explicit confidence field. Pass one encodes what is unambiguous. Anything ambiguous goes to an unresolved queue with the exact clause text attached, and someone with authority to decide, usually a network engineer and a lawyer together, works the queue. Nothing enters the availability calculation until it is resolved, and unresolved segments are shown as unknown rather than as available. Unknown is an honest answer that protects you. Available is a claim you cannot support.

Why do the fibre inventory and mapping integrations break after launch?

The encumbrance only means anything because it points at a strand and a segment in your inventory system. That pointer is the fragile part, and it usually breaks quietly some months after go live.

The mechanism is plant change. VETRO FiberMap and 3-GIS both model fibre plant properly and both are the right tools for that job, but records inside them are not frozen. Cables get replaced, segments get split at a new splice point, a route gets relocated and re-identified, and an acquired network gets loaded using a different naming convention. If your integration joins on an identifier that the inventory system treats as mutable, the encumbrance detaches from the plant and points at nothing. No error appears. The availability screen simply starts reporting more free capacity than exists.

Two design decisions prevent it. First, hold your own stable surrogate key for every encumbered segment alongside the inventory system's identifier, so a changed identifier becomes a mismatch you can detect rather than a silent orphan. Second, run a reconciliation job on a schedule that reports every encumbrance whose target no longer resolves, every segment whose fibre count changed since the encumbrance was written, and every segment where encumbered strands now exceed the total count. That report should go to a named person, not a dashboard.

Treat plant change as an event the system has to handle, not an exception. A relocation or a cable replacement should generate a task to reassign the affected encumbrances, with the reassignment recorded and dated, because a counterparty may later ask which fibres they hold and the honest answer has a history.

What happens when escalation, relocation and restoration are left out of scope?

These three get deferred to phase two more often than anything else, on the reasonable sounding argument that the encumbrance model comes first. The trouble is that they are where the money and the disputes actually sit.

The maintenance charge escalates annually by an index or a fixed percentage, sometimes with a cap. Applied by hand, it gets missed in years when the responsible person changes, applied from the wrong index month, or applied to an agreement that had a cap nobody carried forward. Over a twenty five year term that compounds, and it is invisible in the ledger because the ledger records what was invoiced rather than what was owed. Since most operators sit on both sides of IRUs, the same gap means you are also paying incoming invoices nobody checks against the agreement.

Relocation is worse because it is adversarial. A highway agency orders a move, the cost is shared between everyone on the route by a formula that differs in every agreement, and assembling the shares means reading contracts under time pressure while counterparties read theirs and dispute yours.

Restoration is worse again because it happens at two in the morning. The response time commitment, the maintenance obligation and the liability position differ per agreement, and the technician on the cable has visibility into none of it.

The fix in all three cases is the same shape. Hold the charge as a formula, with rate basis, unit count, escalation method, index source, effective month, cap and floor as structured fields, so the annual adjustment produces an invoice and a notice showing the calculation. Attach the cost sharing formula and the restoration terms to the segment through the encumbrance, so a relocation project outputs the participant list and each share, and an outage ticket surfaces the obligations that apply before anyone is dispatched.

Should you build custom or configure what you already own?

For a real share of operators reading this, the answer is configure, and we would say so before quoting.

If your actual problem is that agreements are unsigned, unfiled or scattered across three shared drives, that is a contract lifecycle problem and Agiloft or Icertis solve it properly. Clause libraries, approvals, obligation tracking and date management are mature there and rebuilding them is a waste of your money.

If your actual problem is that your plant records stop at cable level, or that an acquired network was never properly loaded, then no contract system can help you, because the encumbrance has nowhere precise to attach. Fix that first with VETRO FiberMap or 3-GIS. That is inventory work, it is what those products are built for, and the contract layer has to wait for it.

And if you hold a handful of IRUs on one route with a single counterparty, a well maintained folder and a calendar entry is genuinely enough. Spend the money on plant.

Build when the join is the problem: when your commercial team quotes availability without any system check against encumbrances, when agreements have outlived the people who negotiated them, when escalators are applied by hand or cannot be confirmed at all, or when a financing or sale is approaching and encumbrance clarity will affect what you are paid.

How do hidden costs get into the quote?

Four items account for most of the overruns we see in this category, and all four are knowable before you sign.

Abstraction volume priced as a lump. A fixed price to abstract the portfolio, quoted before anyone has read a contract, is a guess. Insist on a sample: give the developer five agreements chosen to include one clean recent one, one from an acquired network and one with amendments, and price per agreement from what that sample actually took.

Inventory readiness assumed rather than checked. If strand level records do not exist for the routes that matter, the build cannot do its job, and discovering that in week six turns into an unbudgeted inventory project. Check three routes before kickoff.

Counterparty portals slipped in as a screen. A portal means authentication, permissions, statement generation, a support path and someone answering questions from a counterparty's asset manager. It is a workstream, not a page.

Index data. Escalation formulas reference published indices, and sourcing those reliably year after year, with the right vintage and the right revision behaviour, is a small ongoing obligation that quotes routinely omit.

What separates a build that works from one that fails here?

Ask the developer to draw the encumbrance object on a whiteboard before you sign anything. The right answer references segment and strand identifiers from your inventory system, carries a term, a counterparty, a charge basis and a version history that survives plant change. If they draw a contract with an attached file, they have built a repository before and will build one again.

Ask what happens to an encumbrance when a cable is replaced. If the answer is vague, your obligations will detach from your plant and you will trust the system right up to the moment it is wrong in front of a customer.

Ask which inventory system they have integrated, by name, and what broke. 3-GIS, VETRO and an internally built spatial database are three different problems, and a developer who asks which system holds strand level truth before quoting is asking the right question.

Settle ownership of the repository, the cloud accounts and the data in the contract before kickoff. At Digital Heroes the client owns it from the first commit. Then do the free version of this project first: pick one route you believe has spare capacity and have someone read every agreement touching it. Whatever that turns up, and however long it takes, is your business case and your scope document at the same time.