Skip to content
Vinxi/Kernel THE BOOK OF RECORD

ESRI ArcGIS Utility Network — Study

Esri ArcGIS Utility Network — Architecture, Data Model & Competitor Analysis

Purpose: Understand, ground-up, how Esri has architected and designed ArcGIS Utility Network (UN) — its data model, personas/user stories, UIs and client surfaces, workflows, extensibility, and customizability — and frame the findings as a competitor analysis for Lepton Infrastructure Cloud. This is both a learning document (UN is the de-facto global reference model for utility GIS, so it is the best teacher of the domain) and a strategy document (it is our most credible competitor, and the precise contours of where it is strong vs. heavyweight tell us where a greenfield, graph-native, event-sourced platform wins).

One-line verdict: ArcGIS UN is a mature, rigorous, analytically powerful fixed-schema geospatial data model that has correctly identified the right domain primitives (commodity networks, associations, subnetworks, rule-gated connectivity, tracing). Its weaknesses are not conceptual but architectural: materialize-then-validate topology, deferred batch subnetwork recompute, hub-and-spoke branch versioning, and a heavyweight proprietary ArcGIS Enterprise deployment. Lepton should steal the domain model wholesale and replace the architecture — live derivation instead of batch validation, distributed log-based merge instead of central reconcile/post, and an open graph-native substrate instead of a licensed multi-service stack.

Provenance note. Findings marked with [cite] rest on a verified deep-research pass over Esri’s own primary documentation (pro.arcgis.com / developers.arcgis.com / enterprise.arcgis.com), live-fetched and adversarially fact-checked (21 confirmed claims, 9 of 10 unanimous; 4 refuted claims explicitly excluded — see §13). Sections on personas, client-surface split, and schema-level customizability were thinner in that pass and draw on general product knowledge; they are flagged [product knowledge — verify] and collected as open questions in §12. Treat the data-model and versioning sections as solid; treat the persona/UI sections as a strong working model to confirm.

1. Orientation — what UN is and the problem it solves

ArcGIS Utility Network is Esri’s framework for modeling utility systems — electric, gas, water, stormwater, wastewater, and telecommunications — capturing both the physical assets (wires, pipes, valves, devices, circuits, zones) and the commodity that flows through them. [cite] It is the successor to the older Geometric Network (and the even older coverage/ArcInfo network models), introduced in 2018 and now the strategic platform Esri is migrating all utility customers onto (with a well-publicized late-2026 push to retire the geometric network).

The core insight UN encodes: a utility is not a map, it is a network with a flowing commodity, and the questions that matter are network questions — “if this valve closes, who loses water?”, “trace upstream to the source”, “how many customers does this circuit feed?”, “is this connection physically/electrically valid?”. A pile of geometry alone cannot answer these; you need an explicit, rule-governed connectivity model on top of geometry. That is exactly what UN is.

This is the single most important thing to internalize for Lepton: Esri has already proven that the domain primitive is a commodity network with rule-gated connectivity and trace-derived subnetworks. We are not inventing the domain model; we are re-implementing it on a better substrate.

2. The data model (the heart of it)

UN is a fixed-schema, layered geospatial data model — not a generic property graph. [cite] Understand the layers from the outside in.

2.1 Two kinds of network: domain networks + the structure network

  • Domain network(s) — one or more, each carrying a single flowing commodity (water, gas, electric, telecom). A UN “contains one or more domain networks.” [cite] This is where the live system lives: conductors, mains, services, devices, junctions.
  • Structure network — exactly three feature classes: StructureJunction, StructureLine, StructureBoundary. No resource flows through it. [cite] It models the physical containers and supports — poles, ducts, conduit, vaults, trenches, towers — that hold or carry domain features. The separation of “the thing that carries the commodity” from “the thing that physically supports it” is a clean and reusable idea.

2.2 Tier groups and tiers — mandatory partitioning

Inside a domain network, features are first organized into a mandatory, administrator-defined hierarchy of tier groups and tiers. [cite] A tier typically represents a physical pressure or voltage level (e.g. transmission vs. distribution; high-pressure vs. low-pressure). A tier:

  • constrains which feature types are valid within it, and
  • defines the range of network tracing analysis (traces are scoped by tier). [cite]

The hierarchy is configurable at design time but effectively fixed post-deployment (hierarchical tier ranks cannot be altered) — this configuration-time rigidity is a deliberate trade for analytical guarantees, and a key contrast point: a graph-native platform need not pre-partition the network into fixed physical levels.

2.3 The classification schema: asset groups & asset types [product knowledge — verify]

Within a tier, domain features use a fixed set of base feature classes (device, line, junction, assembly, subnetline, plus nonspatial junction objects / edge objects), and each row is classified by a two-level subtype scheme:

  • Asset Group (e.g. “Transformer”, “Switch”, “Service Point”) — a subtype of the base class.
  • Asset Type (e.g. “Single-phase Pole-mount Transformer”) — a finer classification under the asset group.

This base class → asset group → asset type triple is how UN gets domain richness out of a fixed schema: you do not add tables, you add asset groups/types as configuration. This is genuinely close to Lepton’s Entity / Trait thinking, except UN’s is a closed subtype hierarchy rather than open composition. (Lepton parallel: asset group/type ≈ a constrained, single-inheritance version of Entity-Trait. Our open Trait composition is strictly more expressive.)

2.4 Network attributes & terminals [product knowledge — verify]

  • Network attributes are feature attributes promoted into the topology index so traces can read them without hitting the feature table — they drive barriers, filters, and function results in a trace (e.g. “stop at open device”, “sum the load”). They are the performance trick that makes tracing fast.
  • Terminals & terminal configurations model the internal ports of a device (e.g. a switch has source-side and load-side terminals; a transformer has high/low terminals). Connectivity and subnetwork controllers are set at the terminal level, not just the feature level. This is how UN represents internal device wiring — directly relevant to telecom ports/strands/splices.

⚠️ Do not assert a specific fixed “four-part traversability taxonomy (tiers/categories/attributes/ terminals) that replaces network-weights” as the configuration scheme — that specific framing was refuted in the research pass (§13). These objects exist, but the exact taxonomy claim is unreliable.

2.5 Associations — the explicit relationship layer (exactly three types)

Relationships beyond spatial geometry are modeled through associations, and the model defines exactly three association types: [cite]

  1. Connectivity association — connects two features that are not geometrically coincident (e.g. a transformer wired to a distribution line without sharing a coordinate). [cite]
  2. Containment association — a feature is contained within another (e.g. devices inside an enclosure, conductors inside a duct) — supports “show contents” / collapse-expand.
  3. Structural attachment association — a domain feature is physically attached to a structure feature (e.g. a transformer attached to a pole).

The compiled network graph is fed by both geometric coincidence and associations — associations are the explicitly-modeled relationship layer for relationships geometry alone cannot express. [cite]

⚠️ Do not call associations a “bolt-on atop a feature-layer foundation” — that framing was refuted (§13). They are first-class participants in the topology.

2.6 Connectivity vs. traversability — a distinction worth stealing

UN cleanly separates two properties: [cite]

  • Connectivity = two features have geometric-coincidence connectivity or are joined by a connectivity association.
  • Traversability = connected features that also have a path satisfying the trace configuration (barriers, filters, direction).

So a network can be connected but not traversable for a given analysis (e.g. an open switch breaks traversability without breaking the physical connection). This two-level model — physical connectivity vs. analytical reachability — is exactly the right abstraction and Lepton should adopt it explicitly.

2.7 Network rules — the gate on what may connect

UN enforces what is allowed to connect or associate through a rule base. Esri’s actual rule types are five (correct this in any doc that says “three”): [cite]

  • junction–edge connectivity
  • junction–junction connectivity
  • edge–junction–edge connectivity
  • structural attachment
  • containment

Once a rule base exists, “no network features can connect or associate that are not supported by a rule” — snapping a line to a point does nothing if no rule permits it. [cite]

Documented exception (carry this nuance): two coincident edge elements of the same asset group/type auto-connect via a system junction without a user-defined rule. So “rules must always exist first” is not absolute.

2.8 Subnetworks & subnetwork controllers — trace-derived, then persisted

A subnetwork is a topological subset within a tier: the set of features that have traversability to the same set of subnetwork controllers. [cite] It is the UN representation of a circuit (electric), a pressure/DMA zone (water/gas), or a delivery area.

  • It is created by designating features as subnetwork controllers — sources (commodity flows away) or sinks (commodity flows toward) — with the subnetwork name set on a controller terminal. [cite]
  • Membership is computed by tracing connectivity from the controllers — derived, not hand-assigned — and then persisted as a subnetwork-name attribute on member features. [cite]

⚠️ Refuted (do not repeat): “subnetworks are not stored, only discovered on demand by tracing.” In fact membership is materialized/persisted, and refreshing it is an explicit deferred batch step (Update Subnetwork), not on-demand discovery. This batch-recompute model is a primary differentiation target for live/event-sourced derivation. (§13)

2.9 Network topology — a separately stored, materialized graph

This is the architectural keystone — and UN’s biggest liability.

UN does not trace directly against the editable features. It maintains a separately stored, materialized “network topology” (an index/graph) that must be explicitly validated to synchronize with feature edits. [cite] Mechanically:

  • Any creation/modification of network features, associations, or network attributes produces inconsistencies flagged as “dirty areas” — explicit spatial markers that “the content you see on the map does not match what is stored in the network topology.” [cite]
  • Dirty areas persist until the user explicitly runs Validate Network Topology; they clear only if no rule error exists in the validated extent. [cite]
  • On the Default version of an enterprise geodatabase, only one validate session can run at a time (validation is serialized), though editing and tracing remain available during validation. [cite]

(Nuance: edits to unlocatable nonspatial objects do not create dirty areas, so “any edit” slightly overstates.) This explicit materialize → diverge → batch-validate loop is the single largest architectural contrast between UN and a live graph-native model.

3. The editing & analysis workflows (the lifecycle)

UN editing is not free-form — it is a disciplined lifecycle. [cite]

   EDIT (features / associations / attributes)
        │  every edit → produces DIRTY AREAS  (map ≠ stored topology)
        ▼
   VALIDATE NETWORK TOPOLOGY  (explicit; INCREMENTAL — dirty-bounded, extent-scoped, schedulable async;
        │                       but single-session on Default — see §9.5)
        │  clears dirty areas where no rule error exists; failures become error features
        ▼
   UPDATE SUBNETWORK  (explicit; scoped to DIRTY subnetworks; holds a shared lock on Default — see §9.5)
        │  subnetwork state machine:  DIRTY → CLEAN  (or → INVALID on consistency failure)
        ▼
   TRACE / REPORT  (upstream/downstream, flow, load summaries) — needs enabled topology + controllers + start points

3.1 Subnetwork state machine [cite]

  • dirty — has validated edits not yet processed by Update Subnetwork.
  • clean — successfully updated.
  • invalid — consistency failures discovered during Update Subnetwork.

3.2 Tracing — the payoff

With an enabled topology + controllers + start points, UN runs built-in topology analytics: [cite]

  • Upstream / downstream trace from any location.
  • Resource-flow tracing (how gas/water/electricity actually flows).
  • Subnetwork-based reporting, e.g. electric load summaries (“how many customers does this subnetwork feed?”). [cite]

⚠️ Refuted (do not repeat): “traces run via a Trace geoprocessing tool and there are exactly eight basic trace types.” Do not commit to a fixed trace-type count or that exact tool framing (§13). Common trace types include connected, upstream, downstream, subnetwork, shortest-path, isolation, and loops — list them as examples, not an exhaustive enumeration.

4. Personas & user stories [working model; surface mapping verified in §5]

The persona→surface mapping below is now corroborated by the verified surface-capability matrix in §5 (e.g. only Pro can author traces / edit associations / reconcile-post). The specific story wording remains a working model from general product knowledge.

PersonaPrimary surfaceCore jobs / user stories
GIS Data Editor / Network EditorArcGIS Pro (primary); Web Editor”As an editor, I add/modify assets and connectivity in a named branch version, validate the topology, and reconcile/post my edits.” Lives the §3 lifecycle daily.
GIS Analyst / Data StewardArcGIS Pro”I configure asset groups/types, network attributes, rules, and tiers; I run QA traces and resolve dirty areas / invalid subnetworks.” Owns model integrity.
Planner / DesignerArcGIS Pro + (often) extensions like ArcGIS for Network Design / 3rd-party design tools”I design extensions, run what-if traces, size circuits/zones, produce load summaries.”
Field Worker / InspectorArcGIS Field Maps (mobile, offline)“I view the network in the field, redline, capture inspections, sometimes edit offline and sync.” (Mobile + branch versioning has real friction — §11.)
Operations / NOC viewerWeb apps (Experience Builder / Instant Apps), ArcGIS Velocity for real-time”I view live network state, outages, sensor feeds; I trace impact.”
GIS AdministratorArcGIS Enterprise admin, Pro”I publish UN services, manage branch versions, schedule reconcile/post, manage the multi-component server stack.”

The persona split reveals UN’s center of gravity: the heavy, authoritative work happens in ArcGIS Pro (desktop); web and field are increasingly capable but historically secondary. A modern competitor can win by making the web/browser surface the first-class authoring environment, not a downstream viewer.

5. Client surfaces & UIs — what Esri actually exposes [cite — verified pass]

UN is consumed through a family of separate clients, and the capability gradient is steep and deliberate: authoring power concentrates in ArcGIS Pro (desktop); web and field are real but bounded; real-time is a separate product. The single most revealing fact from the research: reconcile/post — the act of integrating edits into shared truth — is desktop-only; you cannot do it in the browser. [cite] Likewise association editing and trace authoring are desktop-only; web/field can run pre-authored traces but not create them. [cite]

5.1 Capability matrix (verified)

SurfacePersonaEdit featuresEdit associationsAuthor tracesRun tracesValidateReconcile/Post
ArcGIS Pro (desktop/Win)editor · analyst · admin✅ full, network-aware✅✅✅ all✅✅ (only here)
Web Editor (browser)non-GIS editor · field-proximate crew✅ create/delete via templates❌ view only❌✅✅ by extent❌ → use Pro
Experience Builder (browser)ops · analyst · public❌❌❌✅ Trace widget❌❌
Field Maps (mobile)field worker✅ geometry + attrs, on/offline❌❌✅ named traces(on sync)❌
Velocity (cloud real-time)ops / NOCn/a — event feedsn/an/aper-event analyticsn/an/a

5.2 Surface by surface (verified)

  • ArcGIS Pro (desktop, Windows) — the authoring home. Editing tools are network-aware: created features “automatically conform to the rules and associations defined for the network.” [cite] Schema design, trace authoring (named trace configs), validation, subnetwork management, network diagrams, and — uniquely — reconcile/post all live here. Heavy, expert-oriented, Windows-only.
  • ArcGIS Web Editor (browser) — genuine browser-based UN editing, not just viewing: create/delete features via editing templates and Group Templates, validate topology by extent, view associations, run traces. Explicitly aimed at editors “without … advanced GIS expertise” and at freeing up “crews … closer to the assets.” [cite] Constraints (verified): requires branch versioning (you open/create a named version — “like branches in Git”); Dirty Areas are surfaced directly in the browser and must be validated before save; and you cannot reconcile/post here — that requires Pro. [cite]
  • Experience Builder — UN Trace widget (browser) — analysis-only: runs connectivity/traversability traces in the browser, cannot edit. Requires the topology to be enabled and validated; tracing across dirty (unvalidated) areas is unreliable. [cite] This is the “viewer/analyst” web surface (plus Map Viewer / Instant Apps / Dashboards for viewing & monitoring).
  • ArcGIS Field Maps (mobile, iOS/Android) — edits feature geometry + attributes, online or offline, but cannot edit associations. [cite] Runs named trace configs (upstream, downstream, isolation, subnetwork, connected, loops) authored in Pro — it cannot author them itself. [cite] Field is capture + run-pre-authored-analysis, not authoring.
  • ArcGIS Velocity (cloud, real-time/big-data) — a separate product: ingests live data “from nearly any source” (sensors, assets, feeds; cloud IoT platforms, sensor APIs, message brokers via preconfigured integrations) [cite] and runs per-event analytics — “evaluate every event as it arrives using spatial, temporal, and attribute-based conditions” including geofence/proximity. [cite] This is the closest analog to Lepton’s high-frequency telemetry-ingest spike — note it is bolted beside UN, not woven into the same model.
  • Network Diagrams — schematic (non-geographic) single-line views generated from connectivity, served by NetworkDiagramServer (§6). The view operators actually think in; worth replicating.

5.3 Read for Lepton

The verified picture is sharper than “desktop-first”: the consequential operations — trace authoring, association/relationship editing, and reconcile/post (merge to shared truth) — are all locked to the Windows desktop. Web and field are deliberately “view + light-edit + run-pre-authored-analysis,” and real-time is a wholly separate app. That stratification is the seam to attack:

Lepton’s one adaptive multi-surface UI (Stage / Surface / Sanjaya planes — see [[project-lepton-adaptive-ui-framework]]) should make the browser a first-class authoring + merge surface — edit Links/relationships, author traces, and promote/merge a draft from the same surface that adapts density per device — instead of shipping four apps with four capability tiers and forcing the high-value work back onto desktop. And telemetry (the Velocity analog) should be in the model (event-sourced), not a side product.

6. Architecture, services & extensibility

6.1 Service-based architecture — not a monolith

In an enterprise deployment, UN is exposed as a set of distinct server-side REST services, not a single endpoint: [cite]

ServiceResponsibility
MapServerMap rendering
FeatureServerFeature CRUD / query
UtilityNetworkServerTrace, Validate Network Topology, Update Subnetwork, Update Is Connected, Query Network Moments, Enable/Disable Topology [cite]
NetworkDiagramServerSchematic network diagrams
VersionManagementServerBranch version create / reconcile / post / undo-redo [cite]
ValidationServerValidation operations

Critically, trace, topology validation, and subnetwork update are server-side operations — the heavy compute runs on the server, not the client. [cite] (ArcGIS Pro / Runtime SDKs can also trace client-side against a local geodatabase, which doesn’t contradict the service framing.)

6.2 Extensibility / customizability surface [mixed cite + product knowledge]

  • REST services — the services above are directly callable; this is the integration backbone. [cite]
  • ArcGIS API for Python (arcgis) + arcpy — scripting branch versioning, edits, traces, automation. Branch-versioning is a documented Python workflow. [cite]
  • ArcGIS Pro SDK (.NET) — custom desktop tools/add-ins.
  • ArcGIS Maps SDKs (Native / JS) — build custom apps that consume UN services.
  • Attribute Rules (Arcade) — server/geodatabase-side business logic on edit (calculation + constraint rules); the main “no-microservice” customization hook.
  • Schema configuration — asset groups/types, network attributes, rules, tiers, terminal configs are all configuration, not code (this is genuinely powerful — domain richness without schema migrations).

Open customizability question (§12): whether the fixed base-class set + exactly-three association types can be extended with custom relationship semantics, and whether telecom/fiber (splices, ports, strands) fits cleanly into connectivity/containment/structural-attachment — directly relevant to Lepton’s FTTx domain. Esri added a telecom domain network (circuit management) in the 2026 release, which suggests fiber was made to fit the same primitives — worth verifying how cleanly.

6.3 Concurrency: branch versioning — the heavyweight core

Multi-editor concurrency depends entirely on branch versioning — “the mechanism behind long-transaction editing for web feature services.” [cite] The model is hub-and-spoke:

  • Each editor works in an isolated named branch version (one editor per named version). [cite]
  • They reconcile and post back to a single central Default version — “the target version is always the default version.” There is no peer-to-peer, named-version-to-named-version merge. [cite]
  • This is an enterprise-geodatabase-bound feature, managed by the dedicated VersionManagementServer, and is mandatory for UN (also for parcel fabric, trace networks, LRS). [cite]

This is the architectural pressure point. Centralized reconcile/post against a single Default version is the opposite of a distributed, log-based, mergeable model. Replacing hub-and-spoke versioning with event-sourced/log-based versioning is the cleanest, most defensible differentiation for Lepton — though to make it actionable we need to study UN’s conflict-detection granularity on reconcile/post (§12).

7. Deployment & licensing footprint — the proprietary weight

UN’s richest, multiuser capabilities require an enterprise deployment on a services-based architecture using ArcGIS Enterprise. [cite] For web/mobile viewing or multi-user editing, “you must deploy the dataset to ArcGIS Enterprise and create web services for it.” [cite]

  • Base ArcGIS Enterprise = four licensed components — ArcGIS Server, Portal for ArcGIS, ArcGIS Data Store, Web Adaptor — plus authorization files. [cite]
  • A single-user file/mobile geodatabase deployment exists but is read-only-concurrent, single-editor, no branch versioning — i.e. a toy compared to the enterprise capability. [cite]

So the “heavyweight / proprietary” characterization is factually grounded, not rhetoric: full UN means a multi-component, licensed, server-side stack with a serialized validation bottleneck on Default. This is the cost/lock-in surface a SaaS-native competitor attacks directly.

8. Honest strengths (what we must respect / steal)

  1. The domain model is right. Commodity domain networks + structure network, associations (3 types), rule-gated connectivity, connectivity-vs-traversability, controllers, trace-derived subnetworks — this is a battle-tested ontology refined across electric/gas/water/telecom worldwide. Steal it.
  2. Configuration-not-code schema richness. Asset groups/types/attributes/rules as configuration avoids the SmartInventory “1,626 branches / custom entities require a fork” disease. (Lepton’s open Trait composition should be more expressive, not less.)
  3. Connectivity vs. traversability as distinct, rule-gated properties — adopt explicitly.
  4. Subnetworks as derived, named, reportable objects (load summaries, customer counts) — the right way to think about circuits/zones.
  5. Tracing as a first-class, configurable analytical engine (barriers/filters/functions via network attributes) — fast because the topology is indexed.
  6. Schematic network diagrams — operators think in single-line diagrams; this is a real UI win.
  7. Maturity & ecosystem — global deployments, training, partners, migration tooling. We will not out-mature Esri; we out-architect them.

9. Honest weaknesses (where we win)

#WeaknessWhy it’s a weaknessLepton’s counter
1Serialized, manual, whole-Default validate [cite]Note: the dirty/validated distinction is good — keep it. The weakness is the implementation: a single manual, serialized-on-Default, monolithic batch op; state is stale-by-default with no freshness SLA.Validation as policy, not architecture — one incremental engine + a cadence dial (live ↔ batch) + two-tier (local-cheap-live / global-expensive-deferred) + a hard pre-merge gate. See §9.5.
2Deferred batch Update Subnetwork [cite]Subnetwork membership is stale until someone runs the batch update; dirty/clean/invalid lifecycle is operational overhead.Incremental, event-driven re-derivation of subnetwork membership as edits land.
3Hub-and-spoke branch versioning [cite]Central Default version, reconcile/post, one editor per named version, no peer merge. Doesn’t fit real-time multiplayer.Event-sourced / log-based, distributed merge (per-Trait merge semantics; concurrency boundaries by merge boundary).
4Heavyweight proprietary enterprise stack [cite]4+ licensed components, server-side recompute, serialized validation on Default. High cost & lock-in.SaaS-native, open substrate (Postgres + topology engine + open services); deploy as one coherent product.
5Configuration-time rigidity (fixed tiers, fixed base classes, exactly 3 association types) [cite]Post-deployment changes are constrained; model is closed.Open Entity-Trait-Link composition — relationship semantics are data, not a closed enum.
6Surface fragmentation (Pro vs Web vs Field vs Velocity)Four apps, four capability levels; desktop-first.One adaptive multi-surface UI (Stage/Surface/Sanjaya) — same model, adapting surface.
7Server-side compute for trace/validate/subnetwork [cite]Round-trips and serialization; not interactive at the edit.Derive-on-write / in-process projections for interactive feedback.
8No native AI/agent layerUN is a system of record + analysis tools; reasoning is human-driven in Pro.Sanjaya agent plane + governance-outside-the-prompt + ML-under-LLM over the same ontology.

9.5 Validation as policy, not architecture — supporting live and batch

This section is Lepton’s design position, developed in discussion — not an Esri-sourced finding. It is the direct answer to weakness #1 (and a correction to this doc’s earlier over-dismissal of the dirty/validate model). The dirty-vs-validated distinction is correct and we keep it — especially at India-/US-wide scale, where you want a proposed/confirmed boundary and bounded (not global) recompute. What we reject is Esri’s implementation: a single manual, serialized, whole-Default batch op. The fix is to make validation one incremental mechanism with a cadence dial, not two engines.

The reframe

Esri welds three independent concerns into one “Validate” button. Separate them and both live and batch modes fall out of a single mechanism:

  1. Trigger cadence — when derivation runs.
  2. Scope — over what (the causal slice just edited / a selected extent / an affected subnetwork / all).
  3. Read consistency — what a reader sees (last-validated snapshot vs. live-including-unvalidated).

The staging unit is a change-set / draft, not a spatial polygon

The key refinement over Esri’s dirty-areas: you edit inside a draft (an open change-set = a run of events) that accumulates “dirty” causally, not just spatially. This is Capture → Observe → Resolve (see [[reference-vinxi-os-causality-substrate]]): Capture = events into the draft; Observe = derive/validate; Resolve = promote/merge. “Manual” simply means you decide when Observe fires.

  • Batch/manual = let the draft accumulate; derive + promote at a checkpoint. For bulk import, migration, or a designer building a whole subdivision where the intermediate states are supposed to be invalid (the transformer isn’t wired yet — that’s an unfinished draft, not an error).
  • Live = derive on every committed event (debounced). For surgical edits, field fixes, or “trace right now” — with the illegal-connection diagnostic the instant the edit lands.

Same engine, same code path; live is just the batch loop run eagerly.

The cadence dial (a first-class dial in the Stage/Surface lexicon — see [[project-lepton-adaptive-ui-framework]])

ModeValidation fires…Use it for
Liveevery committed edit (debounced ~ms)single-editor surgical work, field, trace-now
On-idleafter N ms of no editsthe comfortable default — feels live, costs less
Checkpointon explicit checkpointvalidating a designed feature as a unit
Manualonly on explicit “Validate”bulk import, migration, long intentionally-invalid drafts
Pre-mergealways, before promote/mergethe non-negotiable gate — nothing dirty reaches shared truth

The bottom row is what makes the others safe: whatever cadence you pick, validation is forced before a draft merges into the shared/validated graph. A sloppy live session or a giant manual draft can never silently corrupt what others trust.

Two design choices that make this work at nation scale

  1. Reads pick their own consistency — this is what lets modes coexist. A query/trace declares @validated (last confirmed snapshot — what ops dashboards and other editors read) or @working (live, including your own unvalidated edits — what you read while editing). One editor in live mode pours zero dirtiness into the snapshot everyone else sees, so validation cadence becomes a per-draft setting, not a global one.
  2. Tier the validation itself — the answer to “isn’t live ruinously expensive on a large feeder?”:
    • Local / cheap (always live-able): structural rule checks on the causal slice (is this connection legal, does this terminal exist, is containment valid). Bounded to the edit’s neighborhood; ms-scale even on a nation-wide graph.
    • Global / expensive (debounce / checkpoint / manual): subnetwork-wide re-derivation — full membership retrace, load summaries, downstream customer counts. Never fired per-keystroke.

So even “Live” is really live-local + deferred-global. Esri’s Update Subnetwork is the expensive tier — and they make you trigger even the cheap tier by hand. We make the cheap tier live and the expensive tier policy-driven.

Net: one incremental engine + change-sets as the staging unit + a per-draft cadence dial + per-read consistency + two-tier validation. That spans “import 2M features, validate once” through “live squiggles as I edit,” with a hard pre-merge gate so neither mode endangers shared truth. Keep Esri’s staging boundary; kill its serialized-manual-monolithic recompute.

What the focused research confirmed — the staging model is good, the centralization is the weakness [cite]

The follow-up pass substantially vindicates the staging model and this cadence-dial design, and narrows the real critique to two centralization primitives:

  • Validation is already incremental and dirty-bounded — “the validate operation only validates features with dirty areas” [cite], and since ArcGIS Pro 2.5 partial-extent validation clips dirty areas to the validated extent rather than processing the whole area. [cite] So Esri does not re-derive the network on every validate — the staging boundary already buys bounded recompute. ✅ Keep it. (Two exceptions expand to the full dirty area: association dirty areas and update-subnetwork error-feature dirty areas.)
  • Esri themselves recommend automating/scheduling validation at intervals on the continuously-edited Default version, run asynchronously on a dedicated UtilityNetworkTools geoprocessing service — separate from the feature service, with its own configurable timeout (default 2 hours). [cite] That is literally a cadence policy in the wild — confirming our On-idle / Scheduled dial is how real deployments already operate, just bolted on manually rather than designed in.
  • The real bottleneck is confirmed and narrow: validation is single-session on the Default version [cite], and Update Subnetwork takes and holds a shared lock on the Default version for its full duration (under “With Eventing” edit mode), which serializes concurrent operations like reconcile. [cite] This is the serialized-on-Default weakness — and exactly what distributed, log-based, per-region derivation removes.
  • Our two-tier split maps cleanly onto Esri’s own reality: the cheap tier ≈ Validate (rule checks, dirty-bounded, fast) [cite]; the expensive tier ≈ Update Subnetwork (lock-holding, subnetwork-wide, scoped to dirty subnetworks) [cite]. Esri makes you trigger both manually and serializes the expensive one on a single Default; Lepton makes the cheap tier live and partitions/parallelizes the expensive one per region/subnetwork instead of locking one global Default.

Corrected verdict: the dirty → validate → Update-Subnetwork staging model is genuinely well-designed for scale — bounded, async, schedulable, and incremental. Its limits are the centralization primitives (a single Default version, single-session validate, shared locks during subnetwork update), not the staging concept. Lepton keeps the concept and replaces the centralization with distributed, log-based, per-region derivation + merge.

10. Side-by-side: ArcGIS UN vs. Lepton Infrastructure Cloud

DimensionArcGIS Utility NetworkLepton Infrastructure Cloud (target)
Core abstractionFixed-schema geospatial data model [cite]Event-sourced knowledge graph; topology is one Lens, not the whole graph
Relationship modelGeometry + exactly 3 association types (closed) [cite]Entity-Trait-Link (open composition; per-Trait merge semantics)
TopologySeparately stored, materialized; validated incrementally (dirty-bounded) but single-session on Default [cite]Live-derived projection over the append-only log; per-region
Subnetworks/circuitsTrace-derived, persisted; Update Subnetwork is dirty-scoped but holds a shared lock on Default [cite]Incrementally re-derived on write, per-region (no global lock)
ConcurrencyBranch versioning, hub-and-spoke reconcile/post to Default [cite]Distributed, log-based merge; realtime multiplayer
DeploymentArcGIS Enterprise, 4+ licensed components, server-side [cite]SaaS-native, open stack (Postgres + topology engine)
Schema changeAsset groups/types/rules as config; tiers fixed post-deploy [cite]Traits/Links as data — fully open, no migration
UIDesktop-first (Pro); Web/Field/Velocity fragmentedOne adaptive multi-surface UI
AI / reasoningNone native; human-driven in ProNative agent plane (Sanjaya) over the ontology
Maturity✅ Global, proven, deep ecosystem🟡 Greenfield — must earn trust
Tracing/analytics✅ Rich, fast (indexed), configurable [cite]Must match this — non-negotiable parity bar

Strategy in one line: match UN’s domain model and tracing parity (table-stakes), then beat it on liveness (keep the staging boundary, but live-local validation + no central serialization — §9.5), concurrency (distributed per-region merge, no single Default / shared locks), openness (no Enterprise lock-in), surface (one adaptive UI where the browser authors & merges — §5), and intelligence (native agents).

11. FTTx / telecom relevance (for the domain-learning track)

UN’s telecom fit maps directly onto the FTTx primer concepts:

  • Structure network (poles/ducts/conduit/vaults) ≈ the physical containment plant (SmartInventory’s duct/trench/handhole tables).
  • Containment associations ≈ cables-in-duct, fibers-in-cable, splices as contained objects.
  • Terminals / terminal configurations ≈ ports and strand-level connectivity inside splice closures / patch panels — the internal wiring of a device.
  • Connectivity associations ≈ splice/jumper connections between non-coincident features.
  • Subnetworks / controllers ≈ a PON tree / feeder served from an OLT port (source controller), customers as the served set — and a load summary ≈ “homes passed/connected on this PON.”

Esri’s 2026 telecom domain network (circuit management) is strong evidence that fiber can be forced into the connectivity/containment/structural-attachment primitives. The open question (§12) is how cleanly — strand-level splicing is notoriously awkward in models built for electric/water, and this is exactly where Lepton’s open Trait/Link model and our existing SmartInventory splicing knowledge can produce a better fiber model than a primitive set retrofitted from electric utilities.

12. Open questions — status after the focused second pass

A focused second research pass (UI surfaces, validate-at-scale, schema extensibility, versioning conflicts) closed two of the four original questions and partially closed a third. Status:

  1. ✅ CLOSED — scale/operational behavior of validate & subnetwork update. Validation is incremental and dirty-bounded (only features with dirty areas; extent-clipped since Pro 2.5), runs async on a dedicated geoprocessing service (default 2-hour timeout), and Esri recommends scheduling it; Update Subnetwork is scoped to dirty subnetworks. The bottleneck is not the staging model but centralization: single-session validate on Default + a shared lock on Default during subnetwork update. See §9.5 (this materially changed our verdict — the model is good at scale; only the centralization is the weakness). Still unquantified: absolute wall-clock at tens of millions of features — useful but no longer decision-blocking.
  2. 🔶 STILL OPEN — schema/relationship extensibility & strand-level FTTx fit. The pass fetched the 2026 telecom domain network and circuit-management docs but no extensibility claim survived into the verified set, so we still cannot say authoritatively whether the fixed base-class set / three association types accept custom relationship semantics, or how cleanly splices/ports/strands fit. This is now the single highest-value remaining follow-up — it directly informs Lepton’s FTTx model. See §11.
  3. ✅ CLOSED — client-surface capability split. Fully mapped and verified in §5 (capability matrix): trace authoring, association editing, and reconcile/post are desktop-only; web/field are view + light-edit + run-pre-authored-traces; Velocity is a separate real-time product.
  4. 🔶 PARTIAL — branch-versioning conflict mechanics. Confirmed: on reconcile, a version inherits the current topology state and re-creates dirty areas for all edited features; on post, those dirty areas let the topology be re-validated/rebuilt in Default; reconcile/post is desktop-only (§5). Still open: the exact conflict-detection granularity (row vs. attribute vs. geometry) and the resolution UX — no granularity claim survived into the verified set.

(Highest-value next pass: #2 (schema extensibility + FTTx fit), which most directly informs Lepton’s fiber model. Say the word.)

13. Refuted claims — explicitly do NOT repeat these

The verification pass killed four plausible-sounding claims. They are wrong; do not let them leak into Lepton docs or decks:

Refuted claimVerdictCorrect version
”Subnetworks are not stored, only discovered on demand by tracing.”0–3 ✗Membership is computed by trace, then persisted/materialized; refresh is an explicit batch step (Update Subnetwork).
”Associations/dirty-areas are bolt-ons atop a feature-layer foundation.”1–2 ✗They are first-class topology participants, not bolt-ons.
”There are exactly eight basic trace types, run via a Trace geoprocessing tool.”0–3 ✗Do not commit to a fixed count; list trace types as examples.
”UN replaces network-weights with a specific four-part taxonomy (tiers/categories/attributes/terminals) as the config scheme.”0–3 ✗Those objects exist, but that exact “definitive scheme” framing is unreliable.

Also carry two terminology corrections: (a) “network topology” is a validated state, not a rule type — the real rule types are the five in §2.7; (b) the “rules must exist before connection” principle has a documented exception for like-typed coincident edges (auto-connect via system junction).

14. Sources

All primary unless noted; live-fetched and verified during the research pass (2026 “latest” doc line).

Esri primary documentation

Esri developer / enterprise

Focused second pass — UI surfaces, validate-at-scale, versioning (all primary, verified)

Consulted but not yet verified (schema extensibility / FTTx — open Q #2)

Practitioner / competitor / community (secondary — corroboration & contrarian)

Generated from two verified deep-research passes. Pass 1: 26 sources, 125 claims → 25 verified (21 confirmed / 4 refuted) — data model, versioning, services, deployment. Pass 2: 22 sources, 110 claims → 25 verified (25 confirmed / 0 refuted) — UI surfaces, validate-at-scale, branch-versioning conflicts. The data-model, UI-surface, validate-scale, and versioning sections are citation-grounded; schema/relationship extensibility and strand-level FTTx fit remain the one open question (§12 #2).