Revisit time and delivery latency measure different services

A satellite can revisit an area frequently while a customer's finished report arrives much later. The gap is not necessarily a failure. Observation, product preparation, availability through a supplier and release to the end customer are different stages. Each has its own timing measure and its own owner.

For a business buying imagery or derived data, the useful promise is the one connected to its product. An archive subscription, a data delivery and a reviewed analytical service should not be compared as if their advertised timing referred to the same event. Understanding the clocks helps the team price its own work and avoid passing an unsupported freshness claim to customers.

Revisit is a property of observation opportunity

ESA's Sentinel-2 mission summary lists a five-day revisit time. That is a mission characteristic. It does not state that a particular commercial customer will receive a usable, fully interpreted report every five days. The observation opportunity and the delivered product remain distinct.

A commercial proposal should therefore say whether its timing concerns potential observation, scheduled collection, acquired data or a customer-ready output. The customer also needs to know the conditions and scope behind the number. A figure referring to a mission or constellation is different from an enforceable commitment for a particular service.

This is relevant even for products built from public data. The provider may add substantial value by finding suitable observations, preparing them consistently and presenting a useful conclusion. The supplier should describe that added service rather than relying on the source mission's revisit figure as its own delivery promise.

A buying team can keep the comparison simple by writing the event beside each duration. If two numbers have different starting or ending events, they should not occupy the same comparison column without explanation.

Latency needs a start and an endpoint

NASA's LANCE service description says that most data products are available within three hours of satellite observation. That wording identifies the observation as the starting point and product availability as the endpoint. It also qualifies the statement as applying to most products, rather than guaranteeing every delivery.

A downstream company may still need to retrieve, prepare, review and incorporate the data into its own service. Those steps add time beyond the upstream availability measure. If the company advertises the supplier's figure as its own end-to-end performance, the customer can receive a materially different service from the one it expected.

A useful delivery record can separate the stages without exposing internal implementation details:

Recorded time	What it tells the customer
Source observation	When the underlying information was acquired
Product generation	When a particular processed result was produced
Supplier availability	When the contracted source product could be obtained
Customer delivery	When the buyer received its agreed output
Subsequent revision	When an earlier output was corrected or replaced

Not every subscription needs every timestamp in its visible interface. The service should retain enough information to establish the timing promise it actually makes.

Product quality can change with the delivery route

NASA's LANCE page encourages users to choose standard science products when latency is not their main concern, explaining that those products use the best available ancillary, calibration and ephemeris information. This is a concrete example of why a faster and a later product may represent different processing choices. It is not a universal rule that every later commercial product is better.

The commercial question is what quality and qualification accompany the rapid delivery. A supplier may provide an early output that is sufficient for a bounded application and a later revised product for another purpose. The buyer needs to know whether both are included and how the relationship between them is documented.

A company producing periodic environmental summaries might value consistency and traceability more than the earliest available preview. Another customer may have a legitimate need for a preliminary update, provided its provisional status is clear. Those are different service designs with different support obligations.

The contract should not leave the distinction to a footnote that disappears in a customer dashboard. If an early product is later revised, the downstream team needs a way to identify which version supported each published conclusion.

A fast typical delivery can hide a long tail

A service described with an average or median timing figure still needs an account of slower deliveries. A customer whose product depends on a regular deadline may be more affected by occasional lengthy delays than by a small improvement in typical speed. The comparison should reflect the consequence for the purchased service.

The provider can report a distribution or a proportion delivered within an agreed period, together with exclusions and missing cases. The buyer should know whether failed deliveries were counted. A statistic calculated only from successfully delivered products answers a narrower question than one covering every eligible request.

Consider a hypothetical monthly customer service. The upstream provider delivers quickly on most occasions, but one delayed input requires the downstream team to postpone a report. The provider's median can remain excellent while the customer-facing deadline is missed. The commercial response may involve a different service commitment, a clearly labelled incomplete report or a separately priced review.

There is no universal percentile or latency target established here. The purpose is to connect the measure with the buyer's product and the supplier's actual responsibility.

New processing does not make an old observation new

A fresh download can contain old information. Reprocessing, archive migration and improved analytics can create a new product from an earlier observation. That may add value, but it does not update the date of the underlying scene. The customer should be able to distinguish the two.

The OGC Connected Systems observation model makes a related distinction between the time associated with the observed phenomenon and the time a result was obtained. It provides a useful vocabulary for preserving the difference in data exchanges. A commercial platform need not implement that standard to explain the same distinction clearly.

A report combining several sources can also contain several observation dates. Reducing them to the date the report was generated can obscure uneven freshness. The product should state the period or source dates relevant to the conclusion, particularly when one input has been carried forward from an earlier delivery.

Our guide to optical and radar information products covers the complementary question of what each source contributes. Combining modalities does not remove the need to account for their different timelines.

Assign each delay to the service that owns it

A supplier can promise only the parts of delivery within its agreed scope. The customer should know which dependencies are included, which are provided by another party and how delays are recorded. This is useful for pricing as well as dispute resolution: expedited processing, analyst review and customer integration are separate services with real costs.

The purchasing record should identify the output, its timing measure, the basis for the claim and the treatment of delayed or revised deliveries. The same definitions can then appear in ordinary service reports, making performance assessable after the sales process.

Our reporting on NRO radar procurement and GAO's commercial-space data adoption findings provides market context. For a specific subscription, the useful final question is more precise: how old is the information when the customer receives the agreed product, and what evidence supports that answer?