Ground-station services: defining the data-delivery handover

A ground station can receive data successfully while the customer still has nothing it can use. The missing step may be a transfer to another facility, a processing job, a quality check or an unresolved mismatch between the delivered file and the customer's catalogue. For a company buying access to space infrastructure, the commercial question is where the supplier's delivery responsibility ends.

That boundary affects more than the service-level agreement. It determines which team investigates failures, whether a repeat transfer costs extra, when a product can be released to customers and what evidence supports an invoice. A ground-service proposal should therefore describe a journey from the purchased contact or capacity to a named information product at a named destination.

Reception and delivery are different products

ESA's description of the Sentinel Core Ground Segment separates acquisition, processing, quality assessment and archiving within distributed infrastructure. Users may experience a single access point even though several facilities contribute to the result. That architecture illustrates why the visible download service and the receiving station are different parts of a delivery chain. It does not establish the responsibilities in a particular commercial offer.

A customer could buy a scheduled reception service, a managed transfer of received data or a processed dataset available through an application interface. Each can be a reasonable purchase. They become difficult to compare when all three are described simply as ground support. A low price for reception may leave the customer funding storage, onward connectivity and processing elsewhere.

The proposal needs a plain description of the delivered object. Is it a stream, a collection of received files, a consolidated dataset or a product with quality flags and searchable metadata? State the version and packaging expected by the consuming application. A supplier should be able to point to the exact handover in a sample transaction without relying on the customer to infer it from a network diagram.

Start with the agreed service, then measure its execution

The IOAG service catalogue, issue 2 revision 3, provides a useful conceptual separation. It distinguishes evaluating a provider's catalogue, establishing a service agreement, describing scheduled services and accounting for the volume and quality of services after provision. This is an inter-agency framework from 2021, with some referenced formats still prospective in that edition. It should be used here as a model for clear responsibilities rather than evidence that a commercial provider implements every listed capability.

A catalogue says what a provider can offer. The order says what the customer actually bought. The delivery record says what happened. Keeping these records distinct prevents a capability statement from becoming the only evidence offered when an individual delivery is disputed.

For each booked service, the customer needs a durable identifier that appears in the schedule, completion notice and delivery record. Rescheduling should preserve the connection to the original request while showing the new commitment. Otherwise a missed delivery can disappear into a revised calendar, making both performance review and reconciliation unreliable.

Specify what counts as a complete handover

Consider an illustrative environmental-data company that buys reception and delivery for a daily reporting product. Its ground-service supplier delivers nine files and marks the job complete. The customer's software expects ten files, including a metadata record identifying the acquisition. The station may have performed its agreed reception task correctly, but the reporting product cannot be released.

The useful acceptance rule is not simply that some bytes arrived. It identifies the expected deliverables, a means of checking their integrity and the status of any missing elements. Completeness may mean all data received during the purchased service, rather than all data the spacecraft was originally expected to produce. Those are different promises and should remain distinguishable.

An incomplete transfer should have an explicit state. The customer may choose to ingest partial data provisionally, hold the product for a later correction or reject the delivery. That decision belongs in the product workflow. Quietly changing the status from pending to complete after a timeout creates an apparent success that downstream teams cannot interpret.

The handover should also identify the responsible recipient. Uploading to a supplier-controlled portal is different from acceptance by the customer's storage service. Where the customer controls the destination, the parties need an agreed record of delivery attempts and responses. This makes an unavailable customer endpoint distinguishable from a failure before the supplier attempted delivery.

Put each clock around a meaningful interval

Data delivery can contain several clocks: time awaiting a service slot, reception duration, time until the supplier makes data available, onward transfer and time until customer acceptance. A single latency number is useful only after its start and end events are named.

For a reporting business, the commercially important measure may be readiness before a publication deadline. The supplier may instead measure the interval after reception ends. Both numbers can be accurate while answering different questions. The customer should retain the supplier's bounded measure and separately assess whether the full chain meets the product deadline.

Percentages also need a denominator. Measuring successful files gives a different picture from measuring complete acquisitions or daily reporting packages. Ten small files delivered promptly should not automatically outweigh one large, essential dataset that was late. Choose the unit that corresponds to the purchased obligation, then retain enough detail to explain exceptions.

BDI's guide to imagery revisit and delivery latency explores the related distinction between a collection opportunity and a usable delivered product. Ground-service handover is the part of that chain where contractual boundaries should become observable records.

Agree how retries and corrections will appear

A repeat delivery can be a repair, a replacement or a duplicate. The customer needs to know which. Assigning a new filename without preserving the original identity can make an ingestion system count the same content twice. Replacing a file silently can leave two customer teams analysing different versions under the same apparent identifier.

The delivery record should explain whether the new object supersedes an earlier one, completes a previously partial package or adds newly available material. It should also preserve the reason for the change. An onward transfer failure requires a different commercial response from a correction to processing performed by the supplier.

Retention matters here. A supplier that keeps received data briefly may be able to replay a failed transfer during that window but offer no later recovery. The customer should compare that period with its own detection and support schedule. A weekend ingestion failure discovered on Monday is a foreseeable business case, not an exotic technical exception.

Review the service through a real transaction

Before committing to scale, ask for a representative delivery package and its associated records. Follow one identifier from the agreed service through completion, transfer, quality status and billing. Include a case with a missing element or customer-side interruption, so the review demonstrates how uncertainty is reported rather than merely showing the fastest successful download.

The SSC Copernicus ground-station extension is relevant market context for the continuing importance of ground infrastructure. A programme-level award, however, cannot substitute for the service description a particular customer needs.

The strongest commercial comparison uses the same handover boundary for every offer. Price the responsibilities retained by the customer, identify the records needed to diagnose an incomplete delivery and tie payment units to the agreed service. A station contact is an important event. The purchased outcome becomes assessable when the customer can show what arrived, where it arrived and whether it met the defined delivery condition.