A sensor supplier can use the public UK Space Domain Awareness (SDA) requirements to understand potential contributions to a wider system, then prepare questions about allocation, interfaces and evidence. The publication is not a tender: it explicitly makes no commitment to issue a contract. Its measures of performance are indicative development thresholds, not statements of current UK capability or future goals. Cross-government Space Domain Awareness requirements
This guide uses the public document updated on 16 June 2026, checked on 8 September. It focuses on engineering readiness for a potential supplier discussion. The new strategy provides policy context, but neither document establishes a current contract for an individual sensor team. UK Space Strategy announcement Use the UK route guide to establish an actual procurement or funding path.
How do system requirements become supplier questions?
The public Annex B describes a system of systems (SoS). A sensor may contribute observations, calibration information or metadata, while other organisations provide processing and operational services. Start with the source requirement identifier, then separate your proposed contribution from the customer’s agreed allocation. Do not rewrite a SoS obligation as “every sensor shall” without that agreement.
| Source ID / topic | Public system need, paraphrased | Proposed supplier question |
|---|---|---|
| UKSDA-SR-13-003: interface documentation | Data accepted by the SoS needs appropriate interface control documentation | Which ICD, schema and version must accompany our observation data? |
| UKSDA-SR-14-004: audit trail | Data, products and artefacts need appropriate provenance and context | Which source identifiers, timestamps, processing steps and metadata must we supply? |
| UKSDA-SR-14-005: uncertainty | Generated data, products and artefacts need uncertainty information | What uncertainty representation and assumptions must our contribution expose? |
| UKSDA-SR-14-006: bias and accuracy | The SoS must be able to use observations with sensor bias and accuracy information | How should we represent bias estimates and the basis of accuracy claims? |
| UKSDA-SR-14-007: calibration | The SoS must handle and incorporate sensor calibration data | Which calibration records, validity conditions and change notifications are needed? |
The source column paraphrases Annex B. The questions are Arc’s preparation recommendations, not government-approved allocations or extra published requirements. Confirm exact wording and the applicable version in a customer discussion.
Worked example: an optical sensor contribution map
Fictional example: an optical sensor supplier proposes time-tagged observations with calibration metadata. It has not been selected for a UK programme. The team uses the public uncertainty and calibration requirements to prepare a data handover discussion, without inventing an accuracy threshold or an allocated national mission.
The proposed output is a sample observation record linked to a configuration identifier, a calibration record and an explanation of uncertainty assumptions. The systems lead asks the customer to confirm the interface schema and units. The metrology owner explains the calibration basis and validity conditions. The verification lead proposes checks that data and metadata remain associated through the handover.
The gap is explicit: the customer has not agreed the required representation. A locally convenient file format is therefore a candidate, not an accepted ICD. The supplier can prepare a representative sample and question list, but should not claim that the interface is compliant with an unagreed downstream service.
What should happen after a calibration or configuration change?
Suppose the sensor’s processing configuration changes while an earlier calibration record remains attached to new observations. A consumer may receive technically readable data with misleading context. In the example, the team proposes a configuration-to-calibration link and an explicit validity check before handover. The accepting authority must agree how changes are communicated and how previously supplied data should be treated.
Use the configuration guide to retain the item and processing state behind evidence. The TRL guide helps distinguish demonstrated capability from a planned representative trial. Neither an interface sample nor a source mapping alone establishes readiness for an operational deployment.
What should the supplier bring to the next discussion?
Bring a concise contribution map: public source ID, proposed role, allocation question, interface, evidence available, gap and owner. The workbook includes both a blank SDA sheet and illustrative mapping rows. Keep performance claims bounded by the measurement conditions and evidence you can actually show.
The intended decision is whether a defined contribution is worth taking into a funded project or supplier package. It is not a claim that a public requirements document guarantees a market, contract or technical acceptance. Record what the customer agrees, preserve what remains an assumption and use the actual opportunity notice for the next bid step.
Try one work package in Arc
Arc connects requirements, interfaces, risks, verification activities and evidence in a programme model. Arc connected programme model Start with one bid commitment, its proposed evidence and the person responsible for the next decision. Engineers remain responsible for the technical judgement; using a tool does not establish eligibility, compliance or a funding award.
Frequently asked questions
Are the public UK SDA requirements an invitation to tender?
No. The publication explicitly says that it does not imply a commitment to issue a future tender or contract. Treat it as public requirements context and use an actual procurement notice for bidding instructions.
Must one sensor meet every system-of-systems requirement?
Do not assume that. Identify your proposed contribution and ask the customer how the wider requirement is allocated. The supplier’s agreed scope and interfaces determine what it must deliver.
Are the published performance measures current UK capabilities?
The document says its measures are indicative thresholds for development, not statements of current capabilities or future goals. Preserve that caveat when discussing the requirements.
Evaluate Arc
Connect one bid commitment to its engineering evidence.
Try a work package in Arc: organise its requirements, interfaces, risks, verification work and evidence so your team can review the next decision.