ragleap-physical: let an AI propose, a person approve, and test it all in simulation first (pre-alpha)

Short answer: ragleap-physical is a pre-alpha, simulation-only library that sits between an AI agent and a simulator. The AI can only propose a change. A named person approves that exact change, the bridge checks the limits again, and the outcome is checked in the simulator. Nothing in it controls real hardware, and it is not a safety certification. Five releases are on PyPI: 0.0.1 and 0.0.2 on 2026-11-02, 0.0.3 on 2026-11-04, 0.0.4 (changelog dated 2026-11-06) and 0.0.5 (changelog dated 2026-11-08). Updated 2026-11-09: this said four releases. Updated 2026-11-07: this said three releases.

What problem is it for?

Two things matter when an AI is allowed anywhere near a machine: a mistaken action, and not knowing who allowed it. The aim of ragleap-physical is fewer errors and a safer workplace (updated 2026-11-09: this said “fewer errors, fewer losses and a safer workplace”), by letting people build and test the approval and limit logic in simulation first, where a mistake costs nothing. That is the aim, not a measured result: nothing here has been validated against a real machine.

How does the approval flow work?

Observe. The AI lists its sources, reads an observation and reads the safety envelope.
Propose. The AI can only propose a change.
Approve. A named person approves the exact proposal in the operator console. The approver’s name comes from the token, never from the request.
Check. The bridge runs a dry run and checks the limits again, including the workspace box.
Apply and verify. The change is applied in the simulator and the outcome is checked there. An out-of-range value is refused, not clamped.
Stop. A stop needs no approval.

What can the AI do, and what can it not do?

The AI gets exactly four tools: list sources, get an observation, get the envelope and propose an action. None of them can approve, apply, stop or change a limit, because the limits live in the bridge and not in the model’s reach. A small MCP server (standard library, loopback by default, optional bearer token) serves the tools. It was tested against the official MCP Python SDK. RagLeap’s own MCP client was not read or tested against it.

Which limits does the bridge enforce?

A safety envelope that is checked again when a change is applied.
A workspace box in x, y and z that every tracked point must stay inside, checked on the starting state, on the dry run and again on the real motion in short slices. If a workspace is set and the adapter cannot report positions, everything is refused.
In the simulated machine tool, the AI can only adjust a tool offset, in micrometres, inside a range, a step size and a minimum gap between changes. Changing the tool itself is a human action. The numbers in that model are invented and say nothing about a real machine.

What has been tested, and what has not?

Our Tests page lists 19 test files and 239 test functions on the main branch. That is a count from the repository, not a pass count.
For 0.0.1 the release notes record 185 tests passing on the published source archive with MuJoCo and the MCP SDK installed (Colab, 2026-11-02), and GitHub CI on Python 3.10, 3.11 and 3.12.
Tests that need MuJoCo or the MCP SDK are skipped without those extras, and a skipped test proves nothing.
The project rule is that every limit or check needs a deliberate-break test: change one line, and a test must fail.
On Windows, a contributor found a connection reset (WinError 10053) on refused requests. Version 0.0.3 reads and discards a small request body before refusing, with a test. A clean Windows 11 re-test of 0.0.3 on 2026-11-04 still saw intermittent failures in full-suite runs (207 passed, 1 failed, 27 skipped; then 2 failed), and the failing tests passed when run alone. So the Windows problem is reported and not resolved.
MuJoCo results are repeatable within one installed environment only.

Who has helped?

@Anurag07-crypto tested the package and the first-hour guide on a clean Windows 11 machine (issue #1114) and added PowerShell steps (PR #1177). @bhuvanm0981-ctrl wrote the two-link workspace demo (PR #1153) and is translating the README into Kannada (issue #1123). Hindi and Tamil README drafts exist and have not been reviewed by native speakers. The release notes label the package AI-assisted.

How can I try it?

From a clone of the repository, inside packages/ragleap-physical, these lines are copied from the package README:

pip install -e ".[test]"          # core only, standard library
pip install -e ".[mujoco,test]"   # with the optional MuJoCo adapter
pip install -e ".[test,interop]"  # also runs the MCP SDK interop test
pytest
python examples/demo_fake.py
python examples/two_link_workspace_demo.py

The first-hour guide has the full walk-through, including Windows PowerShell steps.

What is it not?

Nothing is claimed about real robots, real machines, safety certification or regulatory compliance. A passing simulation test is not proof for a real machine. Not built: a second simulator, real hardware, and Java and npm clients. Out of scope, always: life-safety systems, medical devices, vehicles on public roads, weapons, and anything that could hurt people without an independent hardware safety stop. Real hardware and real machines are not open for contributions.

How can I help?

Mechanical, manufacturing and metrology engineers are asked to review the simulated models and say where they are wrong or unrealistic. A short, sourced comment is enough (issue #1139). There is also an open request for a seeded test that drives the bridge with random proposals, approvals, stops and restarts and checks the safety invariants after every step (issue #1138). See the library page, the 0.0.3 release notes and the open physical issues.