Map data coverage

It is a binary, not a maturity curve

The expectation was a gradient: long-held operating companies with deep map libraries, recent acquisitions still building one. That is not what the data shows. 5 of 32 opcos have a Map or Snow Map attachment type configured in Aspire at all. The other 27 return zero not because uploads are sparse but because the attachment type does not exist in their Aspire configuration. There is nothing to upload into.

That changes the shape of the work entirely. A gradient would call for encouragement and training. A binary calls for a configuration change in 27 Aspire tenants before any map-dependent feature can be built for them — and that is a ServiceTitan-side task, not something a Heartland process improvement reaches.

Nor is this legacy data being wound down. All five active opcos uploaded within the week before the survey, and Signature's library reaches back to 4 January 2018. Where maps are used they are used continuously: eight years of operational history, 14,449 attachments at Signature alone.

Every region has at least one active opco, so this is not a regional pattern — it tracks individual Aspire configurations, not geography or management line.

Two conventions, inconsistently applied

Among the five that do hold maps, the typing is not consistent either. Signature is the only opco that distinguishes a regular Map from a Snow Map (10,762 and 3,687). Columbia Landcare uses only the Snow Map type; Keesen, JML and LSI use only Map. So a query written against one opco's convention will silently miss another's, and any estate-wide map feature has to read both types everywhere.

Method, and one number not to trust

Two passes. The first checked all 32 opcos for the attachment type and sampled up to 200 rows each — fast, but a lower bound for anything active. The second re-queried the five with a type configured, paging $skip 200 rows at a time until a short page confirmed the end.

The first pass undercounted every active opco by an order of magnitude, which is the same deep-paging trap the scheduling work hit from the other direction (METHOD.md §3). A sampled count is not a count.

The survey's own headline and its table do not reconcile. The headline reported 19,938 total attachments; the per-opco figures sum to 18,943, a gap of 995. This page uses the per-opco sum because it is traceable to individual rows. The headline figure should not be quoted until the difference is explained — it is the right size to be a missed page somewhere.

LSI's 200 should be read as a lower bound, not a total. It is exactly one page of the first pass and carries no earliest-upload date, which is the signature of a query that did not page to exhaustion. Every other active opco returned a non-round number and a start year. Re-run the full-count pass against LSI before quoting it.

What follows from this

• Do not scope a map-dependent feature estate-wide. It would serve five opcos and silently do nothing for 27. Scope it to the five, or treat the Aspire configuration change as a prerequisite with its own timeline.
• Ask ServiceTitan what configuring the attachment type involves. Whether it is a per-tenant setting, a template change, or a migration decides whether this is days or quarters of work — and it is the only question that matters for sequencing.
• Read both Map and Snow Map wherever maps are read. Columbia Landcare has no regular Map type at all; a Map-only query returns nothing for them.
• Re-run the full-count pass for LSI so the one soft number in the survey becomes a real one.
• Ask why Signature separates snow maps and nobody else does. If the distinction is operationally useful it belongs in the four other active opcos; if it is an accident, Signature's 3,687 snow maps need reconciling against its 10,762 regular ones before either count is used for area or pricing work.