# Asset Management — Research & Planning

- **Date:** 2026-09-02
- **Status:** Research — no build decisions taken
- **Status Date:** 2026-09-02
- **Phases:** TBD (a build plan is written only once the recommendations in Part 5 are chosen)
- **Phases Complete:** 0
- **Notes:** Research and options only. Nothing here is committed to, no code or migration is
  implied, and the numbered lists in Parts 5–7 exist to be argued with by number.

## How to use this document

- **Parts 1–2** are market research: what asset management software actually does, and how much
  of it generalises beyond fibre into adjacent utilities.
- **Part 3** is an honest inventory of what GeoLynx already has that overlaps. It is the most
  important section, because a lot of an asset register already exists here under another name.
- **Part 4** is the positioning argument — what a GeoLynx asset module should be, and what it
  should deliberately refuse to be.
- **Part 5** is the recommendation list, flat-numbered 1–43 so it can be reviewed by number.
- **Parts 6–7** are the decisions that need settling and the questions only the business can answer.

`docs/2026-07-18-asset-management-module.md` is the earlier requirements-gathering note. It is
useful background and is not superseded, but nothing here is constrained by it — several of its
assumptions (notably that the module is a clone of the projects module, and that the register
starts empty) are challenged below.

---

## Part 1 — What "asset management" means in the market

### 1.1 Three different products share the name

Searching for "asset management software" returns three largely unrelated product categories.
Deciding which one is being built is the single most consequential choice here, because they
have different core objects, different buyers and different failure modes.

| Category | Core object | The question it answers | Typical products |
|---|---|---|---|
| **EAM / CMMS** — enterprise asset management, computerised maintenance management | A maintainable *thing* with a failure history | "What do we own, what condition is it in, when is it next due maintenance, and what did it cost us?" | IBM Maximo, SAP EAM, Limble, Tractian |
| **ITAM** — IT / equipment asset tracking | A *serialised item* with a custodian | "Who has it, where is it, is it under warranty, is it calibrated?" | Asset Panda, GigaTrak, MapYourTag |
| **Network inventory / OSS-GIS** | A *located, connected* network element | "What exists where, what connects to what, what capacity is spare, and which premises can we serve?" | 3-GIS, IQGeo, VETRO FiberMap, Esri Utility Network, OZMap |

GeoLynx sits squarely in the third category, with a useful slice of the first. It has almost no
business in the second beyond a small equipment-custody use case (see item 36).

This matters because the third category is *not* a variation of the first. An EAM asks "is this
pump healthy"; a network inventory asks "if I cut here, who goes dark, and is there a spare duct
I can use instead". The data model that answers the second question is a connected, spatial,
capacity-aware one — which is exactly where GeoLynx's existing strengths are.

### 1.2 The universal core — present in all three categories

Every product in every category has these. They are table stakes, not differentiators:

- **Asset register** — a unique ID per asset plus make/model/serial, classification, location,
  ownership, install date, cost, current status and condition. Vendors are unanimous that this is
  the foundation and that everything else is worthless without it.
- **Classification / taxonomy** — a controlled list of asset types, with type-specific attributes.
- **Hierarchy** — parent/child structure, used for two things: rolling costs and work up to a
  parent, and understanding failure impact downward.
- **Lifecycle status** — planned → installed → commissioned/in service → faulty → decommissioned
  → disposed, with the dates of each transition.
- **History and audit** — who changed what, when. GeoLynx already does this better than most.
- **Documents and photos** — as-builts, warranties, test results, site photos.
- **Work management** — requests → work orders → planning → scheduling → execution → closeout.
- **Planned/preventive maintenance and inspection regimes** — recurring schedules by time or
  usage, generating work automatically.
- **Spares / MRO materials** — parts linked to assets, reorder points, consumption against work.
- **Reliability and performance analytics** — failure records, mean time between failures,
  maintenance spend per asset, replace-or-repair decisions.
- **Financials** — acquisition cost, depreciation schedule, warranty expiry, replacement cost.
- **Compliance reporting** — inspection due/overdue, certification renewal, statutory returns.
  ISO 55000 is the umbrella standard the serious end of the market aligns to.

### 1.3 What network and utility inventory adds on top

This is where the category diverges from generic EAM, and where a fibre/utility product lives:

- **Outside plant and inside plant inventory** — ducts, sub-ducts, chambers/vaults, poles,
  cabinets, pedestals, closures, cables, splitters, patch panels, ports, and — for fibre —
  individual strands.
- **Connectivity and tracing** — a-end/b-end relationships, splice records, and the ability to
  trace a path end to end. Vendors treat strand-level tracing as the headline capability.
- **Capacity and occupancy** — how full is this duct, how many sub-ducts are in it, how loaded is
  this pole, how many splitter ports are free, how many spare fibres are in this cable. The
  recurring industry theme is that operators model fibre well and *duct badly*, and duct space is
  the constrained resource that decides whether the next build costs £5k or £50k. Spare capacity
  should be recorded explicitly, not inferred from absence.
- **Serviceability** — which premises can be served from this asset, and at what cost.
- **Planned vs as-built** — design intent produced before the build, reconciled to what was
  actually put in the ground after it. Vendors are blunt that the gap between as-planned and
  as-built is the primary data-quality problem in the sector, and that carrying one record
  through plan → construct → as-built → operate is the fix.
- **Third-party infrastructure** — assets attached to or inside somebody else's plant, with the
  rental and record-keeping that implies (in the UK, Openreach PIA).
- **Outage and impact analysis** — given a failed asset, which services and customers are affected.

### 1.4 What GIS specifically contributes — three kinds of association

The Esri Utility Network model is the most rigorous published treatment of how spatial assets
relate, and it names three association types that are worth stealing wholesale as vocabulary:

1. **Containment** — content inside a container. A splice closure inside a chamber; a sub-duct
   inside a duct; a card inside a cabinet. Only containers may contain.
2. **Structural attachment** — a device physically fixed to a structure. A closure on a pole; a
   cabinet on a plinth; a lamp on a column.
3. **Connectivity** — two things joined that are *not* geometrically coincident. This is what lets
   a cable connect two closures without their coordinates matching.

The important consequence: **an asset does not need its own coordinates to be located.** If it is
contained by or attached to something that has coordinates, it is locatable, and the model should
say so explicitly rather than copying the parent's geometry.

Two further spatial concepts matter for utilities:

- **Linear assets and linear referencing.** A duct or a pipe is not a point with a length field —
  it is a route along which things change. Linear referencing (measure/offset along the route) and
  dynamic segmentation let you say "metres 0–900 of this duct are ours, 900–1200 are leased, and
  there is a blockage at 640" without splitting the asset into three assets. Every serious utility
  EAM has this; it is also the single most expensive thing on this page to build.
- **Location confidence.** UK utility surveying has a formal standard for "how sure are we where
  this actually is": **PAS 128**, with quality levels QL-D (desktop records only) through QL-A
  (physically verified by excavation), and sub-levels within Type B detection surveys. Recording a
  confidence level per asset is cheap, and it is the honest answer to a register assembled from
  mixed-quality sources.

### 1.5 Field operations

The register is only as good as the field's ability to correct it. Common capabilities:

- **Mobile inspection and survey** — GPS-stamped, photo-attached, form-driven, and **offline-first**,
  because chambers are in places with no signal.
- **Asset tagging** — barcode, QR or NFC labels on the physical asset, scanned to open its record.
  This is the cheapest, highest-leverage data-quality tool in the category.
- **Custody and checkout** — for movable equipment (splicers, OTDRs, test sets): who has it, when
  it is due back, and whether it is in calibration. Some products lock out checkout of an item
  that is overdue calibration.
- **Redlining** — field marks a correction on the map, office reviews and accepts it. This is an
  approval workflow, and GeoLynx already has a good one.

### 1.6 UK regulatory and commercial drivers

These are the reasons a UK operator would *buy* rather than *want* this module:

- **NUAR — the National Underground Asset Register.** Underpinned by 2025 legislation, asset owners
  (public and private) will be obliged to supply data on their underground apparatus to a national
  platform and keep it current, in a prescribed form. Reported proposals include a **28-day minimum
  refresh for apparatus that risks injury on a strike** and quarterly for the rest, with an initial
  upload window of 12 months that, per commentary, is unlikely to start before spring 2026 and
  unlikely to be enforced before spring 2027. **Treat every date here as needing verification
  before it is relied on** — this is fast-moving and the commentary sources disagree. The strategic
  point stands regardless: every buried-asset owner in the UK is about to need a maintained,
  exportable, positionally-honest asset register. That is a module, and it has a deadline.
- **PIA and infrastructure sharing.** Renting Openreach duct and pole space requires knowing
  exactly what you have attached where, both to be billed correctly and to challenge being billed
  incorrectly.
- **Investor and lender scrutiny.** The altnet market moved from being valued on coverage promises
  to being judged on revenue per premises passed, and consolidation has made asset verification a
  live diligence exercise. A defensible, auditable asset register with build dates and evidence is
  a due-diligence asset in its own right. (Reported transaction metrics — e.g. an order of
  ~£500/home passed — come from market commentary, not audited filings; directional only.)
- **Land rights.** An asset on someone else's land needs a wayleave, and a wayleave without a list
  of the apparatus it covers is hard to enforce or renew. GeoLynx is unusual in already having the
  wayleave side of this.
- **Street works** (NRSWA permits, reinstatement) sits adjacent — it is work management over
  assets rather than asset management, and is not recommended for this module.

### 1.7 How these implementations fail

Consistent across every source, and worth designing against:

- **Data quality, not software, is the top cause of failure.** Registers arrive from spreadsheets
  with four names for the same asset class.
- **Naming and ID conventions.** "CH-001", "CH 001" and "Chamber 1" become three assets with
  fragmented history. A systematic identifier scheme decided *before* first import is the single
  highest-value hour of work in the whole project. Sources put the point where random naming
  becomes a crisis at around 500 assets.
- **No physical verification.** A register that is never reconciled to what is actually in the
  ground degrades quietly and then gets distrusted all at once.
- **Over-modelling.** Building strand-level connectivity, depreciation and PM scheduling before
  anyone has entered a hundred chambers is the classic way to ship nothing.
- **Two registers.** A design system and an asset system that both claim to be the truth, kept in
  sync by hand, diverge within months. **This is the trap GeoLynx is closest to walking into** —
  see Part 3.

---

## Part 2 — Fibre-adjacent markets and utilities

The brief is explicitly not fibre-only. The good news from the research is that the *structure* of
the problem is near-identical across these sectors; what varies is the taxonomy, the units of
capacity and the statutory regime.

| Sector | Typical asset classes | Same as fibre | Different / extra |
|---|---|---|---|
| **Water / wastewater** | Mains, service pipes, valves, hydrants, meters, pumping stations, manholes, reservoirs | Linear buried network, chambers, containment, condition, NUAR | Pressure zones, leakage, flow/quality sampling, DMA hierarchy, statutory water-quality reporting |
| **Gas** | Mains, services, valves, governors, meters | As above, with the highest strike-risk profile | Pressure tiers, purging/commissioning records, very strict statutory safety regimes |
| **Electricity (DNO/IDNO, private networks)** | Cables, overhead lines, poles, substations, transformers, switchgear, pillars, meters | Poles and attachments, containment, connectivity, capacity | Voltage tiers, phasing, protection settings, load/capacity in kVA, energisation records, asset health scoring |
| **Street lighting** | Columns, lanterns, feeder pillars, control gear | Point assets on a linear route, inspection regimes | Structural testing of columns, energy inventory/unmetered supply records |
| **EV charging** | Chargepoints, connectors, cabinets, grid connections | Point assets, capacity, uptime, containment in a site hierarchy | Connector-level uptime/availability reporting, OCPP telemetry, tariff/site-host relationships |
| **Smart city / CCTV / sensors** | Cameras, sensors, comms cabinets, backhaul | Attachment to columns and poles, containment | Device/IoT connectivity, data-protection considerations |
| **Rail / highways telecoms** | Trackside/roadside cabinets, ducts, cables, masts | Linear referencing is *native* here (chainage/mileage) | Possession/access windows, safety accreditation |
| **District heating** | Pipework, plant rooms, heat interface units, meters | Linear buried network, containment | Flow/return pairing, heat metering |

**What this implies for the build.** Roughly 80% of the model generalises if — and only if — it is
**type-driven rather than fibre-hardcoded**. Concretely:

- No fibre nouns in table or column names. An asset has a *type*; "closure", "valve" and "lantern"
  are rows in a taxonomy, not columns in a schema.
- Capacity must be expressed as a **unit-bearing quantity** (ways, sub-ducts, fibres, ports, kVA,
  mm bore) rather than a fibre-specific column set.
- Connectivity semantics must be generic (a-end/b-end plus containment/attachment), because a
  water main and a fibre cable are the same shape of problem.
- Inspection regimes must be configurable, because pole testing, column testing and hydrant flow
  testing are the same feature with different forms.

The three UK-wide drivers — **NUAR, PAS 128 confidence levels, and land rights/wayleaves** — apply
to *every* row of that table. That is a strong argument for GeoLynx building the generic version
first and the fibre specifics second, rather than the reverse.

---

## Part 3 — What GeoLynx already has that overlaps

This section is the reason not to start from a blank sheet.

| Existing capability | Where | Relevance to assets |
|---|---|---|
| **A planned network model** | `prospector.network_points`, `network_structures`, `network_cables`, `network_duct`, `network_subduct`, `pia_blockages` | **The big one.** Already carries type, name, status, `project_id`, geometry, `parent_point_id` / `parent_structure_id` (containment), `a_end`/`b_end` (connectivity), `pianoi_ref` (PIA reference), `customer_*_id`, fibre allocation text and SLD coordinates. Written by `map_feature_save.php`, `network_topo_save.php`, `project_fibre_allocation.php`. This is a network inventory in all but name — a *planned* one, scoped to a project. |
| **Third-party infrastructure** | `strategy.openreach_*` foreign tables — chamber, pole, spans, span coupler, imported duct/structure | The PIA attachment target. Third-party, bulk-refreshed, not ours to own. |
| **Premises and addressing** | `basedata.abp`, `projects.project_premises`, `projects.vw_premise_claimants` | Serviceability: which premises an asset could serve, and the existing pattern for materialising a spatial relationship instead of resolving it live on every read. |
| **Land rights** | `wayleave.wayleave_coverage`, `vw_wayleave_pending`, the approval model | The closest existing analogue to an asset↔land relationship, and a proven approval workflow (proposed → approved → tombstoned, with derived pending). |
| **Counterparties** | `accounts` | Landowner, supplier, contractor, maintainer, capacity customer — all account relationships. |
| **Commercial pipeline** | `opportunity`, `opportunity_project_link`, distance analysis, Land Registry search | "Is there existing infrastructure near this opportunity" is an asset question. |
| **Map platform** | `public.map_layers` (data-driven: `database_schema` / `database_table` / style / tooltip), OpenLayers, `pointStyleManager` | A new asset layer is configuration plus a view, not a new mapping stack. |
| **Field meta system** | `*_fields` meta tables, `get_update_form.php`, shared `renderMetaForm()` / `populateMetaForm()` in `main.js` | Static + dynamic fields per module, admin-configurable. The opportunity module is the shared-path reference implementation — a new module should use it, not copy `project_edit_v2.js`. |
| **Audit, permissions, lifecycle** | Journal + history tables, two-tier RBAC, pseudo-modules (`wayleaves_approve`, `projects_approve`), `docs/module-delete-restore-pattern.md`, admin status management | All directly reusable. Delete/restore and approval both have written patterns to follow. |
| **Work management** | `docs/task_system_plan.md` — workflows, dependencies, SLAs, Cytoscape DAG | **Designed, not built.** No `tasks.*` tables in the baseline and no endpoints. |

Two consequences follow, and they shape everything in Part 5.

**(a) A large part of the asset register already exists as *planned* data.** The most valuable
thing an asset module can do here is not "start a new register" — it is **carry the planned
network through construction into an as-built register**, which is exactly what the market says is
the hardest and most valuable transition. Building a parallel asset table that people re-key
network data into would create the two-registers failure from §1.7 on day one.

**(b) Work management belongs to the task system, not to the asset module.** Inspections, repairs
and PM schedules are workflows with assignees, SLAs and dependencies — the task system plan
already describes that engine. If assets ship a private work-order implementation, there will be
two of them. The asset module should own *what is due and why* (the regime and the asset's
condition) and hand *who does it and by when* to tasks.

---

## Part 4 — The GeoLynx flavour

Five principles that follow from the strengths above:

1. **Every asset is locatable, always.** Own geometry, or contained by / attached to something with
   geometry. No asset ever sits in a table with no way to put it on the map. Inheritance is
   modelled as a relationship, not by copying coordinates — except for attachment to third-party
   plant, where the coordinates *are* snapshotted, because Openreach data is refreshed in bulk and
   can move or vanish underneath us.
2. **One hierarchy that a human can explain.** The projects module has already learned this lesson
   the hard way: name relationships by *where a thing is counted*, not by the viewer's role in the
   tree. Containment depth should be shallow and rule-checked by type (a closure goes in a chamber;
   a chamber does not go in a closure).
3. **Links are first-class, and mostly derived.** GeoLynx's real differentiator is that projects,
   wayleaves, premises, accounts and opportunities are all in one spatial database. The asset
   module should *derive* relationships spatially wherever it can — which wayleave covers this
   pole, which premises this cabinet could serve, which project built this duct — rather than
   asking a user to maintain them by hand.
4. **The register is the continuation of the plan.** Plan → build → as-built → operate, on one
   record, with the status telling you which stage it is at.
5. **Type-driven, never fibre-driven** — for the adjacent-market reasons in Part 2.

**Explicit anti-goals** (things a market survey will tempt us into, and we should decline):

- Not a maintenance scheduling engine — that is the task system.
- Not a circuit/service inventory. Strand-level tracing and light-path management is a large
  product in its own right, and `prospector.network_cables.fibre_allocation` already does a
  simplified version.
- Not an accounting fixed-asset register. Depreciation belongs in finance software; carry cost and
  dates so finance can be fed, and stop there.
- Not real-time monitoring/SCADA/OCPP telemetry. Record condition observations, not live streams.

---

## Part 5 — Recommended features, for review

Flat-numbered so items can be accepted, deferred or rejected individually. Each carries a rough
size (S/M/L) and its main dependency. Nothing here is committed to.

### Group A — Foundation (the register itself)

1. **Asset register with a single asset entity.** One `assets` table, every asset type in it,
   distinguished by an asset-type reference rather than per-type tables. *Rationale: keeps the
   field-meta, journal, RBAC, delete/restore and map patterns intact; per-type tables would
   multiply all five.* (M)
2. **Asset type taxonomy, admin-managed.** A hierarchical, admin-editable list of types
   (Structure → Chamber → Jointing chamber), each type carrying its geometry kind, its allowed
   containers and its default capacity unit. This is the piece that makes the module work for
   water and street lighting as well as fibre. (M — depends on 1)
3. **Static + dynamic fields via the shared meta path.** Reuse `renderMetaForm()` /
   `populateMetaForm()` rather than copying an editor. Also the moment to add the module to
   `fieldMetaModuleConfig()` and `dashboardModuleMap()` together. (M)
4. **Type-scoped dynamic fields.** Extend the field meta system so a dynamic field can be limited
   to one or more asset types (null = all types), so a pole gets pole attributes and a valve gets
   valve attributes without a 200-field form. *This is the one genuine extension to the existing
   field system that assets require, and it would benefit every other module too.* (M — the main
   new mechanism in this list)
5. **Lifecycle status, admin-managed.** Reuse the existing status management (styles, ordering,
   retirement, default status). Suggested default set: Planned, Approved for build, Under
   construction, As-built, In service, Faulty, Decommissioned, Removed. (S — pattern exists)
6. **Asset identifier scheme.** A system-generated, human-readable, unique asset reference
   (type prefix + sequence, with a per-deployment format), plus separate fields for the
   *customer's* reference and any *third-party* reference. Deliberately called out as its own item
   because §1.7 says getting this wrong is the top cause of register failure. (S — decide before
   any import)
7. **Journal, history and soft delete.** The existing patterns, unchanged, including the
   delete/restore rules from `docs/module-delete-restore-pattern.md`. (S — pattern exists)
8. **Asset list page with the standard filters, plus attachments/photos.** The Tabulator list, the
   shared file-upload JS (and therefore the `#uploadModal` markup), cover image. (M)

### Group B — Spatial and hierarchy

9. **Geometry on the asset — point, line or polygon.** One geometry column, kind constrained by
   asset type. Chambers and poles are points, ducts and cables are lines, compounds and sites are
   polygons. (M)
10. **Containment and attachment as explicit relationships.** Borrowing the utility-network
    vocabulary: an asset is *contained by* another asset, or *attached to* another asset, and
    either way inherits its location if it has none of its own. Type rules decide what may contain
    what. (M — the conceptual core of the module)
11. **Attachment to third-party plant, with a coordinate snapshot.** Attach an asset to an
    Openreach pole/chamber (or another operator's structure), storing the third-party reference
    *and* the coordinates as at attach time, so the asset survives a bulk refresh of the source
    data. Needs a check of which Openreach identifier is actually stable across refreshes. (M)
12. **Asset map layer(s), registered in `map_layers`.** Assets on the main map and in the project
    editor, styled by type and status, off by default, following the project-premises layer
    precedent. Style keys must exist in `pointStyleManager` or the editor map dies. (M)
13. **Draw and edit asset geometry on the map.** Place a point, draw a duct run, snap to existing
    assets and to Openreach structures. (L — the largest single UI item here)
14. **Lineage views that read correctly from any level.** Containment ancestors/descendants,
    named by where a thing is counted, following the hard-won project-premises naming lesson. (M)

### Group C — Cross-module links (the GeoLynx differentiator)

15. **Asset ↔ project.** Which project built it, and which projects have since worked on it.
    Derivable initially from the planned-network `project_id`. (S)
16. **Asset ↔ wayleave, derived spatially.** Which wayleave gives us the right to have this asset
    where it is — and, inverted, *which of our assets sit on land with no wayleave*. That inverse
    query is a compliance report nobody in this market can currently run easily, and GeoLynx is
    one of very few systems holding both halves of the data. (M — strong candidate for the
    module's headline feature)
17. **Asset ↔ premises/UPRN served.** Which premises a cabinet, closure or splitter could serve,
    materialised the way `project_premises` is rather than resolved live. Feeds serviceability. (L)
18. **Asset ↔ account.** Owner, landowner, maintainer, supplier, and capacity customer — as typed
    relationships rather than one field. (S)
19. **Asset ↔ opportunity: "what have we already got near here".** Surface existing own assets when
    scoring an opportunity, alongside the existing PIA/Openreach reuse analysis. Reusing your own
    duct is cheaper than renting somebody else's. (M — reuses the opportunity proximity machinery)
20. **Own assets as a distance-analysis dataset.** Add the asset register to the strategic distance
    analysis tool so "distance to our nearest chamber" becomes a scoring input. (S — the tool is
    already dataset-driven)
21. **Asset ↔ stocklist.** Lower priority; include only if there is a real workflow behind it. (S)

### Group D — Field operations and data quality

22. **Location confidence per asset (PAS 128 quality level).** A small controlled list (QL-A…QL-D,
    plus the Type B sub-levels if wanted) recorded per asset, surfaced on the map and reportable.
    Cheap, and it is the honest way to hold a register built from mixed-quality sources. (S —
    best value-per-hour item in this list)
23. **Source and evidence per asset.** Where this record came from: as-built survey, design,
    imported spreadsheet, third-party data — with the attachment that proves it. (S)
24. **Condition observations.** A dated, user-attributed condition record with a configurable
    grading scale and photos. Note: *observations*, not a maintenance engine. (M)
25. **Inspection regimes.** Per asset type: an inspection kind and a frequency; the module reports
    what is due and overdue. The *doing* of it is a task once the task system exists. (M — depends
    on 24; couples to the task system)
26. **QR / barcode asset tagging.** A printable tag per asset whose scan opens that asset's record.
    Small build, disproportionate effect on field data quality. (S/M)

### Group E — Commercial and regulatory

27. **NUAR-shaped export.** A maintained, exportable extract of buried assets with geometry,
    type, owner and confidence level, in whatever the prescribed schema turns out to be. Requires
    tracking the specification; the export itself is small if items 1, 9 and 22 exist. **Potentially
    the strongest commercial reason to build this module at all**, and it applies to every sector
    in Part 2. (M — after the spec firms up)
28. **Ownership and tenure per asset.** Owned / leased-in (PIA) / third-party / shared, with the
    counterparty account and the agreement reference. Drives both what we pay and what we may
    lease out. (S)
29. **Capacity and occupancy, generically.** Total / used / spare, with a unit taken from the asset
    type: ways in a duct, sub-ducts in a way, fibres in a cable, ports on a splitter, kVA on a
    transformer. Spare capacity recorded explicitly rather than inferred. (M — deliberately shallow;
    strand-level modelling is out of scope)
30. **Asset register reporting pack.** Counts and length by type, status and area; build dates;
    evidence coverage. The thing you hand a lender, an insurer or a diligence process. (S — after 1)
31. **Rental/cost tracking against third-party attachments.** What we pay whom for the plant we
    are attached to or inside. (S — only if PIA billing reconciliation is a real pain point)

### Group F — Later, or only if wanted

32. **As-built promotion from the planned network.** Promote `prospector.network_*` features to
    asset records when a project completes, keeping the link back to the planned feature.
    *Listed here rather than in Group A only because it depends on decision D6 in Part 6 — if that
    decision goes the other way, this becomes the foundation instead of an enhancement.* (L)
33. **Redline / field-correction approval flow.** Field proposes a change, office approves, using
    the wayleave approval model as the pattern. (M)
34. **Linear referencing on linear assets.** Positions along a duct or pipe — blockages, joints,
    ownership changes — without splitting the asset. Powerful and expensive; only worth it once
    linear assets are actually being maintained. (L)
35. **Offline mobile capture.** The genuinely useful field capability, and the biggest departure
    from the current architecture (no build system, no app). Would need a deliberate technical
    decision. (L)
36. **Movable equipment custody and calibration.** Splicers, OTDRs, test sets: who has it, due
    back, calibration expiry. A different shape from network assets — a separate asset class, not a
    separate module. (M — only if the business actually loses track of kit)
37. **Failure and reliability analytics.** Failures per type, MTBF, repeat-offender assets. Needs a
    year of data before it says anything. (M)
38. **Spares/materials.** Explicitly flagged as a possible overlap with the stocklists module's
    name but not its meaning; probably a genuinely new thing if wanted at all. (M)

### Group G — Recommended *not* to build here

39. **A work-order engine.** Belongs to the task system. Building it twice is the main structural
    risk in this module.
40. **Depreciation and financial asset accounting.** Carry cost and dates; let finance software do
    the rest.
41. **Strand-level connectivity and light-path tracing.** A product of its own; the planned-network
    fibre allocation already covers the practical need.
42. **Real-time telemetry / SCADA / OCPP.** Record observations, not streams.
43. **Street works permitting (NRSWA).** Work management over assets, not asset management.

---

## Part 6 — Design decisions to settle, with a recommendation

These are the choices that a migration would bake in permanently. Each has a recommendation rather
than being left open.

**D1 — Schema name.** *Recommend `assets`.* Consistent with `projects` / `accounts` / `stocklists`.
The empty `inventory` schema in the baseline carries no data and a misleading name (inventory means
spares in this market). Cost of being wrong: a rename migration, cheap now, painful later.

**D2 — One asset entity or per-type tables.** *Recommend one entity plus a type taxonomy* (items
1–2). Per-type tables multiply every pattern in the codebase by the number of types and make
cross-type spatial queries ugly.

**D3 — How type-specific attributes are handled.** *Recommend extending the field meta system with a
type scope* (item 4) rather than either a giant flat form or per-type tables. This is a real change
to a shared system and should be designed on its own, since every module could use it.

**D4 — Geometry.** *Recommend one untyped geometry column* (matching `projects.projects.geom`), with
the permitted kind enforced per asset type. Keeps one map layer path and one editor.

**D5 — How location inheritance is stored.** *Recommend storing the relationship, not the coordinates*
— containment and attachment as explicit links, location resolved in a view. **Exception:**
attachment to third-party plant snapshots the coordinates, because the source data is refreshed in
bulk and can move or disappear.

**D6 — Relationship to the planned network (`prospector.network_*`).** The most consequential
decision in this document, and the one to make first. Three options:

- **(a) Separate register, linked.** Assets are new records that may reference a planned feature.
  Simplest to build; risks the two-registers failure.
- **(b) Promotion.** Planned features are promoted into asset records at as-built, keeping a link
  back. One truth per stage, an explicit handover point, moderate build.
- **(c) Unification.** The asset register *is* the network model, with status distinguishing planned
  from as-built, and `prospector.network_*` migrated into it. Cleanest end state, largest and most
  disruptive build, touches `map_feature_save.php`, `network_topo_save.php`,
  `project_fibre_allocation.php`, `opportunity_manage.php` and the map layers.

*Recommend (b), designed so that (c) remains reachable* — i.e. do not add anything to the asset model
that would make later unification impossible. **This decision should be taken before any other work
starts**, because it determines whether item 32 is an enhancement or the foundation.

**D7 — Status model.** *Recommend the standard admin-managed status pattern* with a default set
spanning plan → as-built → in service → decommissioned, so one record covers the lifecycle.

**D8 — Ownership/tenure vs the asset record.** *Recommend tenure as a field on the asset* (owned /
leased-in / third-party / shared) with counterparty and agreement references, rather than separate
tables per tenure kind.

**D9 — Capacity modelling depth.** *Recommend the shallow generic version* (item 29): a total, a
used and a unit, derived where it can be. Explicitly reject strand-level modelling in v1.

**D10 — Asset identifier format.** *Recommend a system-generated reference with a configurable
per-deployment format*, plus separate customer and third-party reference fields. Decide the format
before the first import, not after.

---

## Part 7 — Questions only the business can answer

1. **Who is the first customer for this, and in which sector?** A fibre altnet, a utility, or
   GeoLynx's own operation? It changes the default taxonomy and the priority of Group E.
2. **Is NUAR compliance a selling point you want to lead with?** If yes, items 22 and 27 move to the
   front and the taxonomy needs to be NUAR-shaped from the start.
3. **Does an asset register already exist to import** — spreadsheets, contractor as-builts, a legacy
   GIS? Its shape is the strongest constraint on D10 and the taxonomy, and its size decides whether
   bulk import tooling is a v1 item.
4. **Who maintains the register day to day** — office staff from as-builts, or field staff on site?
   The answer decides how much of Group D is really optional.
5. **Is the pain "we don't know what we own" or "we can't prove what we own"?** The first prioritises
   capture and hierarchy; the second prioritises evidence, confidence levels and reporting.
6. **Do you rent out capacity or space to anyone**, now or planned? That promotes items 28, 29 and 31.
7. **How deep does containment actually go in practice?** Two levels or five? It decides how much
   hierarchy machinery is justified.
8. **Is the task system going to be built?** If not, items 24–25 need rethinking, because the asset
   module should not grow a work-order engine to compensate.

---

## Suggested sequencing (indicative only, not a plan)

Once the recommendations are chosen, the natural order is:

1. Settle **D6** and **D10**, and the first customer/sector question. Everything else depends on them.
2. Register foundation — items 1, 2, 3, 5, 6, 7, 8.
3. Spatial — items 9, 10, 12, plus 22 and 23 while the model is still soft.
4. Links — items 15, 16, 18, then 19/20.
5. Everything else by whatever the answers in Part 7 make urgent.

---

## Sources

Market and product research, September 2026:

- [3-GIS — telecom asset & inventory management](https://www.3-gis.com/telecom/telecom-asset-inventory-management) and [network management lifecycle](https://www.3-gis.com/en/network-management-lifecycle)
- [VETRO FiberMap — network inventory management](https://vetrofibermap.com/network-inventory-management-software/)
- [IQGeo — Network Manager Telecom](https://www.iqgeo.com/products/network-manager-telecom) and [Inspection & Survey](https://www.iqgeo.com/products/inspection-and-survey)
- [3-GIS — making the most of duct space](https://www.3-gis.com/blog/making-the-most-of-duct-space-challenges-and-opportunities)
- [Esri — Associations (ArcGIS Pro documentation)](https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/associations.htm) and [connectivity and associations](https://doc.esri.com/en/arcgis-pro/latest/help/data/utility-network/about-connectivity-and-associations.html)
- [SSP Innovations — editing with associations](https://sspinnovations.com/blog/esri-utility-network-editing-associations-connectivity-attachments-containment/)
- [Umbrex — core EAM modules and capabilities](https://umbrex.com/resources/enterprise-asset-management-system-playbook/core-eam-modules-and-capabilities/)
- [TechTarget — what is enterprise asset management](https://www.techtarget.com/searcherp/definition/enterprise-asset-management-EAM)
- [eWorkOrders — CMMS asset management](https://eworkorders.com/asset-management/)
- [Dynaway — pitfalls of a poorly set up asset register](https://www.dynaway.com/blog/asset-register) and [AssetCues — asset tag numbering format](https://www.assetcues.com/blog/asset-tag-numbering-format/)
- [HAUC(UK) — National Underground Asset Register](https://www.hauc-uk.org.uk/news/national-underground-asset-register-nuar) and [Travers Smith — what NUAR means for energy infrastructure](https://www.traverssmith.com/knowledge/knowledge-container/the-new-national-underground-asset-register-what-does-it-mean-for-the-energy-infrastructure-sector/)
- [Geospatial Commission blog — a comprehensive NUAR integrated into the existing ecosystem](https://gdsgeospatial.blog.gov.uk/2026/01/28/towards-a-comprehensive-national-underground-asset-register-integrated-into-the-existing-ecosystem)
- [LSBUD — PAS 128 specification overview](https://lsbud.co.uk/pas128-a-specification-for-underground-utility-detection-verification-and-location/) and [CICES — PAS 128 client specification guide](https://cices.org/media/rbydmvnu/pas128-client-specification-guide-sep-22-final.pdf)
- [IQGeo — how UK altnets can optimize fibre rollout with an integrated PIA strategy](https://www.iqgeo.com/blog/how-uk-altnets-can-optimize-fiber-rollout-with-an-integrated-pia-strategy) and [Coreline Fibre — PIA explained](https://www.corelinefibre.co.uk/blog/pia-explained)
- [Bratby Law — UK altnet consolidation 2026](https://bratby.law/uk-altnet-consolidation-fibre-ma-wave-2026/) and [Infrastructure Investor — buying a distressed altnet](http://theinfrastructureinvestor.com/ma-in-action-distressed.html)
- [Prometheus Group — linear asset management](https://www.prometheusgroup.com/learning-center/linear-asset-management) and [IBM Maximo — linear assets](https://www.ibm.com/docs/en/masv-and-l/maximo-manage/cd?topic=administering-linear-assets)
- [KloudGin — linear vs vertical assets in utility operations](https://kloudgin.com/understanding-the-fundamental-divide-linear-vs-vertical-assets-in-utility-and-public-sector-operations/)
- [IFS — what is utility asset management](https://www.ifs.com/en/glossary/utility-asset-management) and [Bynry — asset management software for water utilities](https://www.bynry.com/blog/asset-management-software-water-utilities)
- [asecaddesign — construction drawings vs as-built drawings in telecom](https://asecaddesign.com/blogs/the-difference-between-construction-drawings-and-as-built-drawings-in-telecom-projects/)
- [AssetCues — tool and equipment barcode tracking](https://www.assetcues.com/blog/tool-tracking-barcode-system/) and [Clappia — asset tagging with barcode and QR labels](https://www.clappia.com/hardware/asset-tagging-qr-barcode-printing)
- [Dhyan — StreetMan smart street assets](https://www.dhyan.com/solutions/smart-street-assets-central-management-software/) and [Sitetracker — EV charging](https://www.sitetracker.com/industries/ev-charging/)