> ## Documentation Index > Fetch the complete documentation index at: https://docs.cadenzalabs.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Why Cadenza? > How a single, end-to-end stack compares to the status quo of stitched-together tools. The way most teams build physical AI today is a patchwork: one tool for simulation, another for the training loop, a hand-rolled data pipeline in between, and a fragile script to get onto the robot. Every seam is a place where formats break, assumptions drift, and weeks disappear. Cadenza replaces that patchwork with **one stack, designed end to end** — the [SDK](/sdk/introduction) as the foundation you build on, and the [CLI](/cli-setup/introduction) as the workflow that turns it into data, training, and deployments. ## The status quo vs Cadenza | | Typical stack today | Cadenza Labs | | ------------------- | --------------------------------------------- | --------------------------------------------------------------- | | **Simulation** | A general physics engine you wire up yourself | MuJoCo core with robots, scenes, and an action library included | | **Data collection** | Custom logging and labeling per project | Every tick logged and scored automatically | | **Training** | Separate framework, glue code to reshape data | Rollouts → VLA data → LoRA in a couple of commands | | **Sim-to-real** | A rewrite from the sim loop to the robot loop | The same control loop runs in sim and on hardware | | **Iteration** | Re-plumb the pipeline on every change | One stack — a change flows straight through | ## Where the advantage comes from Every layer shares the same physics core, action library, and policy interface — no glue code, no format conversions between stages. Simulation and hardware run the identical control loop, so sim-to-real transfer isn't a separate, fragile rewrite. Every mission is logged tick-by-tick and scored automatically, so training data arrives clean and labeled — not as a separate annotation project. LoRA-based fine-tuning keeps specialization cheap, fast, and composable — swap task-specific adapters on a shared base model. ## Why it matters: iteration speed The point of a unified stack is **velocity**. Because every layer shares the same core, a change to a scene, a reward, or a policy flows through simulation, data, and fine-tuning without re-plumbing anything. Faster loops mean more rollouts, more data, and better policies — which is the whole game in physical AI. ## Start building The foundation — simulate robots, build scenes, and run policies in Python. The workflow on top — gather data, fine-tune, and deploy.