How to test a credit policy before production: node tests, debug and promotion

Testing a node in isolation

The first level of testing is the individual node: running it without executing the whole policy and without saving it. The uFlow test configuration lets you load input values in two ways:

The output is the list of output variables with their values and types: enough to validate a matrix, a calculator or a parser without touching anything else.

• Manual entry: you type in the values of the variables the node needs.
• Load from a transaction: with the identifier of a previous transaction you import its variables, subject to the user's permissions and to the institution's data protection policies — useful for reproducing a specific case.

Debugging the full flow, step by step

The second level is debug mode: executing the entire policy node by node, with the variables panel showing how each value changes at every step.

The controls let you step forward, step back, skip a node or run to a specific point. And there is one powerful trick: you can modify the value of a variable mid-execution to force a path — for example, simulating that the credit bureau failed and verifying that the fallback path does what it should, without waiting for a real outage.

The checklist before promoting to production

Before publishing a new version, this is the minimum evidence that should exist:

• Every path exercised in debug mode, including the error and fallback paths.
• Matrices and branches with full coverage: no possible case left without an answer.
• The business edge cases tested with representative cases — anonymized or synthetic data that replicates the structure of the real thing.
• If the change is substantial: champion/challenger over a portion of the traffic before adopting it at 100%.
• Sign-off from whoever is accountable, with edit and execution permissions separated by role.

Promotion and rollback

Publishing creates a new, identifiable version rather than overwriting the previous one: if something goes wrong, rolling back to the prior version is immediate, and the transaction log identifies exactly which decisions the faulty version made.

For workflows with separate environments, policies are exported and imported as a file: what was tested in the test environment is literally what gets published in production. And after go-live, the first hours are monitored: approval rate, errors by provider, and paths executed.