What should happen when an AI system wants to change something in the physical world?
In a typical software workflow, an incorrect operation might fail a test or return an error. With physical equipment, the consequences can be more serious.
A machine has operating limits. Sensors have uncertainty. Mechanical systems have dynamics. A simulation can miss important real-world behaviour.
These are some of the challenges behind RagLeap Physical, our open-source engineering exploration into connecting intelligent software to physical processes.
Repository: https://github.com/ragleap/ragleap-core/tree/main/packages/ragleap-physical
Main project: https://github.com/ragleap/ragleap-core/
We are starting with CNC machining and tool-wear compensation. This post explains the architecture we are exploring, the research so far, and where contributors can help.
1. The core design principle: proposals are not commands
An AI system may identify a problem and propose an action. That does not mean it should be allowed to execute the action directly.
Our approach separates reasoning from machine interaction:
AI / Decision Logic
|
v
Action Proposal
|
v
Safety Bridge
|
+--> Validate command
+--> Check permissions
+--> Enforce limits
+--> Require approval when needed
|
v
Supported Machine Adapter
|
v
Simulator or authorised system
This is a conceptual view of the architecture, not a claim that every adapter or physical-control path is already implemented.
The important separation is between generating an action and authorising its execution.
2. What is a safety envelope?
A safety envelope defines the boundaries within which a proposed action may be considered.
For a tool-offset compensation experiment, relevant constraints can include:
- Maximum offset change per adjustment
- Maximum cumulative offset
- Minimum time or interval between adjustments
- An allow-list of permitted commands
- Permissions associated with the current operating mode
A proposal outside the allowed boundaries should be rejected rather than passed through simply because a model suggested it.
These software controls are only one part of a complete safety system. Real equipment also requires appropriate hardware interlocks, guarding, emergency-stop mechanisms and machine-specific risk assessment.
3. Test prohibited behaviour, not just the happy path
A safety-focused test suite should verify that the system refuses actions it must not perform.
The project work includes tests for behaviours such as:
- Observation-only mode cannot propose or apply changes.
- Recommendation mode cannot apply changes.
- Unsupported commands are rejected.
- Real hardware is refused where the implementation does not support it.
These tests are more meaningful than a single demonstration in which a simulated action succeeds.
The development conversation also recorded a MuJoCo test run with one failure related to a robot arm's tip moving approximately 0.16 mm because of joint coupling. The test assumption was subsequently revised, but the updated run still needs to be treated separately from independently verified real-hardware validation.
That is an important engineering lesson: a test can be wrong even when the underlying simulator is behaving correctly. We need to test the full trajectory and relevant constraints, not just assume the end position tells the whole story.
4. Why start with CNC tool wear?
Tool wear provides a concrete problem to investigate.
As a cutting tool wears, the dimensions of machined parts can drift. Measurements can inform a correction strategy, such as adjusting a tool offset.
Our research notebook explores this using a simplified model and synthetic data. It compares different correction strategies and examines the trade-offs between lost parts and the frequency of adjustments.
In the simulated scenario, measurement-based correction reduced lost parts relative to a no-correction baseline. A tuned simple rule also performed competitively with a more sophisticated predictor in the base scenario.
These findings are specific to the model and its assumptions. They do not demonstrate real-world scrap reduction, industrial precision or production readiness.
The next work is to keep the experiment reproducible, document the limitations and validate future claims against real measurements.
5. A staged path to real equipment
We do not want to jump directly from a successful simulation to writing commands to a factory machine.
Our intended path is:
Stage A — Simulate
Test the bridge, constraints, command allow-list and failure cases without physical equipment.
Stage B — Analyse
Use measurements or simulated telemetry to estimate wear and dimensional drift without controlling a machine.
Stage C — Recommend
Generate a proposed correction for a human operator to inspect and approve.
Stage D — Read-only telemetry
Investigate supported industrial interfaces that expose machine data without permitting control. The exact capabilities and access restrictions must be verified for each interface.
Stage E — Validate
Compare predictions with real measurements, a documented baseline and repeatable experiments.
Stage F — Consider bounded control
Only consider write-capable interactions when the adapter, machine-specific limits, authorisation, independent safeguards and supervised validation are in place.
Each stage has its own requirements. Passing simulation tests does not automatically authorise the next stage.
6. Where contributors can help
This is an open-source project, and we want engineers to help challenge and improve it.
Python and backend engineers
- Review the bridge and validation logic.
- Improve error handling and test coverage.
- Help keep interfaces clear and maintainable.
Robotics and simulation engineers
- Review simulation assumptions.
- Improve trajectory validation.
- Identify failure cases that current tests miss.
CNC and manufacturing engineers
- Challenge the tool-wear model.
- Identify practical measurement and machining constraints.
- Help define meaningful validation criteria.
Metrology and control-systems researchers
- Examine measurement uncertainty.
- Propose fair experimental comparisons.
- Help distinguish model performance from physical evidence.
Testing and documentation contributors
- Add regression tests and reproducible examples.
- Explain safety boundaries.
- Document unsupported operations and limitations.
A contribution does not have to be a large feature. A focused issue, a reproducible bug report, a careful code review or a better experiment can make the project stronger.
7. Explore RagLeap Physical
We are building toward a safety-first, open-source bridge between intelligent software and physical processes. We are not claiming that the project currently supports every machine, every industry or autonomous production.
The goal is to make progress that other engineers can inspect, test and challenge.
- Physical package: https://github.com/ragleap/ragleap-core/tree/main/packages/ragleap-physical
- Main repository: https://github.com/ragleap/ragleap-core/
If you work in Python, robotics, CNC, manufacturing, simulation, metrology or safety engineering, we welcome your feedback and contributions.
⭐ Star the repository if you find the direction useful. Explore the code, open an issue, or submit a focused pull request.
Build incrementally. Test the boundaries. Publish the evidence. Keep humans in control.
Top comments (0)