informat-expression

Informat Expression

used to convert natural language rules into UEL expressions executable on the Informat / 织信 platform.

Reading order first

Read in this order:

1. references/expression-rules.md
2. references/expression-boundaries.md
3. references/expression-sdk.md
4. references/expression-examples.md

If complete function definitions,User.*/Date.* edge capabilities, or DSL details are needed, then consult:

• ../../sources/informat.expression.md

If the user requests example assets, archive locations, or "show an example", first consult:

• ../../examples/generated_expressions/

Applicable scenarios

Prioritize for these requests:

• Approval conditions
• Transition conditions
• Instance name expressions
• Auto-complete conditions
• Field formulas
• Expressions in forms, dashboards, and API return values
• Requests like "please give me a ${...} rule"
• Need to determine "whether this should use an expression or a script"

If what the user needs is script code, automation JavaScript, or platform script logic, use instead informat-script。

Hard constraints

• Expressions must use ${} wrapping.
• ${} Content outside
• Do not use +, only use String.concat(...)。
• Array literals are prohibited; use instead Array.of(...)。
• Prohibit output of JavaScript-style .map(...)、.filter(...)、.reduce(...), arrow functions, and object literal inference.
• DSL functions that explicitly exist in the source documents may be used, for example Array.map(list, key)、Array.filter(list, key, value)、Array.join(...)。
• Only expression objects and functions known from the source materials may be used.
• For division, consider the divisor being 0 will throw an exception.
• Reserved keywords must not be misused as ordinary identifiers.
• Date.datePart(..., 'month') In , January corresponds to 0，day_of_week In , Sunday corresponds to 0。

Two hard rules

1. String concatenation

Incorrect:

${ 'A' + 'B' }
${ name + '-' + code }

Correct:

${ String.concat('A', 'B') }
${ String.concat(name, '-', code) }

2. Array construction

Incorrect:

${ ['a', 'b'] }
${ Array.first(User.usersWithRole(['researcher'])) }

Correct:

${ Array.of('a', 'b') }
${ Array.first(User.usersWithRole(Array.of('researcher'))) }

Output format

By default, output in this order:

1. Final expression
2. If necessary, add one sentence of applicable explanation or DSL alternative syntax
3. When the user requests example assets or archive locations, add the relevant file paths
4. If it cannot be implemented, list the reasons separately and suggest switching to a script

If the user requests multiple candidate expressions, provide multiple valid versions and explain the differences.

Example assets

When the user requests viewing, citing, or explaining example assets, use the files under examples/generated_expressions/YYYY-MM/ :

• String concatenation / approval number:examples/generated_expressions/2026-03/string_concat_example.txt
• 0-based month determination:examples/generated_expressions/2026-03/date_month_zero_base.txt
• User.usersWithRole and Array.of：examples/generated_expressions/2026-03/array_of_user_role.txt
• JS-style .map(...) counterexample:examples/generated_expressions/2026-03/js_style_error.txt

If the date or month directories change, first use the actual files in the current repository under examples/generated_expressions/ as the basis.

When not to keep forcing an expression

In the following situations, prioritize stopping and explaining the boundaries, then suggest switching to a script:

• Needs complex flow control, complex side effects, or multi-step orchestration
• Needs JavaScript-style loops, arrow functions,.map/.filter/.reduce
• Need to call a function that does not exist in the source material
• Need an array literal or object literal to complete the core logic
• Unable to confirm whether a certain object or function actually exists

Self-check list

Check before output:

• Was it fully used ${}
• Was JavaScript syntax misused
• Was string concatenation written as +
• Was an array written as a literal
• Was JS .map/.filter mistakenly treated as an expression DSL
• Were JS higher-order functions or arrow functions misused
• Is there a risk of division by 0
• Were the 0-based values of months and weekdays handled correctly
• Were the limitations clearly stated when implementation was not possible