Model execution and storage

The current platform supports three rat controllers:

1. the built-in statistical baseline;
2. a Python policy used in a headless run or training environment; and
3. a compatible ONNX model running live in the browser.

These controllers share simulation body rules. A model requests an action, while Godot owns fixed time, collisions, doors, body size, position, recording and termination state.

Observation and action boundary

The versioned training observation contains 31 named values by default. It covers body state, nearby walls and contact, local light, sound and odour samples, source directions and episode progress. Consumers read observation_names and the schema version rather than relying on an undocumented array.

The action is continuous [turn, speed] or one of five discrete moves. Values are checked and clamped. Stale browser answers, malformed outputs and incompatible dimensions are refused instead of being applied to the rat.

Headless Python path

The SDK launches a verified simulation pack without the 3D scene. Training can use one environment or several copies. Episode logs store settings, seeds, rounded actions, rewards and summaries, enabling an episode to be rebuilt later with full recording.

This path is intended for large numbers of simulation steps. Rendering is added only when a researcher chooses a run to inspect.

Browser ONNX path

In Setup > Rodent > Who controls the rat, a researcher can choose the built-in controller, a saved project model or an uploaded .onnx file. ONNX Runtime Web executes the network in the browser. Godot sends an observation for the current fixed step and applies the returned action through the same rat-body rules used by Python.

The toolbar and saved replay identify the model and immutable version. This provenance prevents a result from being silently reinterpreted after the model changes.

Storage model

rat_models belongs to one research project. rat_model_versions stores immutable version metadata, checksums, observation schema, action mode, SDK version, training summary and file locations. PyTorch weights and ONNX files are kept in the private rat-models Supabase Storage bucket under the project's folder.

Replays can reference the exact model version and training episode. Database constraints refuse a cross-project model/replay link. Row Level Security permits project members to read, permitted editors to add versions and the project lead to delete records.

Deleting a database version does not currently guarantee that its storage object is removed. Administrators must review orphaned objects in the bucket as part of model-retention maintenance.

Model compatibility

For live website use, an uploaded ONNX model must have:

• one float32 input with shape [1, 31];
• either two continuous outputs [turn, speed] or five discrete action scores;
• a recorded episode length for the progress observation;
• a supported action mode and observation schema; and
• a SHA-256 checksum recorded with the immutable version.

Recurrent state and custom extra observations are supported only when an adapter explicitly handles them; the current browser path does not.

Trust and scientific limits

Model execution is not a sandbox for arbitrary source code. The browser accepts a constrained ONNX graph, and the SDK loads model weights using the safer weights-only path where applicable. Researchers must still review provenance, training data, licence, architecture, reward function and validation evidence.

RODENT can prove which model version and configuration produced a software result. It cannot prove that the model predicts real biology.

AI Attribution: This page was prepared with OpenAI Codex assistance from the merged SDK, browser driver, Supabase migrations and tests.