A FarEye delivery milestone does not prove consignee receipt

Anchor the milestone to the physical shipment

FarEye's official source supports the narrow statement that the platform is positioned for delivery visibility and tracking. The direct answer is that a delivery milestone is evidence of what a named source reported at a named time for an identified object. It is not self-proving evidence that the correct order, package, pallet, container, location, person, quantity, or condition crossed the intended handoff.

Retain the seller and buyer order identifiers, shipment and handling-unit identifiers, carrier and service, route and stops, promised and estimated dates, source event code, source system, source timestamp and received timestamp, location method, device or carrier message, quantity, condition requirement, consignee identity, signature or other proof record, exception, and downstream inventory or customer-service transaction. Where identifiers are translated, the crosswalk and its effective version belong in the evidence chain.

Keep delivery states and decision rights separate

Out for delivery, arrived, geofence entered, attempted, delivered, signed, received, put away, accepted, returned, and disputed can be produced by different actors and answer different questions. A control tower may surface those events without owning their definitions or the commercial decision that follows. Teams should identify which state controls customer communication, inventory, revenue, carrier payment, claim filing, replacement, or refund.

The reconciliation should expose early scans, late scans, batch uploads, duplicate events, wrong-location events, substituted recipients, partial delivery, damaged goods, missing proof, rejected delivery, carrier correction, and customer dispute. The event used for service measurement may differ from the event used for accounting or contractual performance. That distinction must be explicit before a milestone becomes a KPI or an automated action.

Test latency, correction, and exception behavior

Visibility depends on carrier connectivity, event normalization, identity matching, time zones, map data, device behavior, and exception rules. Buyers should ask which party supplies each value, what latency is expected, how stale events are shown, whether corrections supersede or append, and how a carrier's event code becomes a displayed label. A confident interface is not a substitute for an auditable translation record.

Use one normal delivery plus a split shipment, partial quantity, missing scan, duplicate scan, offline device, time-zone boundary, incorrect geofence, changed address, rejected handoff, damaged item, and disputed proof. The demonstration should show source evidence, normalization, alerting, human review, customer communication, correction, and reconciliation to order, warehouse, transportation, finance, and claims records.

Treat performance language as untested positioning

The official FarEye page includes provider descriptions of visibility and operating benefits. This review uses those statements only to define the documented product role. It does not adopt provider-reported performance figures as independent evidence because the source does not provide a publication-controlled population, baseline, denominator, exclusions, comparison method, or repeatable test for this article.

Supply Chain Signal reviewed the exact source on August 28, 2026. The registered URL resolved to FarEye's current official tracking page and passed the selected-source gate. No post-August 27 material development was established. Buyers should verify contracted modes, carriers, geographies, event definitions, latency, prediction methods, proof records, integrations, exceptions, access, retention, exports, and measured outcomes in their own network.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Supply Chain Signal will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.