Process Discovery
Part of Automation governance
Reviewing changes to automated decision rules
Compare old and new rule outcomes, confirm authority, check boundary cases and record the release and its effect on pending work.
Review a proposed rule change by comparing current and proposed outcomes for the same kinds of case. The business owner approves what the rule means. The technical owner establishes how the approved version will run and be checked.
A changed threshold or eligibility condition is a business change, even when it takes one configuration edit.
Describe the change in cases
Record the current and proposed rule, the reason, the effective time and the source of authority. Identify affected cases and decide whether open cases stay under the old rule or move to the new one.
“Update routing logic” is too vague for an approver.
| Case condition | Current outcome | Proposed outcome | Question to settle |
|---|---|---|---|
| Meets normal criteria | Current route or decision | Intended route or decision | Is this still authorised? |
| Falls on the changed boundary | Existing result | New result | Which cases change, and why? |
| Has missing or conflicting information | Current hold or exception route | Proposed route | Could uncertainty now appear to meet the rule? |
Use the organisation’s actual rules to fill the table. It is a review aid, not a description of an existing system.
Check impact and authority
Identify the inputs, any changed upstream definitions and the downstream action the rule permits. Ask whether the change could affect access, a financial commitment, a person’s interests or the use of personal information. Involve the responsible specialist where needed.
If personal information is used, the privacy owner should assess obligations relevant to the entity and decision.
Record who requested the change, who approved its business meaning, who assessed implementation and who authorised release. An urgent path still needs an owner, a reason and later review.
Preserve the superseded rule and its effective time so a past case can be interpreted against the version that applied.
Key Change Management Metrics
- Change requester
- Identified individual or team
- Business approver
- Approved meaning of rule change
- Implementation assessor
- Technical validation completed by specialist
- Authorised release owner
- Final sign-off for deployment
- Superseded rule preserved
- Version and effective time retained for audit
Define checks before release
Use safe cases on both sides of the changed boundary, plus a case with missing or conflicting input and a case already in progress. State expected outcomes before checking the implementation.
Verify a resulting business state in the destination where the rule causes an action. Check that cases outside the approved population keep their existing route.
The release plan should state how the version is activated, who inspects early outcomes, who may halt it and what can be restored.
Reinstating an earlier rule cannot undo decisions or writes already made; affected cases need a separate review.
Close the change
Compare early cases and exceptions with the approved outcomes. Record differences, affected case references and the owner’s response.
Update the automation inventory with the rule version and linked change record. Hold further affected work under the agreed stop procedure if an unexpected consequential outcome appears.
