About the Team:

The Interplanetary Sciences Program was established to expand access to scientific exploration across our solar system. Its mission is to make planetary research faster, more affordable, and more capable than ever before by rethinking how science missions are designed, built, and operated. The program aims to enable scientists to send instruments to distant worlds without decades of development or prohibitive costs. By creating a sustainable model for interplanetary exploration, we are transforming space science from an occasional event into a continuous process of discovery that accelerates knowledge, broadens participation, and inspires the next generation of explorers.

About the Role:

The storage platform is one of the foundations for accelerating scientific discovery: science instruments write to it, onboard AI reads from it, and the communications subsystems downlink the data on it to Earth.

You will define the storage architecture and build it yourself. This is not a role where someone else hands you a design and you implement it, and it's not a role where you write architecture documents and hand them to someone else to build. You will make the foundational architectural decisions (redundancy topology, replication strategy, failure domain boundaries, consistency guarantees, write-lifecycle management), build and test prototypes on commodity hardware, and then build the low-level systems code that makes those decisions real: storage drivers, filesystem integration, and fault recovery systems that survive radiation upsets across the full mission lifetime. You'll carry the design from proof-of-concept on commodity hardware through integration on flight hardware, validating every architectural assumption with fault injection testing along the way.

• Own the redundancy and replication architecture across multiple NAS units on two independent hardware strings, defining the consistency model for cross-string replication, the precise bound on acceptable data loss during a radiation-induced crash, and the storage platform's contractual guarantees in every degraded state: drive level, NAS unit, or full string failure. Codify this as the failure mode matrix that drives every implementation decision downstream
• Select the filesystem and design the pool architecture, confirming or revising the current ZFS baseline and owning the final configuration. Validate through quantitative reliability modeling that balance upset probability, rebuild risk, write endurance, and usable capacity over the full mission
• Define the write-endurance budget for a multi-year operational lifetime, allocating write capacity across continuous science ingest, continuous data reduction, periodic bulk reanalysis by onboard AI, and archival snapshots to produce data retention policies that retain key science data through end of mission
• Design the interface contracts between the storage platform and the science instrument, compute, and communication subsystems, defining what the storage platform guarantees, what it doesn't, and what happens when a consumer violates the contract while the platform is already in a degraded state
• Build the storage fault detection and recovery path at the hardware boundary (e.g., kernel driver, block layer, or firmware level) to take a radiation-induced upset from initial detection through filesystem re-integration and ensure transient failures never become data loss
• Build automated fault recovery that handles every scenario in the failure mode matrix, validated through sustained fault injection campaigns on the hardware-in-the-loop testbed to confirm the architecture performs as specified under real failure conditions.

About You:

• Demonstrated ability to make and defend architectural tradeoffs in writing: design documents, RFCs, or equivalents that other engineers built against
• 7+ years experience designing software systems for high reliability over long operational lifetimes: defining redundancy topology, failure domain boundaries, and degraded-mode behavior
• Track record of reasoning about failure modes before they occur: identifying what breaks, defining impact radius, and designing recovery paths at the system level, not just the component level
• Experience working at or near the storage system boundary in kernel, driver, firmware, storage infrastructure, or equivalent developments where you had to reason about hardware behavior and failure modes
• Experience with storage systems that maintain data integrity under faults (copy-on-write filesystems, log-structured storage, RAID architectures, or replication systems)

Nice to haves but not required:

• Familiarity with distributed storage replication models: synchronous vs. async, quorum systems, chain replication, and opinions about when each is appropriate
• Experience designing storage or data systems that must remain available and consistent across independent failure domains
• Experience defining interface contracts between storage platforms and upstream consumers — databases, data pipelines, application frameworks
• Depth in one or more of: filesystem internals, block layer and device management, storage protocol implementation, or fault-tolerant storage infrastructure
• Strong working knowledge of storage data structures and systems reasoning — Merkle trees, NVMe submission/completion queue ring buffers, hash tables, radix trees
• Hands-on experience at the driver/hardware boundary: DMA coherency, MMIO semantics, PCIe enumeration, and cache behavior
• Experience testing storage systems under fault injection: PCIe/NVMe resets, error storms, low-level tracing (ftrace/perf/bpftrace), and crash dump analysis (kdump/vmcore)