BEX

Why computation is represented as data#

A source-code string introduces parser versions, module resolution, whitespace rules, imports, and host-language escape hatches. A BEX program is a Blue node whose operators, literals, reads, statements, functions, and intrinsic dependencies are explicit content.

That makes program identity compatible with BlueId.

Execution boundary#

BEX runs against controlled immutable context such as the current document, incoming event, root processing event where exposed, constants, previous step values, and registered deterministic intrinsics.

It does not receive an ambient network client, wall clock, random source, mutable processor, payment rail, or hidden model inference.

Typical uses#

• deterministic request validation;
• calculated patches;
• conditional event construction;
• small business rules;
• lifecycle transition logic;
• pure transformations over document and event state;
• policy checks whose inputs are already declared.

Result as data#

A BEX function can return a value, append changes, and append events. A workflow step or processor then decides how those effects are applied. BEX does not mutate the Root directly.

Intrinsics#

A static intrinsic is selected by exact BlueId. The host must support that identity and implement it deterministically for the declared profile. A friendly function name alone is not a portable capability declaration.

Gas and limits#

Execution charges deterministic gas. Compilers and hosts also need limits on nesting, expression count, functions, literals, pointers, collection traversal, and output size.

BEX should be used where reproducible computation is valuable, not as a general-purpose replacement for external providers.