Insights16 February 2026Updated 26 October 20265 min read

Geo-Fencing for Asset Tracking: Evidence Before Compliance

Glowing blue roots form a global asset tracking network with data flow visualisation icons and text overlays on soil and grass.

A geofence alert reports a device's relationship to a configured region, not a continuous record of an asset's location. Apple's region-monitoring guidance describes entry and exit events and a system-defined distance beyond the boundary before a crossing is reported. For asset tracking, we recommend treating those events as observations to investigate, rather than automatic proof that equipment was present, used or inspected.

Establish what the device can report

Start by identifying what carries the location sensor: a dedicated tracker attached to equipment, a vehicle-mounted device or a worker's phone. Record the association between that device and the asset, including when the association begins and ends. If a workflow relies on a phone travelling with a tool, make that assumption explicit and provide a way to report separation. Do not label a phone's arrival as a tool's arrival without that supporting association. These are evidence-design recommendations, not claims that a geofencing API establishes custody.

Apple's guide defines a geographical region as a circle around a known point. We would therefore test the boundary against the actual site layout before using it to trigger a task. A proposed workflow for checking a delivery at a site entrance should specify how a person confirms receipt, rather than treating a broad site region as the delivery record. Keep the receipt, asset identifier and reported location event as separate records that can be examined together.

Design around platform limits

A few bright boundary rings active on a grid, with more rings drawn faintly and waiting

Apple documents a limit of 20 simultaneously monitored regions per app for its Core Location region-monitoring facility. The same guide says iOS does not wake the app for region notifications when Background App Refresh is disabled globally or for that app. It also describes a cushion distance intended to avoid repeated entry and exit events near a boundary. Those qualifications rule out promising an exact gate-crossing instant or uninterrupted evidence from this facility alone.

Google's geofencing guidance specifies 100 geofences per app per device user and warns that the service does not continuously query location. It also warns that unreliable data connectivity may prevent alerts from being generated, so an offline upload queue cannot be assumed to repair missing detection events. These are distinct from Android's general background restrictions: Google's background-execution guidance explains that background location restrictions limit how frequently apps can retrieve location. Google's background-location approval guidance also asks developers to explain why foreground access is insufficient. Do not translate a responsiveness setting into a guaranteed delivery time for an asset alert. Specify the operating-system versions, permissions and tracking API you intend to support, then measure behaviour on the devices being deployed. Keep alert detection separate from server receipt in the acceptance criteria, so a notification delay is not mistaken for a precisely timed physical movement.

Preserve the observation and its uncertainty

A glowing position point inside a soft halo of uncertainty, the halo overlapping the edge of a boundary ring

For each event, we recommend retaining the device and asset identifiers, region identifier, region-definition version and reported transition type. Where the chosen API provides a location fix and accuracy estimate, retain those too, without inventing coordinates for callbacks that do not supply them. Record when the app received the callback and when the server accepted the record, with the meaning of each timestamp documented. Do not rename either timestamp “time the asset crossed the gate”. These fields are our proposed record contract, not a promise that every platform supplies every field.

Keep a visible state for missing or stale evidence instead of silently carrying the last observation forward as confirmed presence. For example, an illustrative dashboard could show “last reported inside” alongside the observation time and a separate tracker-health status. A supervisor should be able to distinguish an old observation from a recent confirmation without opening a technical log. This separation follows the wider NIST log-management guidance to preserve original logs as well as interpreted records when evidence may be needed.

Make corrections traceable

Geofencing does not itself provide a storage or access-control policy. NIST treats log confidentiality, integrity and availability as matters that log management must protect. Define who may submit events, review disputed associations and export records, then test those permissions independently of the mobile screen. Agree retention and access rules with the people responsible for the information, including how to handle records that relate to workers.

For corrections, favour a linked explanation over silently replacing the original observation. We recommend adding a correction record that identifies the earlier observation, rather than editing that observation in place. Apply that principle narrowly here: retain the original event, record why its asset association was wrong and identify the correction's author. An append-only application convention should not be presented as proof that administrators cannot alter the underlying storage.

Keep the golden thread claim within scope

In England, the Building Safety Regulator's golden thread guidance concerns information kept by specified parties working on higher-risk buildings and those responsible for high-rise residential buildings. It calls for digital information that is secure, available and usable, and describes version control so users can see changes. That is a wider information-management responsibility than an asset crossing a virtual boundary. Use location observations only where they help answer a defined question about the building work, with the relevant inspection or handover record attached. Do not infer that an inspection happened because equipment or a phone was nearby. A geofence record alone does not establish compliance with those duties.

Test the failure cases before relying on alerts

We recommend a field trial covering boundary approaches, time spent near the edge and entry followed quickly by exit. Repeat the trial with the app in the background, restricted permissions, Background App Refresh disabled on iOS and a lost network connection. These cases follow from the documented platform restrictions, rather than an assumed “real-time” service level.

For the application itself, test queued uploads, repeated submissions and correction of a device-to-asset association. Ask a reviewer to reconstruct one disputed movement using the original observations, receipt times and correction history. Set acceptance thresholds from the operational consequence of a missed or late report, rather than a demonstration in favourable conditions. Where the trial cannot support a decision, retain a manual confirmation step instead of giving the automation authority it has not earned.

Update, October 2026

For teams using coding agents to implement this workflow, we recommend including the platform restrictions, record contract and unresolved assumptions in the agent's starting context. Our engineering article on grounding packs and explicit knowledge gaps describes an approach that carries provenance and dates with the information handed to an agent. Use the same evidence in independent review, so an implementation cannot pass merely because it repeats an unsupported promise from its brief.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →