Learned policies are good at proposing. They are dangerous when given unconstrained authority over motors. The industry often collapses “it worked in sim” into “it is safe on metal.” Those are different worlds.

Reality OS (Rust last-gate implementation) is the fail-closed gate for Reality OS + Governor: a fail-closed certified command path design (design intent — not an ISO/SIL certificate we pretend to hold). Public description string we use:

Rust last-gate for Reality OS + Governor: fail-closed certified command path. SIM ≠ metal.

The repository is private on GitHub (sim-too-real/reality-os-rust), licensed MIT, and available for pilot diligence. It is a theworld-runtime port of the authority kernel.

Contact: vardhan@simtooreal.com · simtooreal.com · robosynx.com

Fail-closed Governor rules

The Governor may only:

• allow
• narrow
• abort

It cannot:

• invent a plan
• upgrade a refuse into an allow
• pretend SIM evidence is metal authority

SIM ≠ metal is stamped into the honesty model, not left as a slide footnote. Learned systems never write motors. That is not a branding line; it is an architectural refusal.

Crate map

The workspace is split so authority, physics analogs, plant I/O, and session surfaces stay separable:

The point of the split is auditability: a last-gate that is one opaque binary with “AI inside” is not something we want to defend in diligence.

Honest ledger (what we claim and refuse)

We encourage public technical writing about this stack only when it stays inside the ledger:

If a partner needs metal MEASURED, ISO/SIL, or independent hardware e-stop, that is a real engineering program — not something we paper over with a README badge.

What “certified command path” means here

In our wording, certified command path means: the software path is designed so only allow / narrow / abort exits exist, refusals cannot be upgraded by the learner, and SIM is not silently re-labeled as metal.

It does not mean: third-party ISO 10218 / 26262 / SIL certification complete. When we do not have that evidence, we say No.

How it sits next to RoboSynx and SimTooReal

• RoboSynx — free browser tools for URDF / SDF / MJCF, validation, 3D view, ROS 2 scaffold
• SimTooReal — Isaac Lab / MuJoCo training ops, failure detection, transfer scoring
• Reality OS / Reality OS — last-gate when a team is ready to talk about command authority near hardware (pilot)

Typical path: clean files → honest training metrics → transfer score → only then a fail-closed gate conversation. Skipping to metal because a demo looked smooth is how trust dies.

Pilots

For teams putting learned policies near metal, we discuss Reality OS as a pilot upsell with explicit scope: SIM/HIL analogs, governor behavior, and a written honesty ledger for what is still missing (metal MEASURED, independent e-stop, standards evidence).

vardhan@simtooreal.com

Fail closed. Name the holes. SIM ≠ metal.

Industrial and mechanical engineering already have enormous knowledge. Most of it is trapped in PDFs, tribal spreadsheets, and tribal memory. Physical AI teams need something else: machine-usable claims — rights, provenance, SI quantities, and curves — that a program can query without pretending English is a database.

Mech OS Datastack is that claims store. It is private R&D / pilot diligence today. It is deliberately not a second Mech OS kernel.

Contact: vardhan@simtooreal.com · simtooreal.com · robosynx.com

What it stores

Mech OS Datastack holds machine-usable claims about mechanical and industrial engineering:

• rights — what you are allowed to use and under what conditions the claim was recorded
• provenance — where a claim came from, so audits are possible
• SI quantities — numbers with units, not orphan floats
• curves — engineering curves as first-class data, not screenshots

The goal is a queryable substrate for diligence and tooling — not a blog of engineering tips.

Explicit non-goals

Two lines we will not blur:

1. Not a second Mech OS kernel. Mech OS owns mechanism admission, conservation structure, and the honesty stamp for admitted knowing. Mech OS Datastack does not write AdmissionStatus.
2. Fixture materials in v1 are synthetic. They are not AISI allowables. If a demo curve looks like a steel grade table, treat it as a fixture unless provenance says otherwise.

Cross-repo verification with Mech OS exists so the claims store and the admission kernel stay honest about their division of labor.

v1 shape: local CAS + SQLite

The v1 architecture is intentionally boring and inspectable:

• Local content-addressed storage (CAS) for blobs and artifacts
• SQLite for queryable claim indexes and metadata
• A CLI surface:

Boring storage is a feature. Auditors and pilot partners should be able to reason about the disk layout without a mystery service.

Why separate it from Mech OS

Mech OS answers: is this a unit-checked mechanism that may be admitted?

Mech OS Datastack answers: what mechanical/industrial claims do we have, with what rights and provenance, expressed in SI?

Mixing those jobs into one process creates a temptation: let a data ingest silently become an admission. We refuse that. Mech OS Datastack never writes AdmissionStatus. Mech OS remains the admission authority for knowing; machine::verify remains the simulation-admission authority on the FP side.

How teams should use this in diligence

If you are evaluating SimTooReal / RoboSynx and ask “what about mechanical allowables and claim provenance?”, the honest answer is:

• Mech OS Datastack is the claims and provenance layer
• Mech OS is the mechanism admission layer
• Neither replaces a certified materials database you already trust for production metal decisions
• Synthetic fixtures in v1 are labeled as such — do not treat them as AISI allowables

That sentence is longer than a slogan. It is also true.

Relation to the public products

RoboSynx helps you get robot files into simulators without install tax. SimTooReal helps you monitor Isaac Lab / MuJoCo training and score transfer readiness.

Mech OS Datastack is deeper stack: the industrial-claim substrate behind diligence conversations. Public writing about it is encouraged when it stays diligence-honest — provenance, SI, synthetic fixtures named as synthetic, no fake certifications.

Contact

vardhan@simtooreal.com

• simtooreal.com
• robosynx.com

Claims without provenance are rumors. We prefer queries with a trail.

A policy can converge beautifully in simulation and still fail on hardware because the real gap was never made explicit.

The problem is not that engineers do not know the sim-to-real problem exists. The problem is that many teams still evaluate it informally.

That usually sounds like:

• "the motions looked close enough"

• "it worked on one unit"

• "we added some domain randomization"

• "the reward was stable"

Those are not readiness criteria. They are anecdotes.

This article outlines a better framework based on the public SimTooReal platform: a five-pillar way to score and reason about sim-to-real transfer before a policy reaches real hardware.

Why reward is not a transfer metric

Reward is useful for optimization. It is not sufficient for readiness.

A high reward in simulation can coexist with:

• poor coverage of the action space that matters on hardware

• miscalibrated friction or damping

• joint distributions that diverge sharply from the real robot

• stable task completion in sim but unstable control behavior in the real system

This is why transfer needs its own metrics.

The five-pillar framework

SimTooReal describes its transfer advisor around five pillars:

1. joint distribution overlap

2. action space coverage

3. physics parameter alignment

4. behavioral consistency

5. simulator fidelity

Together, these give a more complete answer to the question:

"Is this policy ready for hardware, and if not, why not?"

1. Joint distribution overlap

Start with the actual behavior of the robot body.

Compare simulated and real trajectories joint by joint:

• angle distributions

• velocity distributions

• torque behavior where available

• tail events and saturation regions

If one knee, hip, wrist, or gripper joint behaves differently in reality, the failure is rarely "global." It is often local and mechanical. A per-joint view helps surface that early.

SimTooReal presents this as joint distribution overlap using techniques like histogram comparison and KL-style divergence checks.

That is a strong first pillar because it makes the failure spatially visible.

2. Action space coverage

A policy can look robust in sim while operating inside a narrow comfort zone.

That becomes dangerous when real-world disturbances push the controller into regions it barely explored during training.

Action coverage asks:

• how much of the policy's available action space was actually exercised

• whether the real environment is demanding action behaviors not well represented in simulation

• whether the run is robust or simply lucky inside a constrained envelope

Low action coverage is one of the clearest signals of brittle transfer.

3. Physics parameter alignment

This is where system identification becomes central.

If the policy is fighting the wrong world model, transfer will degrade no matter how clean the training curves look.

SimTooReal frames this around optimization over parameters like:

• mass and inertia

• friction

• damping

• contact restitution

The idea is straightforward: use real trajectories to minimize divergence between the simulator and hardware by tuning the simulator parameters more aggressively and more systematically than manual trial-and-error allows.

This is one of the highest-leverage parts of transfer work because small mismatches in contact and actuation physics often create outsized behavioral differences.

4. Behavioral consistency

Sometimes the per-joint statistics look acceptable, but the behavior still feels wrong.

That is why an end-to-end consistency metric matters.

SimTooReal ties this to trajectory similarity, including Dynamic Time Warping style comparisons. The goal is to ask:

• does the policy express the same behavior in the same task across sim and reality

• do the time-aligned trajectories remain meaningfully close

• do the observed deviations indicate a harmless style change or a real control risk

This is the layer that catches "it technically moves, but not the same way."

5. Simulator fidelity

The last pillar is more holistic.

Even when the controller and physics seem acceptable, the simulator can still be missing important realities:

• contact force accuracy

• sensor noise characteristics

• visual mismatches for perception-driven policies

• unmodeled latency or actuator response

Fidelity is the broadest pillar because it asks whether the world itself is good enough to support transfer claims.

It is also the pillar that makes teams more honest. Some transfer failures are not policy failures. They are world-model failures.

Making the score actionable

A transfer score is only useful if it changes what the team does next.

That means every low-scoring dimension should connect to a concrete intervention:

• poor joint overlap -> inspect local mechanics, penalties, or joint constraints

• poor action coverage -> expand perturbations and scenario diversity

• poor physics alignment -> run system ID and recalibrate simulator parameters

• poor behavioral consistency -> analyze task-level divergence and sequence timing

• poor fidelity -> revisit contact, sensing, and latency assumptions

This is what makes the framework useful for engineering. It is not just evaluative. It is directional.

From scoring to deployment gates

The most important consequence of explicit transfer scoring is that it enables explicit deployment gates.

On the public SimTooReal deployment pages, transfer validation feeds into a broader safety flow that includes:

• physics safety checks

• operator preflight

• shadow mode

• canary rollout

That is exactly where transfer analysis belongs.

The right question is not:

"Did the policy get a decent score?"

The right question is:

"Did the policy earn promotion to the next deployment stage?"

Practical starting point

One useful wedge in the SimTooReal product is that the transfer benchmark is public and easy to try:

https://www.simtooreal.com/score

The CLI pattern shown on the site is:

simtooreal score --sim sim_traj.csv --real real_traj.csv

That matters because it lowers the barrier to better evaluation habits. Teams do not need to buy into a full platform before they start quantifying transfer.

Final thought

Sim-to-real transfer gets better when it stops being treated as an intuition problem.

A team that can measure:

• body-level divergence

• action coverage

• physics mismatch

• behavioral inconsistency

• fidelity gaps

will make better deployment decisions than a team that only watches reward curves and demo videos.

That is why this five-pillar model is useful. It turns transfer into something you can inspect, compare, and gate with discipline.