The memory layer

Physics-accurate object memory, built from any capture. Realm takes raw geometry and authors the full physics bundle: mass, friction, articulation, and coupling contracts, all qualified before anything enters a simulation.

Realm takes what CLAP captures and turns it into something a robot stack can use. It identifies every object in a scene, retrieves its structured digital representation if one exists, creates it from scratch if it does not, and authors the physics that makes it simulable. The output is a set of USD files: one for the environment, one for each object, one for any non-standard robot. These are the inputs Veron needs to build and run a simulation.

The gap in Physical AI is not a smarter policy. It is persistent, structured, validated memory of the objects those policies are supposed to manipulate. Realm is what builds and maintains that memory.

The memory that compounds

Realm does not just build objects. It accumulates knowledge about them. Every object in the pipeline carries its physics calibration, its qualification record, and, after deployment, the evidence that real-world use has contributed: friction values refined from hardware telemetry, coupling resistances corrected when simulation and reality diverged, failure modes documented so they are not repeated.

This knowledge persists with the object. The next team to work with a coffee machine does not start from first principles. They start from the accumulated work of every prior deployment. Objects improve across use. That is the compounding this infrastructure is named for.

From capture to digital twin

Scene assembly from a recorded capture

When given a CLAP-captured scene, Realm reads the spatial record and identifies every object in it. For each one it checks the object library. If a qualified asset already exists, Realm retrieves it and places it at the exact position and orientation it occupied in the captured scene. If it does not exist, Realm creates it agentically from the capture data, authors its physics, and queues it for qualification.

The result is a scene where every object is placed at the exact position and orientation it occupied during capture, with validated physics loaded from the object library.

Scene assembly from a description

Not every scene starts from a physical capture. When a user wants to build or modify an environment, they describe it in plain language. Realm interprets the description, retrieves relevant qualified objects, and assembles the scene. Object placement, spatial relationships, and physics are handled automatically. The user iterates conversationally: add an object, adjust placement, swap a robot, change the surface.

Coffee machine built from a description: geometry, articulation, and couplings authored.

Physics authoring

Where geometry becomes simulable

Any reconstruction pipeline produces a mesh. What makes an object genuinely usable for manipulation training is the physics layer: mass, friction, collision geometry, articulation joints, and the couplings between parts, all authored together as a single qualified bundle.

Authoring is agentic, and reviewed at every stage. A planning agent writes parametric geometry through a CAD SDK; stage critics (structural, articulation, physics, visual fidelity against the source capture) review and correct each stage before anything reaches qualification. Where judgement is needed, an operator inspects and adjusts articulation in the Assembly Editor. Nothing changes silently: every correction, human or agent, lands in the object’s record.

The authoring pipeline

• Reconstruction: SF3D body shape priors combined with family-specific builders for moving parts (triggers, hinges, drawers, lids, reservoirs). Hybrid path: neural reconstruction where it works, procedural generation where it doesn’t.
• Physics parameters: articulation joints, masses calibrated to physical references, friction authored with frictionCombineMode=max, contact-aware constraints. Real numbers from measurement, not placeholder defaults.
• Affordances: grasp regions, contact surfaces, forbidden zones, and interaction points as explicit artifacts in the object bundle.
• Couplings: causal contracts between components, typed, versioned, and encoded in the asset bundle as couplings.json. Compiled by the Realarity Contract Engine at training scale into batched tensor rules, not per-task Python scripts.

Couplings

A mesh is a shape. A simulable object is a shape that understands how its parts relate to each other. Couplings define those relationships: the causal contracts that connect one component’s state to another’s.

Take a pedal-operated trash can. Pressing the pedal tread drives the linkage rod. The linkage rod lifts the lid dome through the hinge bracket. Four parts. One causal contract. Without that contract authored explicitly, a robot has 18 geometry meshes and no understanding of how the object actually works.

Causal contracts in Realm are typed: each specifies a trigger joint, a threshold condition, and an effect joint with a target value. They are stored as couplings.json within the asset bundle and qualify alongside geometry and physics as part of the gauntlet. A tap lever that flows water, a button that releases a spring-loaded lid, a drawer handle that slides the drawer — each is an explicit, qualified contract in the bundle, not a task-specific script written for one training run.

At training scale, the Realarity Contract Engine compiles these contracts into batched tensor rules, executable directly in Isaac Lab across every parallelised environment, with no per-environment Python in the training step. Measured against per-environment Python callbacks at 64,000 environments, the compiled rules execute 56,000× faster.

Contract Engine compiling coupling contracts to batched tensor rules for Isaac Lab.

Qualification

No object enters the pipeline without passing a qualification gauntlet. Every asset runs through a suite of deterministic tests. In our latest campaign, 19 of 20 object classes shipped end-to-end, at under a dollar of model cost per object.

What the gauntlet checks

• Watertight geometry: no open meshes, no degenerate faces
• Scale validity: dimensions within physical plausibility bounds
• Articulation root integrity: joints attached to the correct parent link
• Collision fidelity: collision geometry within tolerance of visual mesh
• Grasp clearance: end-effector reach verified against geometry
• Coupling consistency: all defined causal contracts trigger correctly and produce valid state transitions across the declared joint range
• Mass plausibility: cross-referenced against physical reference database
• Friction validity: no degenerate values that would prevent simulation convergence

Failures return as structured reports with the specific test that failed and the observed value. Silent failures are caught before they reach training.

USD output

Realm produces three kinds of USD file. These are the inputs Veron consumes to build simulation environments:

• Object USD: geometry, physics, articulation, affordances, couplings, PBR materials. One file per object.
• Environment USD: the assembled scene with all objects placed, lighting, surface properties, and spatial relationships.
• Robot USD: for non-standard robots without existing USD files, Realm imports the manufacturer model and patches joint limits, link masses, and collision geometry into a validated USD.

objects/coffee_maker_v3/
├── manifest.json                 # typed schema, round-trip validated
├── asset/
│   ├── asset.usd                 # OpenUSD — physics, articulation, materials
│   └── visual_mesh.ply           # textured mesh
├── affordances/
│   ├── grasp_regions.json        # gripper-accessible contact surfaces
│   └── forbidden_zones.json      # regions to avoid during manipulation
├── couplings/
│   └── couplings.json            # causal relationships between components
└── qualification/
    ├── gauntlet_results.json     # pass/fail per test with observed values
    └── physics_calibration.json  # masses, frictions, joint params

Get in touch to explore Realm.