Symptom
A rule that sets a variable inside a conditional branch fails validation or fails at runtime with EX005178.
A typical case looks like this: the rule checks a driver value and assigns one of two text values to a placeholder variable, and the engine rejects the assignment because the variable is defined outside the rule.
The same error code also appears in a second, unrelated situation: the rule uses a conditional ternary expression (condition ? a : b), which the Cloud Native rule language does not support.
Cause
The rule language restricts where assignments can happen.
A rule can only assign to variables that live in a scope the rule is allowed to write to.
When the target variable is defined outside the rule, the assignment violates that scope restriction and the engine reports EX005178.
The ternary case is a different defect behind the same code: an unsupported language feature fails parsing, and the parser surfaces it under the same error number.
This is why two people can search for EX005178 and find advice that does not match their situation.
Read the full message text and the reported line before assuming the cause.
Fix
For the scope case, restructure the logic so the assignment happens in a supported scope. Keep the condition and the assignment as separate plain statements:
if (levelOfAppeal = "FINAL") then
Placeholder_Text = "a final adverse decision";
else
Placeholder_Text = "an adverse decision";
endif
If the variable genuinely must be owned outside the rule, do not try to weaken the scope check. Move the assignment to an event or formula timing point that is allowed to write to that variable, or return the value as the rule result and let the caller store it.
For the ternary case, replace the expression with an ordinary if/else block. Run a syntax check after each change and test both branches with real driver data, not only the branch that failed.
Test scope and compute timing together
Variable scope errors in rules usually show up late, after a design that worked in a quick preview meets the full data model. When you restructure the assignment, verify the fix against both the smallest input that reproduces the error and a normal production-sized input, because compute timing differs between the two.