Octopus Polarstar

Octopus Polarstar

An engineering programme's answers change. Polarstar keeps the reason.

Every number carries its boundary, its author and its evidence. When one of them moves, the platform says exactly what stopped being true — and stops the old answer being quoted as though it were still the current one.

The problem

Programmes rarely fail by producing a wrong answer. They fail by producing a right one, changing an input three weeks later, and continuing to quote the old one.

The state of a real programme lives in Word documents, chat threads, supplier PDFs, spreadsheets and simulation output. A reviewer can usually find what the answer is. What they cannot find is why it changed from A to B, who supplied the new evidence, which assumption was overturned, and which supplier revision and which simulation the current conclusion rests on.

That question should be a click, not an archaeology exercise.

Four rules

A stated value carries its boundary

"45 %" is not a fact. "Hydrogen chemical energy in on an LHV basis, to net electrical energy out, including balance of plant — 45 %" is. Comparing two efficiencies quoted across different surfaces is the commonest way a system-level number turns out to be wrong, so the boundary travels with the value everywhere.

Four kinds of number, never one column

A requirement, a supplier claim, a simulation result and a measurement are different things. They are all numbers about the same parameter, and collapsing them into one field called value is how a programme ends up designing against a marketing figure.

Nothing is overwritten

A newer number supersedes an older one; it does not replace it. The old row keeps its author, its date and its evidence — because "why did this change" is only answerable while the previous answer is still there.

Derived quantities are derived

Hydrogen mass is computed from usable energy and fuel-cell efficiency, never stored. Storing it would freeze one assumption into the model and lose the ability to say what moves when that assumption does.

How it works

Three things a reviewer who has been away for a week actually needs.

A parameter's page is its history

Every claim ever made about one quantity, in order, with who said it and on what boundary. The supplier's figure sits beside the stakeholder baseline without having replaced it.

  1. 50 %assumption2026-07-28
  2. superseded by
  3. 45 %stakeholder input2026-08-15 · Sherry
  4. compared with
  5. 46.8 %supplier claimdatasheet p.17
  6. validated by
  7. measurednot tested

Candidates against the requirement

Supplier claims compared to what the system demands, parameter by parameter. The gaps are computed from the data, not summarised out of a conversation.

ParameterABRequired
System η46 %49 %≥ 45 %
Start temp0 °C−10 °C≤ −20 °C
Outdoornoyesyes

⚠ A requirement no candidate meets is a finding, and it is arithmetic rather than opinion.

Why do we currently believe this?

Follow a decision back through the finding, the run, the component version and the claims, down to a document with a page number.

  1. Decision
  2. supported byFinding
  3. produced bySimulation run
  4. usedComponent version
  5. documented byDatasheet — p.17

And when something moves, it says what it broke

Superseding one value walks the graph and marks everything that rested on it. Nothing is deleted and nothing is blocked — the old run is still valid history. What is stale is using it to decide, and only that distinction is worth rendering.

4 experiment runs4 reports2 requirements1 finding

Three layers

Lab

requirements · suppliers · evidence · experiments · findings · decisions

Where people work, and the system of record. Every object versioned, sourced and auditable.

Engine

architecture · packaging · CAD · thermal · H₂ · FEA · optimisation

The AI system-engineering loop. Requirements in, architectures and analyses out — consuming a frozen snapshot of the Lab and returning runs to it.

Workers

FreeCAD · Gmsh · CalculiX · Code_Aster

The CAE processes the Engine drives, containerised and run headless.

Reference project

A containerised hydrogen energy system is the first programme run on Polarstar.

Electrolyser, solid-state hydrogen storage, fuel cell, battery and thermal management, at 5 kW and 10 kW platform ratings. Its requirement set, its open contradictions and its supplier evaluation all live in the Lab.

What is not on this page: which supplier fails which requirement. That is a supplier assessment belonging to the programme, and a platform whose argument is that evidence should be handled carefully cannot open by spending somebody's.

40 kWh
Net usable electrical energy per charge
3 kg
Usable hydrogen, design basis
−20 → 45 °C
Ambient operating range
6 × 3 m
Cabinet envelope

Nothing in the platform is hydrogen-specific. Energy storage, medical devices, sensors and robotics are the same problem in different units — a value asserted by somebody, on a boundary, that other work has come to depend on.

If your programme's current answer cannot name its author, it is not an answer yet.

Polarstar is in active development against a live engineering programme. The Lab is running now.

Open the Lab