What CSF is and why it exists
Text-conditioned motion generators can now produce full-body motions from natural language, with trajectories you can track on a physical platform 1. But these generators don’t understand scene-dependent safety: “reach forward” could mean touching an object or colliding with a person, depending on context 1.
The usual patches are:
- Prompt inspection – block or rewrite unsafe text commands.
- Labeled motion datasets – learn to classify or avoid unsafe trajectories.
- Geometric constraints – hard-code distance, velocity, or collision limits.
These approaches all miss the central problem CSF targets: the same abstract motion can be safe or unsafe depending on how it plays out in the scene 1.
Contextual Safety Filtering (CSF) is proposed as a training-free filter that wraps around existing motion generators. It grounds natural-language safety rules in safe and unsafe reference trajectories produced by the generator itself 1. Instead of learning new models or labeling large corpora, it uses the generator’s own motions as exemplars of “this is what safe looks like” and “this is what unsafe looks like” for a given rule.
The target use case: you already have one or more pretrained text-to-motion generators; you want to deploy them on real robots in human environments without retraining them, while preserving as much benign behavior as possible.
How CSF works, step by step
From the abstract, we can reconstruct the core pipeline at a high level. There are three main moving parts:
- Natural-language safety rules
- Safe and unsafe reference trajectories from the generator
- A CBF-QP that tracks “safe” references via an affine safety value 1
1. Start from natural-language safety rules
CSF is built around natural-language safety rules like “do not move the arm toward a person” or “avoid stepping on fragile objects” in a given context. The paper describes CSF as grounding “natural-language safety rules in safe and unsafe reference trajectories” 1.
Mechanically, this means:
- You specify safety constraints at the level you think about the task (language), not as geometry or low-level joint limits.
- For each such rule, CSF constructs some representation of what compliance and violation look like in motion-space, using reference trajectories.
The selection process for rules and how they are parsed is not detailed in the abstract, but the key point is that they are natural-language-level inputs into the system 1.
2. Use the generator to produce safe/unsafe references
Instead of relying on external labeled data, CSF asks the generator itself to produce trajectories that stand in for:
- “Safe” behavior under a rule
- “Unsafe” behavior under the same rule
The abstract states:
“We introduce contextual safety filtering (CSF), a training-free filter that grounds natural-language safety rules in safe and unsafe reference trajectories produced by the generator.” 1
For an operator or system integrator, this means:
- You don’t retrain the motion model.
- You don’t need a pre-annotated safe/unsafe dataset.
- You do need a process (likely prompt- or configuration-based) to produce representative safe and unsafe trajectories from each generator for each safety rule.
The “contextual” aspect comes from the fact that these references are evaluated and enforced relative to the actual scene. The abstract emphasizes that previous safeguards don’t “directly account for how scene context changes a motion’s meaning” 1; CSF does, by comparing actual motion to references that implicitly encode scene-dependent meaning.
3. Construct an affine safety value per rule
Once you have safe and unsafe references for a rule, CSF uses them to define an affine safety value for that rule 1.
From the abstract:
“For each active rule, safe and unsafe reference trajectories define an affine safety value that a safe reference tracking CBF-QP enforces.” 1
Key pieces:
- Per-rule metric: Each rule gets a scalar “safety value” that varies with the current motion and context, and this value is affine in relevant quantities.
- Defined by references: The mapping from “current trajectory vs. scene” to this safety value is tied to the safe/unsafe references you extracted from the generator.
In practice, this means the filter:
- Monitors the evolving motion trajectory.
- Computes, for each active rule, where the current motion sits between “like the safe reference” and “like the unsafe reference” along some affine dimension.
- Treats that as a constraint to be enforced.
The exact mathematical form of this affine function and how it’s parameterized are not given in the abstract.
4. Enforce safety via a CBF-QP that tracks safe references
The enforcement mechanism is a “safe reference tracking CBF-QP” 1.
The abstract indicates:
- The CBF-QP’s job is to enforce the affine safety value for each active rule.
- It does this while tracking a “safe reference,” which is the desired motion trajectory from the generator that adheres to the safety constraints as encoded by the references 1.
In terms of control flow in your stack:
- The text-conditioned motion generator outputs a candidate trajectory for the robot (potentially unsafe).
- CSF wraps that trajectory in a filter implemented as a CBF-QP.
- For each timestep, the CBF-QP:
- Tries to track a reference trajectory that is safe w.r.t. the current rules.
- Adjusts controls/trajectory so that the per-rule affine safety value satisfies its constraints.
- The resulting adjusted trajectory is what you send to the robot controller.
This is online filtering: the paper reports that the filter was demonstrated on a real robot, so it must operate at control-loop timescales on real hardware 1.
5. Rule activation in context
CSF doesn’t just statically apply all rules; the abstract notes:
“Across four pretrained generators with different architectures, CSF activates the intended rules in all explicit and scene-triggered unsafe cases…” 1
So, some rules:
- Are explicitly unsafe (e.g., a prompt that clearly indicates an unsafe action).
- Or are scene-triggered unsafe (the same motion becomes unsafe due to where people/objects are).
The system must therefore detect when a rule becomes “active” based on the generator’s output and the scene, and then apply the associated affine safety value via the CBF-QP.
The details of this activation logic are not described in the abstract, but for a systems builder the key behavior is:
- You can rely on CSF to turn on relevant rules in scenarios where either the prompt or the scene make the motion unsafe, and leave them off when motion is benign 1.
Where CSF fits in your stack
Given only the abstract, the minimal integration picture looks like this:
- Per-generator setup
- For each motion generator you want to use, derive safe and unsafe reference trajectories for the safety rules you care about 1.
- These references define per-rule affine safety values.
- Runtime control loop
- User/environment produces a text instruction.
- A text-conditioned motion generator outputs a desired trajectory 1.
- CSF wrapper:
- Determines which rules are active (explicitly or via scene triggers).
- Computes the per-rule affine safety values for the current state 1.
- Solves the safe reference tracking CBF-QP to adjust the trajectory/control commands while enforcing the safety values 1.
- The adjusted command is sent to the robot’s low-level controller.
- Hardware deployment
- The authors demonstrate this full loop on a real-world Unitree G1 robot, where CSF “successfully prevents unsafe motions in a variety of scenarios, including interactions with humans and objects” 1.
CSF therefore acts as a modular safety layer between any text-driven trajectory source and your hardware, without needing to specialize to generator architecture 1.
Performance and trade-offs
The abstract reports two key metrics across four pretrained generators with different architectures 1:
- Danger-event reduction: CSF “reduces the danger-event rate by up to 90%” 1.
- Benign motion preservation: It “preserv[es] 88–100% of benign motions” 1.
This indicates:
- The filter effectively eliminates the vast majority of dangerous behaviors detected under their evaluation setups.
- It does so with low false-positive rates: most benign trajectories are left unchanged.
The abstract also states:
“Across four pretrained generators with different architectures, CSF activates the intended rules in all explicit and scene-triggered unsafe cases…” 1
So, in the reported experiments:
- The rule activation mechanism is robust to both explicit unsafe prompts and more subtle scene-triggered unsafe scenarios.
- CSF generalizes across motion generator architectures without retraining 1.
From a deployment perspective, this suggests:
- You can wrap multiple generators (e.g., different models for locomotion vs. manipulation), using the same CSF approach, as long as you can obtain relevant reference trajectories from each 1.
- You get strong safety improvements without giving up most of the motion diversity and fidelity you got those generators for in the first place.
The abstract does not provide measurements of latency, computational overhead, or the precise conditions under which the “up to 90%” and “88–100%” were observed (e.g., which generators, which tasks).
Why this matters right now
The paper targets a specific, current gap:
- Text-conditioned motion generation is already good enough that you can “track” the resulting motions with physical robots 1.
- At the same time, these models are context-blind with respect to safety: they do not understand that moving toward a human is different from moving toward an object, even if the kinematics look similar 1.
CSF’s significance for practitioners:
- It is training-free: you can bolt it on to existing pretrained motion generators 1.
- It operates at the natural-language rule level but enforces constraints through continuous control.
- It has been validated not only in simulation but also in a real robot (Unitree G1) in scenarios that include interactions with humans and objects 1.
If you’re building agentic systems that control physical robots via high-level language, CSF provides a concrete architecture pattern: wrap your generator with a contextual safety filter driven by natural-language rules and generator-derived references, enforced via online optimization.
What to watch next
The abstract sets up several directions that matter for engineers:
- Scaling to more complex scenes: The paper demonstrates “a variety of scenarios, including interactions with humans and objects” 1, but it doesn’t say how it scales with scene complexity (number of agents/objects, clutter).
- Extending rule sets: CSF currently grounds “natural-language safety rules” in reference trajectories 1. Extending rule coverage and managing interactions between many rules will be an important systems challenge.
- Model evolution: CSF is designed for pretrained generators 1. As you swap out motion models, you’ll need pipelines to regenerate safe/unsafe references and validate that the affine safety values still behave as expected.
- Standardizing scene-triggered safety benchmarks: The results on danger-event reduction and benign motion preservation across “explicit and scene-triggered unsafe cases” 1 point toward a need for shared benchmarks that exercise both types of scenarios.
For now, CSF is a concrete demonstration that you can get scene-dependent safety behavior around black-box text-to-motion generators without retraining them, by leaning on reference trajectories and online optimization 1.
What is not documented
Based on the abstract alone, the following are not established:
- The internal architectures of the four motion generators, their sizes, or training data 1.
- The exact process for constructing safe and unsafe reference trajectories (prompting strategies, number of samples, or selection criteria) 1.
- The mathematical form of the affine safety value, including which state variables it depends on and how it is parameterized 1.
- The detailed formulation of the “safe reference tracking CBF-QP,” including objective functions, constraints, and solver choices 1.
- Quantitative breakdowns of the reported “up to 90%” danger-event reduction and “88–100%” benign motion preservation across different tasks, scenes, or generators 1.
- Computational overhead, latency, or hardware requirements for running CSF in real time on the Unitree G1 or in simulation 1.