Evaluation

What to keep in mind

• Every block reference follows the same evaluation sequence.
• Definitions store reusable behavior, while references execute that behavior in context.
• Parameters resolve first, then variables, then active state selection.
• Realization produces geometry, nested blocks, directives, and outputs from one evaluated context.

Definitions execute through references

Every block reference follows the same evaluation sequence, regardless of where it appears in the system.

Evaluation is the runtime that transforms definitions into actual drawings and outputs.

Block definitions define behavior. They contain the parameters, variables, states, lookup tables, and geometry that describe how a block behaves.

Block references execute behavior. When a reference is placed on a sheet or nested inside another block, the engine resolves its inputs and evaluates the definition in that instance context.

Evaluation executes those relationships. This is why one definition can produce many different results. The authored behavior stays the same, but the evaluated result changes with the inputs and surrounding context of each reference.

Why evaluation order matters in practice

• It prevents geometry and outputs from being built from partially resolved values.
• It keeps repeated evaluations deterministic across instances and nested systems.
• It matters most when derived values, state selection, and nested assemblies depend on one another.
• It makes debugging system behavior possible because the runtime flow is consistent rather than ad hoc.

In a coordinated panel system, evaluation order is what keeps sizing logic, selected variants, geometry, and output rows aligned instead of allowing them to diverge.

Evaluation is the runtime bridge

• Authored in Blocks: block definitions define behavior and references carry instance context.
• Related by Logic: logic defines relationships that evaluation will execute.
• Defined here: evaluation executes those relationships in runtime order.
• Extended by Composition: nested references introduce stacked contexts during runtime.
• Reflected in Outputs: outputs are derived from evaluated instances after realization.

Parameters to variables to state to geometry to outputs

Evaluation follows a deterministic runtime flow. Parameters on a block reference resolve first, including explicit values, inherited values, defaults, and any valid parameter-to-parameter dependencies.

Variables evaluate next from those resolved inputs. After the values for the instance are resolved, the active state is determined. Only then does the engine realize geometry, nested blocks, and output data from that resolved context.

• Resolve parameters.
• Evaluate variables.
• Select active state.
• Realize geometry and nested blocks.
• Generate outputs.

Computed values come before generated results

Resolution is the phase where the system computes values. Parameters settle to concrete inputs, variables are derived, and the active state becomes known.

Realization is the phase where the system generates results from those computed values. Geometry is built, nested references are evaluated in context, injection applies resolved values into authored content, and outputs are produced from the realized instances.

This distinction matters because a system can resolve correctly before it visibly realizes anything. If realization were mixed into early value computation, the engine would be forced to build geometry before it fully knew what the instance meant.

Each block reference is a runtime executing the same logic

The definition is like authored behavior waiting to run. Each reference is a runtime instance that executes that behavior with a specific set of inputs and a specific parent context.

This mental model explains why one definition can produce a narrow instance, a wide instance, or a nested assembly without changing its authored logic. The runtime context is different, so the realized result is different.

Deterministic execution, nested context, and injection placement

Evaluation is deterministic. Given the same authored definitions, the same inputs, and the same surrounding context, the engine resolves the same result. This predictability is essential because drawings and outputs both depend on the same execution path.

Nested evaluation introduces an additional subtlety. When a child block reference is realized inside a parent, it does not evaluate as a disconnected object. It evaluates in a context that already contains the parent-resolved values available to it.

Injection belongs during realization rather than during pure logic definition. Logic defines relationships. Evaluation executes those relationships. Injection then applies the resolved values to geometry, text, directives, and output-facing fields while the instance is being realized.

How authors work with the runtime flow

• Resolve variation through parameters first so downstream logic has stable inputs.
• Use variables to consolidate derived values before state selection and realization.
• Design nested assemblies so child blocks consume a clear parent context instead of duplicated formulas.

A control power assembly is a concrete example. Parameters such as load and voltage resolve first. Variables compute sizing values. State selection chooses the correct variant. Realization then produces geometry, injected labels, and outputs from that resolved state.

For the definition layer behind this flow, continue to Logic System. For exact syntax consumed by evaluation, use Reference. To see the runtime flow in a working document, use Help or open the Control Power Panel example.

Keep exploring