Why Simulation Has To Be Closed-Loop

Most maritime simulation today is open-loop. Synthetic scenarios are generated in one stack. Autonomy is evaluated against them in another. Deployment runs in a third.

The simulator and the deployed system do not share a world model. They do not share a sensor model. They do not share a physics model. They share a name.

This works in the academic sense. You can publish with it. You cannot reliably ship maritime autonomy on it.

The reason is the domain gap. Models trained or validated against synthetic-only stacks behave differently in the real world because the synthetic world has different statistics, different edge cases, different sensor characteristics, and different physics than the world the model is deployed into.

The same problem shows up across the category: digital twins that are not continuously grounded in the physical world, simulators that drift from the systems they were meant to validate, and evaluation environments that pass models which fail in deployment.

The gap is not a bug. It is the structural consequence of building simulation separately from deployment.

Closed-loop simulation changes that.

The simulator runs on the same world model the deployed system uses. The synthetic scenarios it produces are continuously calibrated against the real-world data the deployed system observes. The autonomy stack evaluated in simulation is the autonomy stack that ships, tested against a model of the world it will actually encounter in production.

This is not a sim-to-real transfer trick. It is an architectural commitment that has to be made at the foundation of the stack and preserved through every layer above it.

The hard part is not the simulator itself. The hard part is the world model: physics-grounded, real-time, continuously updated from live sensor streams, and expressive enough to support both deployed decision-making and simulated scenario generation.

Building one world model that does both is the engineering problem. Once that exists, the closed loop is what the architecture naturally produces.

Maritime is the right domain for this approach because the operating envelope is too wide for synthetic-only training to cover. Wide dynamic range. Partial observability. Multi-vessel interactions. Sea state. Weather. Regulatory zones. Rare edge cases that may occur once a year at a single port and still dominate deployment risk.

You cannot synthesize a maritime distribution that survives contact with reality.

You have to ground in reality and build the simulation from there.

This is one of the architectural commitments KEKOVA was founded on: the simulator and the deployed system are built on the same live, physics-grounded world model.

The domain gap is not patched later.

It is attacked at the architecture.