Architecting in the Unknown: Lessons from a Space Systems Drill

A hands-on mental drill in system-level problem-solving that's outside my usual beat, but a reminder that every professional needs new tools and mental reps to stay sharp.

While it looks cool working on complex systems, wrapping your head around how the system came to be can kill you from the inside. Image source: reqi.io

Author’s note

My background is in Space Systems Engineering. I led Systems Engineering for a lunar lander mission, and before that, for a mission in very low Earth orbit (VLEO). Since then, I’ve consulted on mission and satellite design and also founded a startup that builds in-orbit edge computing systems for Earth Observation.

Last month, I ran a drill with ChatGPT to test me on systems thinking in Astronautics. This unscripted role-play exercise helped pressure-test how I frame problems, explore trade spaces, and make decisions in early-stage space architecture work. I am sharing the full chat for you to see my methodology and approach to solving system-level problems.

Most of my past writing has focused on launch economics, national programs, and new orbital regimes. While this piece is a little different from those, it offers a window into how I think, and how systems thinking plays out in real-time, when the problem is still foggy and the path forward unclear. I plan on repeating this exercise every once in a while and share how it went.

Without further ado, here is the chat (with ChatGPT o4-mini):

---

Question-1

Imagine you're tasked with designing a small satellite mission to monitor polar ice thickness over time. The customer has a tight budget and wants data updates every two weeks.

What are the key systems-level trade-offs you'd consider when architecting this mission?

Take your time.

My answer:

Based on the data provided (so far), we only understand the following dimensions of the customer’s needs:
1. Polar coverage
2. 14-day revisit/update cycle

Missing, and important data points that I would like to clarify and also understand why a non-satellite solution cannot work:
1. Is absolute ice thickness the need or is relative measurement okay?
2. Which is the closest solution that already exists, and generates similar data - what is the delta we need over that?
3. Does the 14-day repeat interval need to be guaranteed?
4. What is the budget for this undertaking?
5. Is there a ready-made sensor available already for such a requirement that can be used to build a preliminary ConOps?

Though it looks at first that trade-off studies can be started on balancing coverage vs. revisit, which means a balance between configuration and orbit selection - there isn’t enough data to start that unless the customer gives more clarity on what really matters to them.

---

Question-2

Let’s say the customer comes back with the following refinements:

• They are okay with relative ice thickness, as long as it’s consistent and traceable over time.

• The revisit interval should ideally be 14 days, but can vary slightly — consistency matters more than exact timing.

• They’ve reviewed CryoSat-2 and ICESat-2 and feel the resolution and latency are insufficient for their needs.

• Their budget is 1/10th that of a typical ESA mission — about $15M end-to-end.

• You’re allowed to use commercial sensors, but not restricted to them.

Given this, how would you approach the system architecture, and what are the first major decisions you’d drive?

My answer:

I would take this next set of questions in the form of a user interaction meeting, answering point-wise:

1. Relative thickness is acceptable, but what is measure of accuracy? Differential measurements across observations will still need some ground-truth. If that is accounted for, then we could start deriving the differential measurement specification. Data point still missing is the purpose of this measurement: tracing the requirement all the way to the outcome of this mission’s science is necessary.
2. Cool, this helps. Assuming that we do go for a satellite, the requirements to maintain the orbit isn’t too rigid. Helps in negotiating the system costs and budgets on this side.
3. Resolution and its system architecture effects can be straightforward to figure out given more data. Latency is an interesting aspect. We will need to understand the end-to-end activities to be undertaken all the way from a request to delivery of data products (the nature and level of processing of which is yet to be defined). This will help with the architecture as well as help find out if this is really possible within the budget specified. It looks like some novel approaches will be needed.
4. [[I had to Google the budget numbers for this]] The budget stated clearly broadcasts the difficulty of coming up with a system that has better resolution and latency as compared to 2 prior missions, of which ESA’s CryoSat-2 was the cheaper one at ~$200M. I would want to get far more realism and also the non-negotiable priorities of the user before getting into architecture.
5. We will again need to see how this data is being used and what impacts any compromises have.

I would drive for getting more “need statements” and pin down non-negotiable and hence separate them out from great-to-haves.

---

Question-3

Let’s say, hypothetically, the customer finally articulates the following non-negotiables:

• They want to monitor 6 key polar regions across the Arctic and Antarctic.

• Relative thickness must be consistent to ±10 cm across a 2-week cycle.

• They have access to some ground-truth points from autonomous buoys and snow radar once per season.

• Latency of less than 48 hours from acquisition to usable map is required.

• They are open to non-traditional architectures if justified — e.g., hosted payloads, virtual constellations, even a network of balloons or HAPS.

What would your first-pass architecture exploration space look like? You don’t need to commit to one idea — just outline the paths you’d open up.

My answer:

I would start with commercial sensors that, when combined with a position measurement system, can provide a thickness measurement (assuming an error budget can be worked out for this) in the ballpark of the user’s need.

Immediately, for position measurement systems where errors are directly proportional to platform altitude (MLAT or VOR), we might prioritize balloons and HAPS - and park the calculations for reference and compare them against platforms that have absolute position measurement errors that don’t scale with altitude (GNSS). The system-level uncertainty in ice-thickness should be the measure of the complete system’s performance (of course, tied to the 48hr latency and 14day +/-2day assumed revisit).

In order to validate that measurements can be stable within a season, we will need to go deeper into using the ground-truth data to calibrate the flying platform’s measurements across short and long temporal baselines. A science operations team would be best placed to draft the methodology and give their confidence on being able to generate timely products - I will pull them in, if available.

Using the information on the 6 specific regions across both the poles, I would assess the atmospheric platforms historically used and find out their cost, complexity of operations and see if (even for a single year), we can fit this into a budget 1/3rd of what the user has specified. This gives us a reference.

There seems to be a gap in establishing the reference for measurements when observations lie temporarily equidistant from 2 ground-truth campaigns. These would probably be the measurements with the largest uncertainties. It would be good to understand if the thickness measurement uncertainties requested are applicable here (most likely), or only on a statistical sense (i.e., median uncertainty rather than largest uncertainty).

I am not yet asking about lifetime, or total observations needed. I will get to that only in case we arrive at an operations-heavy budget and another solution gives a development-heavy budget.

ChatGPT clearly wasn’t enjoying my push for clarifying needs, and tried to force the issue by pushing me into ‘architecture’ territory.

Question-4

Imagine you're presenting three viable architecture options to the customer:

1. Option A: A CubeSat in sun-synchronous orbit with a commercial radar altimeter.

2. Option B: A shared hosted payload on a weather balloon network run by a polar research agency.

3. Option C: A partnership-based virtual constellation using tasking from existing satellites and fusing public data sources (CryoSat-2, Sentinel-3, etc.) with AI-driven consistency correction.

You know none of them alone meet all the goals — each has trade-offs. Your job is to recommend a strategy, not a single option.

How would you frame your strategy to the customer so they understand the logic of a hybrid approach — and trust that this isn’t indecision but intentional architecture?

My answer:

My recommended strategy would be to anyway go for Option C, and start working towards what the final data product would be. This helps set a baseline for what we are going to target; or even use this as a reference for measurements made by any of the other 2 options. This also helps get the science operations as well as preliminary science underway - which will help in adding to the budget request (if there is a funding agency looking for PR wins).

Option B’s viability will need some evaluation purely from a per-observation cost structure and rolling that upwards with the system budgets already available (I am assuming this) with the balloon network operator. Main decision-point in this is how close to the original requirements does this existing platform let us reach with the candidate commercial sensors while keeping the overall cost of observation below 1/3rd of the budget. It is also good to have a strawman error budget from Option C to compare and see if this is worth it.

Option A is really a last resort, mainly because the cost of development, launch and operations will be much much higher than the other 2. The datapoints from working with Option C, the trade space analysis for Option B - and feedback from the science teams will make or break the case to go for Option A. 

Meanwhile, I will start getting an assessment done on space-worthy or ruggedizable sensors for smallsats/cubesats and what they demand from a satellite platform perspective. Having this high-level spec will be good to put out an RFQ for satellite bus vendors and get a ballpark understanding of the cost and timeline for Option A, if the need arises.

ChatGPT: Would you like a bonus “curveball scenario” next?

Question-5 (Curveball)

Let’s say two weeks into implementation of your hybrid strategy, a new twist arrives:

The customer reveals that a global shipping alliance is now interested in purchasing the derived ice-thickness maps for optimized route planning. However, their use-case requires absolute geolocation accuracy of 1–2 meters, and ice edge delineation, not just thickness. They also need access to the processed maps within 6 hours of acquisition, not 48.

This is not part of the original mission, but they are willing to co-fund up to $10M extra if your system can serve this use-case without breaking the original science mission.

How do you absorb this new stakeholder, and reframe or re-architect accordingly — without compromising your original user’s needs or overextending your system?

My answer:

Responding to this new development would require a good understanding of the resources at hand with our user and intial stakeholder (the entity asking for this system), the timeline they would like to set (as an expectation) with the shipping alliance as well as finding out how far this requirement is from the next best solution they have access to.

Since the team is mostly working with Option C currently, they will be on their way to knowing whether or not the data products they generate give what the shipping alliance wants. Based on what can be achieved and where it falls short, I would advise our user to either (a) try to sell the Option C based solution to the customer with a milestone plan to achieve compliance over time - this doesn’t stretch the team and keeps things manageable; (b) fast-track Option B assessment and trade it against the strawman Option C to understand if this fills gaps found in a scaled up version of Option A. Only after this assessment is done, would I recommend getting back to the customer. Meanwhile, use some BD techniques to keep them warm while validating the real-ness of their requirements and ability to really pay.

ChatGPT: Want a final round? I can give you a “team-on-the-ropes” scenario where a major system choice you made is now being questioned by both the science team and the funding agency — and your next move decides the project’s fate.

Question-6 (gloves off)

You’re 8 months into the project. Option C is delivering early science results. But the team’s stretched — long flights, tricky calibration work, and some data ambiguity is wearing them down.

Suddenly, two things happen within a week:

1. The core science team publishes a preliminary result — but it gets criticized in a peer review as “potentially biased by platform drift and lacking sufficient temporal anchoring.” The PI is shaken, and wants space-based consistency now. They quietly tell the user: “If we’re going to be taken seriously, we may have to go directly to a satellite.”

2. The funding agency reads this — and is worried that the whole current path will never yield “defensible scientific output.” They ask you directly in a call:

“You made us back a path that’s now being questioned. We can approve a one-time $40M satellite development allocation, but we need a full go/no-go justification within 3 weeks. Or we’ll pause funding altogether.”

The science team is losing trust. The agency wants a pivot or a solid defense. Your own team is tired and short on morale.

How do you rebuild trust, realign the team, and make a go/no-go call — with only partial results, a shaky PI, and 21 days on the clock?

My answer:

Firstly, I don’t think all these developments would be known to me suddenly; with regular check-ins on progress, this would have been picked up much earlier.

But let's roll with it. I would take stock of all the feedback that has come on the data and the focus areas identified that make a space-based platform the only choice. With an expanded budget, this may be an easier exercise but doesn’t mean that it automatically compensates for what Option A wasn’t able to (in the time that it took to get here).

To up the morale of the PI and science team, I would point them to the previous budget and the challenge in getting a hardware-based solution off the ground. With the much smaller cost, they should take pride on the new value they have brought with existing systems and a new set of algorithms that have identified very definitive requirements that (probably) only a space-based system can solve.

With the interest from a paying customer and increased funding, a hardware-based platform that solves specifically for the drawbacks of the data fusion and AI-based method can be targeted. A Pre-Phase A (or even Phase A, as work on the other 2 options would be ready) report can be made available stating the architecture, timeline and cost, including - most importantly - how this system resolves the discrepancies of the current methodology and hopefully can even validate those results.

---

Question-7 (parting shot)

How do you respond to the SpaceX view that Systems Engineers are obsolete?

My answer:

The label may be fading but the function isn’t. Someone has to:
- Frame the real question
- Surface the true trade space
- Keep decisions reversible until they can’t be

That’s systems thinking. It is very much alive.

Thoughts

What began as a vague and loosely framed prompt about ice-monitoring turned into a layered exploration of platform choices, user needs, stakeholder shifts, and system-level tradeoffs. This wasn’t the result of a fixed method or playbook. It was the outcome of treating ambiguity as an opportunity rather than a limitation.

That is the essence of systems thinking. It doesn’t promise certainty, but it creates momentum.

In the space sector, where priorities shift and constraints evolve, momentum is often what keeps a project alive and adaptive.

My personal analysis of this drill:

1. In a few places, I anticipated the stakeholder’s needs without forcing them to declare them. I usually push even harder to get stakeholders to articulate conflicting priorities upfront - especially the “non-negotiables”.

2. Strictly speaking, the initial definition of Options A/B/C could’ve been anchored in quantified mission objectives earlier (e.g. required accuracy, spatial footprint per revisit, and target TRL at each decision point). And I could have asked for more clarity. But this, sometimes, is reality.

3. I deferred some architecture choices to “when needed,” which I felt is practical but can easily be called out as risk procrastination.

---

If this drill gave you a sense of how I approach complex, multi-disciplinary problems in space, and if you think that mindset could help your team, I’d be glad to talk. I’m happy to start with a no-obligation consultation to understand your challenge and explore how I can contribute.

If you just like reading what I write, consider subscribing.