References and expressions

Expressions appear in entity values, mutation requirements and transformations, and task predicates. The parser preserves their source spans, structure, and precedence.

References

A concrete entity reference starts with @ and a quoted identity:

@"cargo-42".properties.mass

A mutation role reference starts with @ and a role identifier:

@payload.properties.mass

A component reference identifies one named value:

@"van-110".description.plate
@"van-110".capacities.payload_mass
@"van-110".conditions.readiness
@"van-110".properties.fuel_volume
@"van-110".traits.vehicle

References cannot stop at a component or continue past the value name. Mutation definitions are reusable templates, so their references must be role-rooted. The observe, share, and reserve mutation sections also accept a whole role such as @vehicle; concrete entity references are rejected in every mutation section.

Current change generation preserves component references symbolically. It does not check that an entity, role, component, or value name exists.

Evaluation values

An evaluation value belongs to a mutation role:

@vehicle.$distance
@vehicle.$duration

Only distance and duration are accepted. A concrete entity cannot be the root of an evaluation value. OSL does not compute these values; they remain symbolic inputs for future evaluation and planning systems.

Values and calls

The expression parser accepts:

• condition symbols such as ready;
• quantities such as 12 kg;
• component references and role evaluation values;
• the location(...) call;
• parenthesized groups;
• unary + and -; and
• binary arithmetic and comparison operators.

@van.properties.fuel_volume > 0 l
@van.$distance * @van.properties.fuel_per_distance
(1 kg + 2 kg) * 3 kg

Quoted strings and plain unitless numbers are not general expression values. Calls are not generic: location(...) is the only recognized call name. Location arguments are captured as source text and checked during change generation. Their operational lowering has known defects described in Current limitations.

Condition symbols are resolved in the namespace supplied by a condition reference in the same expression. For example, ready in @vehicle.conditions.readiness = ready resolves to the ready variant of the readiness condition. A condition symbol without that context cannot be materialized into the digital twin.

Operators and precedence

Operators bind in this order, from strongest to weakest:

Operators with the same precedence associate from left to right. Parentheses override precedence.

The parser supports all operators in the table. Change generation supports binary and grouped values but does not safely lower unary values yet. It does not type-check expressions, compare units, or require task and requirement expressions to produce Boolean values.