Sources: data/reference/json/ccb_eoc_conditions.json data/reference/json/ccb_eoc_effects.json tools/json_api/contract-inventory.schema.json tools/json_api/generate_contracts.py tools/json_api/test_generate_contracts.py src/condition.cpp src/npctalk.cpp src/effect_on_condition.cpp src/effect_on_condition.h tests/eoc_test.cpp doc/JSON/EFFECT_ON_CONDITION.md commit c663ceb2c1bd api-contract

EOC variables and context

The machine inventories prove that the common variable parser recognizes these scopes:

Scope	Boundary
u_val	A variable name associated with alpha routing; the prefix does not prove a concrete talker type
npc_val	A variable name associated with beta routing; also historical naming
global_val	The global variable namespace
var_val	An indirect variable reference
context_val	A context value passed through the current EOC/dialogue call chain

The inventories also prove use of value helpers including value_or_var, value_or_var_pair, dbl_or_var, duration_or_var, str_or_var, translation_or_var, and eoc_math. They do not prove that every condition or effect accepts every scope or value type.

Context discipline

• Treat context_val as a call protocol: writer and reader must agree on name, type, and lifetime.
• Before nesting an EOC, check whether the call interface forwards variables; do not assume every effect propagates context automatically.
• For EVENT EOCs, inspect how event fields map into context before consuming a key.
• Prefix mod variables stably to avoid collisions with core or other mods in global scope.
• Validate expression, string interpolation, and structured variable-object parser paths separately.

The handler-level variable contract remains unclassified for 272 of 275 conditions and all 306 effects. known_global_scopes in generated reference is a global parser capability, not a per-key allowlist.