What a hosted-payload customer needs before integration

A hosted-payload opportunity can remove the need to buy and operate an entire spacecraft. It does not remove the need to prove that the instrument being delivered fits the service being purchased. The most useful early question is therefore not whether a platform has room, but whether the parties have agreed what will be accepted and what that acceptance will enable.

For a startup developing a new sensing or computing product, this distinction affects both engineering expenditure and customer promises. A demonstration opportunity may be valuable even when it does not provide the duration, data access or repeatability needed for a commercial service. Recognising that difference before integration helps a company buy an experiment that answers a specific product question.

Identify the product behind the hosting offer

NASA's 2026 spacecraft-platform survey distinguishes hosted orbital services from purchasing a spacecraft bus. In the former, providers may take responsibility for integration, commissioning and operation; in the latter, the customer can retain a larger mission role. The chapter was published on 7 May 2026 and describes a market snapshot as of January. Its categories help structure a comparison, while individual service commitments still need confirmation from the provider.

A customer should turn the offer into a short description of the outcome. Is the purchase a period of experimentation, delivery of a specified dataset, access to hosted computing resources or continuing operation of an instrument? These outcomes require different evidence. A payload functioning briefly can be a successful experiment without satisfying the conditions of a recurring data product.

This is also where a company should identify which downstream promises are still conditional. Sales material can accurately describe an upcoming demonstration while distinguishing it from an available service. That distinction gives prospective customers a reason to follow the result without making them assume that a flight reservation has already resolved product performance.

An interface document records an agreement

NASA's Hosted Payload Interface Guide of 22 March 2018 defines hosted instruments through their dependence on host resources and uses interface-control documents to record agreements among the relevant organisations. Its verification appendix also distinguishes evidence about the instrument-to-host interface from additional verification of the instrument itself. These are recommendations and examples from that guide, rather than a universal acceptance rule for every contemporary platform.

The commercial lesson is that interface compatibility and product capability are separate claims. A hosting provider may be satisfied that an instrument can be accommodated without accepting responsibility for the customer's analytical accuracy, application software or final report. Conversely, strong laboratory performance does not establish that the delivered configuration has been accepted by the host.

The working agreement should identify its baseline: the instrument revision, applicable documents, accepted operating assumptions and unresolved exceptions. A signed cover page with an outdated attachment is weak evidence. The customer needs to know which revision the integration team will actually receive, and whether any later change requires renewed review.

Ask what the resource allocation permits

A headline capacity can describe the platform rather than the customer's allocation. Shared resources make this distinction commercially important. A proposal should state what is reserved for the payload, under which conditions it can be used and what happens when another obligation takes priority.

For example, a data-processing experiment may need a sustained period of service to complete a representative workload. An allocation that is available only in short, irregular intervals may still support useful experimentation, but it answers a different question about the eventual product. The company should decide whether the experiment will demonstrate the intended customer outcome or merely the ability to run part of the workload.

The same reasoning applies to data return. Generating information aboard the host has limited business value if the customer cannot obtain it in the required form or within the period available for analysis. BDI's guide to ground-station data-delivery handover explains how to make the receiving boundary observable. A hosted service should connect its payload commitment to that final delivery obligation.

Keep evidence tied to the delivered configuration

Consider an illustrative startup preparing a hosted environmental-monitoring demonstration. Its original instrument has completed the agreed review, but a customer requests a revised data product. The startup proposes a software change after the evidence package has been accepted. The new feature could improve the business case while altering assumptions the host relied upon.

The right decision is not automatically to reject the feature or accept it without discussion. The team should identify which accepted claims the change affects, who can assess that impact and what evidence is needed before the delivery deadline. A limited change may need a focused review; a broader change may make the existing evidence insufficient.

This creates a useful commercial choice. The startup can preserve the accepted demonstration and defer the feature, fund the additional review or seek a later opportunity. Each choice has a different effect on cost and learning. Treating the change as merely a new file hides that decision until integration discovers the mismatch.

An evidence register should distinguish completed, accepted, conditionally accepted and outstanding items. Completion means the supplier produced something. Acceptance means the authorised recipient agreed it satisfies the relevant condition. A report can exist while a significant question about its applicability remains open.

Make the integration handover a shared decision

Physical delivery of hardware should not be the first time the receiving team sees the evidence needed to work with it. The handover package should make the accepted configuration, remaining actions and ownership of those actions easy to understand. It should also identify the person authorised to resolve discrepancies.

Responsibility for ancillary work deserves explicit attention. A service price may include routine integration but exclude an unusual review, additional handling or repeated activity following a customer change. The customer should ask which assumptions support the quoted scope. This turns a vague expectation of included support into a cost model that can be updated when the product changes.

If an exception remains open at handover, record what can proceed and what must wait. Conditional acceptance can be practical, but only when the condition has an owner and a closing decision. An undefined promise to resolve it later exposes both parties to different interpretations of readiness.

Buy evidence that remains useful after the flight

The most valuable result of a hosted demonstration may be the evidence it produces for the next customer. That requires planning the output before the flight: a clear description of the evaluated configuration, relevant service conditions, observed results and limitations on interpretation. A collection of impressive screenshots rarely answers those questions on its own.

A customer should also clarify which material it can retain and use in a product assessment. Access to a dashboard during an experiment is different from receiving a durable export afterwards. Commercial discussions about evidence access should happen while the service is being defined, rather than after an engineer discovers that a needed record is unavailable.

BDI's D-Orbit profile provides company context for a market in which hosting and related space services are offered as commercial products. When comparing such offers, the decisive question is the same: what evidence will establish that the purchased outcome happened?

A well-defined integration package connects the accepted instrument to the resources allocated, the work included and the information delivered. That connection makes a flight opportunity easier to value. It also gives the company a disciplined way to explain what the demonstration proves, what remains uncertain and which customer decision the next stage must address.