On-Orbit Workload Assurance Architect — Earth-Imaging Constellations

The mandate

The constellation is moving cloud detection, compression and prioritisation onto spacecraft to reduce downlink latency and volume. Existing mission records identify uploaded software and delivered products, but do not fully connect a customer task to the exact onboard workload, source-pixel subset, model or algorithm state, radiation exception, discard decision and later ground reprocessing. Irrecoverable source deletion raises the stakes.

The engagement deliverable is an On-Orbit Workload Assurance Architecture covering task authority, spacecraft capability, signed workload, payload capture, input selection, execution, fault response, derived product, source retention, downlink and deletion. It will define three reference workload classes and a conservative separation from flight-safety and command functions rather than import terrestrial orchestration assumptions wholesale.

Milestone one at week four supplies mission journeys, consequence-ranked evidence loss and spacecraft constraints. Week nine concludes milestone two with the workload manifest, trust boundaries and ground reconciliation model. At week sixteen, milestone three delivers reference emulation and contact-loss exercises. The accepted architecture, interface contracts, rollout sequence and internal qualification pack close milestone four at week twenty-two.

Acceptance requires mission and product teams to reconstruct twelve unseen outputs to authorised task, input region, workload binary, parameter set, execution and retained source; a simulated radiation upset and interrupted contact must produce bounded recovery; and Safety independently confirms command separation. The space-systems executive signs after client operators run an onboard-source-deletion challenge without consultant intervention.

The client will provide mission plans, payload and compute constraints, software manifests, selected image lineage, telemetry, fault-management rules, contact schedules, customer obligations and emulation access. Client engineers build references and authorised operators run spacecraft procedures. Flight software delivery, spacecraft command, collision avoidance, mission-safety approval, launch decisions and production deployment remain expressly excluded.

Why this is external work

Flight teams protect spacecraft, image scientists optimise derived products and cloud teams bring familiar workload tools, but no independent owner spans the irreversible onboard decisions among them. External architecture adds space-aware lineage and failure testing without commanding a vehicle, selecting a flight procedure or promising cloud-like recoverability where physical contact and radiation disagree.

What you will own

• Map task authority, workload manifest, payload capture, selected input, algorithm execution, fault, product, source retention, downlink and deletion.
• Define effective identity for spacecraft, compute unit, signed binary, model, parameter, calibration context and output across contacts.
• Design resource admission and priority evidence for power, thermal, storage, compute, contact and competing mission constraints.
• Exercise radiation upset, partial execution, stale ephemeris context, interrupted upload, contact loss and premature source deletion.
• Specify reconciliation when onboard and ground catalogues disagree without silently recreating evidence that no longer exists.
• Compare orchestration approaches through determinism, command separation, fault containment, update trust, portability and mission burden.
• Transfer workload qualification and source-retention scenario ownership to permanent mission, product and software teams.

Candidate qualifications

• Led on-orbit processing, payload-compute or mission-software architecture across an operating Earth-observation or scientific constellation.
• Connected customer task, spacecraft configuration, payload source, workload version, telemetry and derived product in reviewable lineage.
• Governed onboard storage and deletion where loss of contact or failed processing could make source evidence irrecoverable.
• Designed fault containment for radiation upset, constrained resources and interrupted contacts without intruding into spacecraft command authority.
• Worked across image science, flight operations, safety and commercial product teams under mission and customer timing pressure.
• Delivered architecture client operators could qualify in emulation and mission rehearsals after external specialists withdrew.

Non-negotiables

• The named architect must lead Vancouver mission workshops and both emulated contact-loss and source-deletion acceptance tests.
• No financial relationship may exist with onboard compute, payload, orchestration or ground-platform suppliers evaluated.
• Flight operators and authorised safety leaders retain command, fault-response, mission-priority and spacecraft-risk decisions.
• Production flight code, active commanding, launch and collision decisions, and mission-safety certification are excluded.

1. 49 words maximum. Describe an onboard computation whose source data became unavailable before its output could be reconciled.
2. 49 words maximum. How did you separate a payload workload controller from spacecraft command and fault protection?
3. 49 words maximum. Which client artefacts are essential before testing an interrupted-contact workload recovery?