What Counts as Credible Flight Evidence?

Credible flight evidence lets someone outside the mission team judge what a space technology did in orbit. The record should identify the configuration that flew, the question the mission set out to answer, the conditions in which it operated and the data that support the conclusion.

“It flew” records an event. A buyer, engineer or later mission needs enough context to decide whether that event reduces the risk they care about. A launch, a power-on or one successful output can support a narrow claim, while broader claims require broader operational evidence.

This guide focuses on the evidence package and the decision it supports. For the wider definition, transfer and limits of heritage, read the flight heritage guide.

Start with the decision the flight must support

Evidence is more useful when the next decision is clear before launch. The question may be whether a sensor holds calibration, a processor sustains a workload, a material survives relevant exposure or a communications system performs through defined operating modes.

That decision shapes the mission objective and its acceptance criteria. It also determines which telemetry, logs, reference measurements and environmental context must be retained.

The European Commission’s IOD/IOV programme includes experiment aggregation, launch and operations. ESA’s Technology Flight Opportunities process carries a demonstrator through accommodation, preparation, integration, in-orbit operation and flight-data use. Both examples treat evidence as the result of a managed campaign rather than a launch record alone.

An evidence ladder for flight claims

Different records support different statements. Keeping the levels separate prevents a small success from becoming a much larger marketing claim.

Launch and deployment record. This confirms that the article reached the intended flight stage. Whether the technology operated or met its objective remains open.

Power-on or first contact. A first response supports a narrow commissioning claim for the defined electrical and communications path. Sustained performance, environmental behaviour and recovery need further operation.

An isolated output, such as one image or packet. One result demonstrates that a function operated in orbit, within that event’s configuration and conditions. It does not establish accuracy, repeatability, duration or operating limits.

Telemetry and logs across planned modes. Recorded modes, conditions and events build a broader account of operation. A reviewer must still assess whether that account applies to a different design, unit or mission.

A closed report against success criteria. Here the campaign connects the objective, controlled configuration, observations and conclusion within stated limits. Procurement, repeat supply and uses outside that boundary remain separate decisions.

Repeated relevant missions. Repetition can extend the record across units, duration or operating contexts. Later changes still need comparison with the controlled baseline.

None of these records is worthless. The wording should match the level reached.

The configuration must be identifiable

A reviewer should be able to trace the result to the hardware, firmware and software that produced it. Product name and part number alone are often too broad.

For hardware, record the unit identifier, design revision, key materials and components, manufacturing and acceptance status, mounting and interfaces. For software, record the version, build, dependencies, runtime, compute platform, configuration parameters and update history.

The connection to pre-flight evidence matters too. Qualification and acceptance reports show which configuration and interfaces were verified before integration. The ECSS verification standard centres the verification programme on requirements, strategy and expected documentation. That traceability allows the flight result to extend an existing evidence chain instead of standing by itself.

A useful flight-evidence package

There is no universal flight-evidence certificate. The package should be detailed enough for the intended reviewer and the claim being made.

A practical record usually includes:

• mission objective, success criteria and the decision they support;
• identification of the flight unit, firmware, software and accepted changes;
• relevant ground-test and integration evidence;
• orbit and environmental context at the level needed for the assessment;
• operations timeline, commands, modes and duty cycles;
• health telemetry, performance data and reference measurements;
• data-processing methods, calibration and any exclusions;
• anomalies, unexpected behaviour, waivers and corrective action;
• result against each criterion, including partial or inconclusive outcomes;
• limitations and the configuration or use for which the evidence is relevant.

NASA’s Systems Engineering Handbook calls for verification records to identify the requirements and product versions, tools and equipment, results, pass or fail declarations and discrepancies. The same discipline improves an in-orbit evidence package even when the mission is outside a NASA programme.

Telemetry needs operational context

Telemetry can show temperatures, currents, state changes, errors, throughput, timing or other performance measures. Its meaning depends on what the spacecraft and payload were doing at the time.

A useful record connects the data to the operating mode, command history, software version, spacecraft state and relevant environmental conditions. It also documents gaps, filtering, calibration and processing. A graph without these links may look persuasive while leaving the reviewer unable to reproduce the conclusion.

Operational logs fill part of that gap. They explain planned sequences, interventions, resets, safe-mode entries, updates and decisions made by the mission team. Together, telemetry and logs turn raw measurements into a reviewable account of performance.

Partial success and anomalies still produce evidence

A demonstration can answer valuable questions without meeting every criterion. The report should separate success, partial success, failure and inconclusive results, then explain how each conclusion was reached.

An anomaly record should include the event, affected configuration and mode, available data, investigation, root-cause confidence, corrective action and any repeated operation. If a software update changes the behaviour, preserve the evidence from both versions rather than presenting them as one continuous configuration.

This approach supports a more credible claim and helps the next mission identify the remaining risk. A flawless summary with no anomaly trail can be less useful than an honest report that shows how the system behaved and recovered.

Flight evidence, heritage and TRL

Flight evidence is the recorded result. Flight heritage is the bounded claim built from that evidence and its context. Technology Readiness Level is a separate maturity assessment made against a defined system and use.

NASA’s current TRL definitions distinguish a prototype demonstrated in an operational environment at TRL 7, an actual system completed and flight-qualified at TRL 8, and an actual system proven through successful mission operations at TRL 9. The required evidence changes with the system boundary. A limited payload experiment should not be stretched into a TRL 9 claim for a future operational product.

ESA’s ATLAS programme for satellite communications describes flight heritage as evidence that hardware has operated successfully in space, and uses first-flight demonstration to help address operator concerns about adopting new products. That evidence can support market uptake, but procurement remains a separate decision.

What a buyer still needs to assess

Flight evidence reduces uncertainty within its stated boundary. A buyer or later mission will still compare:

• the flown configuration with the proposed unit;
• the demonstrated environment, functions and duration with the new use;
• manufacturing controls, component changes and repeat supply;
• interfaces, qualification and acceptance evidence for the new mission;
• unresolved anomalies and the strength of corrective action;
• data access, intellectual property, licensing and commercial terms.

One flight may be enough for a specific decision. Another programme may need added testing, analysis, a delta qualification or a new in-orbit campaign. The evidence package lets that decision happen without relying on a slogan.

How SATELYX structures the evidence path

For accepted technologies, SATELYX uses IOD as a Service to connect a defined mission objective with a controlled flight record. Each campaign keeps the configuration, telemetry, operational record and post-flight conclusion linked.

That post-flight record can support a bounded heritage claim and a later catalog assessment. Catalog entry and reuse remain subject to the evidence, repeatability, mission fit and the rights agreed with the technology owner. Customer payload data, customer intellectual property and reuse rights do not transfer automatically.

Review the shared IOD mission path to see how the campaign moves from fit to evidence delivery. If you are still assembling the configuration and interface package, the payload preparation guide covers what to bring to the first technical review.