Connected and traceable: what''s actually included

Our commitment at Nutility is to deliver a connected and traceable Utility Network in a matter of weeks. Through many recent discussions, we've found ourselves explaining just what all is involved in those three simple words: "connected and traceable." It's more than you might think, so we thought it deserved its own article.

Why "connected and traceable" is the whole ballgame

Every utility that migrates to the ArcGIS Utility Network is chasing the same prize: a network model that can actually trace. Upstream and downstream tracing, isolation trace, connected trace, and protective device traces — these aren't nice-to-have GIS features. They're the reason utilities undertake a UN migration in the first place. A UN that isn't fully connected and traceable is, functionally, an expensive migration of your legacy GIS that happens to run on a different platform. You get the licensing cost and the migration effort without the analytical payoff.

The catch is that "connected and traceable" isn't a single deliverable you either have or don't. It's the sum of a long list of underlying data conditions, almost all of which trace back to how your legacy system stored (or didn't store) connectivity information. Legacy electric GIS platforms were, for the most part, never built to enforce network topology the way the UN does. They tolerated gaps, workarounds, and "close enough" geometry that was easy to overlook until now. Migrating that data into a topology-enforcing model surfaces every one of those historical shortcuts at once.

That's the work. Below is what it actually involves.

The conditions that must be met

In order for a Utility Network to be totally connected and traceable, a number of conditions must be satisfied across every feature class and every segment of your network:

Subnetwork controllers defined and assigned. Every subnetwork in the UN — every circuit, pressure zone or system — needs a controlling device (a breaker, recloser, regulator or other protective device) explicitly assigned as its source. Without this, the UN has no anchor point to trace from, and tracing tools will return an error if you attempt to trace within this section of the system.

Network attributes defined and assigned. The UN relies on network attributes (phase, voltage, load, device status, lifecyclestatus and others) being populated consistently across every applicable feature. Many organizations have accumulated incomplete or inconsistent data across these attributes which may or may not have historically impacted connectivity. Going forward, these gaps can produce connectivity errors or even cause the data to be dropped from migration.

Device terminals defined and assigned. Terminals define how current, water, or gas physically flows through a device — which side is upstream and which side is downstream. If terminals are missing or misconfigured, the UN doesn't know how to route a trace through that device at all. If no terminals are assigned at controllable devices, you won't be able to perform an isolation or protective device trace.

Connectivity rules defined for all requisite data conditions. The UN uses connectivity rules to determine which asset types are allowed to physically connect to which other asset types. Off-the-shelf rule sets are built for a generic network, not yours. If your legacy data includes connections the default rules don't anticipate — and it will — those features get silently excluded from the traceable network unless the rules are extended to match your actual conditions.

Stacked and duplicate points resolved. Legacy systems often store multiple point features at the exact same coordinate — a longstanding digitizing shortcut that never caused a visible problem until a topology model has to determine which feature is actually there. The UN can't build correct connectivity when two connected points exist at the exact same location.

No missing junctions. Wherever two or more lines meet with differing categories or subtypes (which may end up different asset groups), the UN requires a device or junction. This is one of the most common errors in a UN migration, because conditions like primary overhead connecting directly to underground or iron pipe connecting directly to plastic pipe was allowed in the GN, even if that did not accurately depict the real-world conditions. These absent points in the UN will create dirty areas and stop tracing.

Why this is the biggest driver of project timelines

This list represents a variety of data conditions that will be encountered — and must be addressed — during every single UN migration. Remediating the issues behind these conditions is often the biggest contributor to overall project duration from a modeling and migration perspective. It's not the schema design, and it's not the software configuration; it's the unglamorous, feature-by-feature work of finding and fixing the thousands of small inconsistencies buried in decades of legacy GIS editing.

Because of this reality, we knew we needed a process that could quickly identify and remediate these conditions in order to radically shorten UN project timelines, which is the entire premise Nutility was built on. Our data assessment sniffs out these conditions — the ones that are often overlooked in the source system and not captured in the other guy's Data Reviewer checks — and our migration process aims to remediate an average of 97% of the data conditions that would otherwise inhibit connectivity in the UN.

The entirety of this data cleanup is performed with a human in the loop. Our engineers validate remediation up to that 97% target and only escalate to clients the conditions that have no clear answer from the data alone. That's how we close the remaining 3%: not by guessing, but by routing genuinely ambiguous cases — the ones where two legitimate interpretations of the legacy data are both defensible — to the people who actually know the network.

Every one of these remediation actions is logged as it happens. Clients don't just get a clean database at the end; they get a complete, auditable inventory of every piece of data that was touched, what was changed, and why. Nothing gets fixed silently.

What the remediation work looks like, concretely

Put plainly, this involves remediating issues like:

Values outside of domain. Attribute values that don't match any assigned domain code can impact connectivity in the UN or worse, prevent data from migrating. These are silent killers in a UN migration, so we sniff them out in your source data and correct them proactively to prevent any downstream impacts in the process.

Creating rules to offset defined points where stacked features exist. Those stacked streetlights or anodes you've been modeling in the GN will produce multiple connectivity errors for at each location in the UN. We summarize these issues and work with you to establish rules to offset these stacked points either horizontally or vertically in order to produce a clean topology in the UN.

Creating junctions where required by the UN. One of the most voluminous error producers in the UN is the absence of junctions that are required by UN but weren't in the GN. We identify these locations and create features that depict real world conditions as much as possible, such as tees or couplings for gas and water, or connectors and terminators for electric.

Creating connectivity rules that match your data, not an off-the-shelf model. This is the piece that's easiest to underestimate. Every utility's network has its own real-world quirks: nonstandard equipment configurations, regional construction standards, decades of field crews making practical decisions that never quite matched the "textbook" model. Trying to shoehorn your data into a ruleset defined in an off-the-shelf model is an exercise in futility; or at least a way to make your project more complicated and costly than it needs to be. Once all your legacy data is migrated to a reasonable asset group and type, terminals are defined and assigned, and junctions are created, connectivity rules must be built to support these specific elements and conditions.

The takeaway

"Connected and traceable" sounds like a checkbox. In practice, it's a few hundred thousand individual decisions about individual features, made consistently across an entire network. That's exactly the kind of work that's slow when it's manual and error-prone when it's rushed — and it's exactly the kind of work our AI agents, paired with senior GIS engineers, are built to compress from years into weeks.

When we say we deliver a connected and traceable UN, here's exactly what that means you'll have in hand:

• A connected and traceable Utility Network database — the fully remediated, trace-ready network itself
• Detailed source-to-target mappings — a clear record of how every piece of legacy data maps into the UN model
• A QA report showing the quality and completeness of all migrated data
• A "publish map" configured with your symbology and refined field visibility, ready to use for publishing your initial UN services