Rules and calculations

Use Python programs to author a rule as readable Python and reopen its original source. The embedded editor provides indentation, syntax highlighting and application-aware suggestions. The fixed server validates and executes the submitted program.

Save and validate

1. Open Create a new program version. Choose a stable program ID, version, entry point, approved environment and parameter schema. Enter Python source; the scoped multiplication example uses dimension members and hierarchy descendants.
2. Choose Save and validate. A source syntax error is returned against the code. Accepted source starts an automatic Validation task; wait for its terminal result. Saving a row does not by itself establish that validation passed.
3. Resolve all diagnostics. They identify the source location, error code and expected syntax or type when available. After an immutable source version has been saved, use Edit as next version for corrections. Only successfully validated code can be activated or executed.

Test without changing business data

1. Read the saved version and provide its parameters. Choose Test version while it is inactive.
2. Follow Test status and inspect the completed Impact result. Check source/version, parameters, baseline revisions, full coordinates, before/after values, differences and affected counts. Later supported steps see earlier proposed effects. Unsupported operations fail explicitly before effects are published.
3. Use result pages to inspect the complete bounded result. A failed or partial computation is not a passed Test. Tests do not update business facts or activate the rule. Results expire after 24 hours; a new Test uses a new request.

Activate and run

1. Choose Activate version when the exact valid version is permitted to affect business data. This action does not run it. Editing source produces another inactive version.
2. Read an execution authority with the required build and run permissions. Run version builds a fresh Plan for the active source and current parameters, then submits that exact sealed Plan under the selected authority.
3. Inspect workflow progress and its actual publication checkpoints. A single scoped transformation is atomic. A multiunit program can retain earlier committed units if a later one fails; its report identifies those outcomes.

Run evaluates current inputs. A prior Test is evidence about its recorded baseline, not permission to apply different effects under the same result identity. Test artifacts cannot be submitted as runnable Plans. If input changes matter, Test again before running.

Recover an interrupted interaction

While this view remains open, Resume uses the original request keys and accepted build/workflow IDs. Navigating away stops automatic chaining. After a reload, inspect the accepted work in Monitor before creating a new execution request. Repeating a completed operation with its original key reconciles that operation; explicitly running again is a new request.