Status: Proposed research mission; no field effectiveness established. Research orbit: LUNAR GATEWAY.
Original proposal · Domain model · Protocol
Thesis. A verified A/B firmware architecture should preserve a bootable, authorized image across interrupted remote updates. Proposed system. Model boot states, image hashes, signature decisions, watchdog resets, energy reserve, and contact windows as a state machine. A hardware-in-the-loop or software emulator interrupts updates at every transition and records whether the device boots a known image without unsafe command acceptance. Evidence and test. Measure recovery success and time, version monotonicity, and the proportion of transitions with an unambiguous audit trail. Compare against a single-image baseline using identical interruption schedules. Boundary. Tests stay on a bench or simulator; flight integration would require separate mission review, memory-wear analysis, and platform-specific fault injection. Anchors: NASA-STD-1006A, NIST SP 800-160 Vol. 2.
Treat the statement “A verified A/B firmware architecture should preserve a bootable, authorized image across interrupted remote updates.” as a hypothesis with a comparator and a population, not as a demonstrated benefit. Implement the precise mechanism described above; preserve the original evidence boundary and endpoint. Use the domain model to state variables and units, but justify which assumptions apply to this particular mechanism rather than copying the model mechanically.
Observation contract: collect only the fields needed to estimate this mission's endpoint. Candidate domain fields are Relative mission time, contact flag, queue bytes, evidence age, power mode, verified digest, rollback state. Bind every record to source/version, valid-time interval, missingness reason and a fixture or collection permission. The domain resource is NASA Core Flight System; its applicability is a candidate starting point, not an assertion that every field required by this mission exists there. When fields or labels are absent, design a synthetic or owned-system fixture and report the gap.
Baseline and falsification: use the original comparison stated above and at least one applicable simple baseline from Always-connected policy; transmit-at-every-step scheduler; unverified receipt. Match information, tuning, observation and resource budgets. Define an absolute acceptance floor and minimum meaningful improvement before collecting the final test results. Reject the thesis if the benefit disappears on an untouched partition, if the resource-normalized baseline dominates it or if a declared invariant fails. Choose numerical floors with the mission owner; this dossier does not invent measured thresholds.
Adverse-case matrix: Missed contact; delayed receipt; key expiry in blackout; storage full; reset during staging. Choose the cases relevant to this mechanism and explain any exclusion. Add a negative control in which the intervention should have no effect. Preserve ambiguous outcomes instead of assigning unsupported truth labels.
Graduate investigation: Availability vs freshness; cosmic faults vs software faults; limited energy; no trusted wall clock. Write a rival explanation for any apparent improvement; identify the smallest additional observation that distinguishes it from the proposed mechanism. Perform a sensitivity analysis over uncertain assumptions and a leave-one-environment/scenario-out evaluation. A performance difference within a synthetic fixture establishes only behavior of that fixture.
Review artifacts: model/assumption ledger; versioned input contract; baseline implementation; preregistered endpoint; adverse-case results with uncertainty; resource-use record; negative findings; independent review notes. The practical starting budget is NASA cFS source as architecture study; synthetic contacts, emulated payload; passive RF resources only. Independent reviewer sign-off remains pending.
Domain references and data caveats · Applicable resource ledger