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.
What belongs in the 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.
Fictional proposed observation handover
Observation: OBS-SDA-01, sample definition only
Configuration: CFG-OPT-01 rev B, processing PROC-OPT-01 v0.1
Calibration: CAL-OPT-01 rev A, validity not yet demonstrated for processing B
Candidate quantities: azimuth/elevation in radians in a defined local topocentric frame
Clock basis: UTC representation and instrument time association to agree
Uncertainty basis: calibration, timing and processing contributions to be evaluated, no accuracy value supplied
Validity: pending calibration/applicability review
ICD: downstream schema, frame convention and units not agreed
Decision: systems lead holds handover until the customer agrees representation and metrology owner supports validity
This is a preparation sample, not an allocated UK obligation or an accepted operational observation.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 happens after a calibration 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 we 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.
Keep sensor observations attached to calibration context
Connect the proposed observation record to its processing configuration, calibration evidence and customer-agreed interface. A changed calibration or processing version should trigger a review of evidence applicability before a new handover is accepted. Arc’s connected programme model can organise that context; engineers retain the technical and approval decisions.
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.
What belongs with a sample SDA observation record?
Keep its source identifier, timestamp, processing configuration, calibration record and uncertainty assumptions associated through handover. Ask the customer to agree schema, version and units; a locally readable sample is a candidate interface until that agreement exists.
What should a supplier review after a processing or calibration change?
Assess which observations and accuracy conclusions the old calibration still supports, preserve the prior processing state, and agree new validity checks and notifications with the accepting authority. Attaching an earlier calibration file to new observations does not establish its applicability.
Book a demo
See how Arc connects a bid commitment to requirements, review decisions and engineering evidence.