Decline is the baseline.

Every system we build assumes someone will fix it. Mru starts from the opposite end: parts will fail, nobody will come, and the software has to keep doing useful work with whatever is left.

01 · The assumption

The intervention assumption

Every long-lived system is a maintained system.

Voyager has flown for 49 years, but a team on Earth still nurses it. Its power drops about 4 watts a year, and people decide what to switch off next. COBOL systems have run for about 60 years because people kept patching them.

Take the people away and almost every system fails at its first serious fault. That is the problem Mru works on, on Earth and in space.

49years

Voyager in flight, with a ground team the whole time.

NASA JPL

~4W / year

Voyager's power loss. Instruments go dark one by one.

NASA JPL, 2025

02 · The principle

The Degradation-First Principle

“Capability is a depleting resource to be spent, not a fixed budget to be defended.”

Whitepaper, §5 · Corollary

Most fault-tolerant designs treat a failure as an exception: detect it, mask it, get back to normal. On a system nobody can repair, there is no normal to get back to.

So Mru treats its own decay, of power, computing, memory and heat, as the governing condition. The goal is not to keep full function. The goal is the most useful work across the whole descent, from full capability to silence.

03 · The quorum

The shrinking quorum

Same hardware. Two designs.

Classic triple redundancy votes on three computers and stops when it can no longer form a majority. Mru keeps going: vote on three, compare on two, check its own work on one.

Computers leftToday (fixed TMR)Mru
3Vote. One bad result is outvoted.Vote. One bad result is outvoted.
2Compare. A mismatch loses the result.Compare. A known-answer test finds the bad one.
1Stopped, for good.Still working, at half speed. It computes twice and checks itself.

Mru decides exactly like fixed TMR while TMR can still run, so it can never deliver less. This is proved with Kani for every possible input.

04 · The architecture

Six layers

Six layers. The lower the layer, the smaller and more verified.

The whitepaper resolves a paradox: a system must be simple enough to be correct, and complex enough to decide things alone. The answer is layers. The lower the layer, the smaller and more verified it is.

This is the full architecture from the whitepaper. Today's software implements the Layer 1 quorum. The rest is the road ahead.

L5

Bounded self-change

A constitution in read-only memory. Rules can adapt how the mission is pursued, never what the mission is. Every change can roll back.

L4

Communication

Coding that adapts as power falls, from kilobits per second to bits per hour, and at the end a beacon.

L3

Science and knowledge triage

Rule-based, not neural networks: legible and bounded. Decides what is worth keeping as storage decays.

L2

Navigation

Star tracking with a fallback to dead reckoning.

L1

Hardware consensus and health Built

The shrinking quorum, memory scrubbing, a health registry, and a power accountant. This is the core that Mru Field and Mru Flight are built on.

L0

Survival kernel

About 200 to 500 instructions, under 10,000 lines of verified code, under half a watt in hibernation. It keeps the system alive.

05 · The descent

Six phases

Defined behaviour at each power level.

Power draw spans nearly three orders of magnitude. The system knows which phase it is in and spends what is left on purpose.

PhasePowerWhat it does
Full operations50–200 WEverything runs. Full voting.
Reduced20–80 WFewer instruments, less often.
Core operations5–20 WOnly the essential job.
Survival1–5 WStay alive. Wake rarely.
Beacon<1 WA last signal that says: I am still here.

Phases from the whitepaper, §13. A probe adds a Transit phase (<1 W) before arrival.

06 · The proof

“A claim about a thousand years cannot be tested by waiting.”

Whitepaper, §14

So we test it in simulation, in the open, and then in the field. Dusk ran 10,000 missions on hardware that only ever decays. The shrinking quorum delivered 1.34× the useful work of fixed TMR, and never less on any single mission.

→ Request information

Questions about the design? Ask the person who wrote it.

A few lines are enough: the hardware, where it is, and how long it must run without a visit. We will tell you plainly whether Mru fits, including when it does not.

  • Requests go to the founder, not a sales team.
  • We reply by email. If a call helps, we suggest one.
  • Technical questions are welcome. The docs and code are public.

Or write to contact@mru.space

Interested in

We use these details only to reply. No mailing list.