Every configured platform has two descriptions of the work running on it. The first is the configuration: routing rules, validations, flows, case types, and the automation that was built and signed off. The second is the behavior: what people do, in what order, with what tools.
When organizations modernize, most programs treat the configuration as the requirement and observed behavior as anecdote. The difference between the two descriptions is the more useful input to the design.
Four Kinds of Variance
Comparing configured rules with observed execution sorts the differences into four groups. Each one is a design decision the new platform should make explicitly rather than inherit by default.
Rules no longer in effect. Automation was built and is now routinely bypassed. Each case is either a rule to retire or a behavior to correct, and without observation there is no way to tell which. If people bypass a validation because it is wrong, carrying it into the new platform repeats the error. If they bypass it because the process is under pressure, retiring it removes a control.
Steps governed by no rule. These are steps people perform consistently that appear in no flow, validation or procedure. A new platform omits them because nothing in the configuration says they exist, yet they are frequently the steps that keep the process working.
Rules that generate work. Validation and routing logic can produce rework by design, which shows up as reopens, transfers and escalations that can be traced back to the originating rule. A platform that copies the rule copies the rework.
Divergence between intent and outcome. In some cases what was requested and what was resolved disagree, for example when the category selected at the start does not match how the case ended. The routing model for a new platform should be derived from these cases rather than from the original taxonomy.
Why Observation Resolves Design Disagreements
Design reviews are where requirements get tested. Someone asks why a rule is being carried over or why a step has been dropped, and the answer needs more support than recollection.
Evidence changes the discussion. If a step is performed in the large majority of cases and appears in no procedure, the question becomes whether the new design should include it. If a rule is bypassed on most executions, the discussion shifts from opinion to what the bypass indicates. A requirement traced to observed execution can be defended in review, which is harder to do for one traced to a workshop.
The screen above is from the Pyze demo environment. It chains the dominant application-to-application transitions observed across real cases and shows how deeply each application is captured. Specific case journeys then appear as variants against that standard path. This is the observed side of the comparison, and it can be laid directly against the configured side.
Output of the Comparison
The output is a set of decisions, each with its evidence:
- Carry over, because the rule is followed and the outcome is good.
- Retire, because the rule is bypassed and nothing breaks.
- Correct, because the behavior is wrong and the rule is right.
- Add, because a step is performed consistently and no rule exists.
- Redesign, because the rule generates rework.
Each line links to the cases behind it, so a reviewer can inspect them. This traceability reduces the need to revisit the requirements document at each stage of the program.
Applicability to Any Configured Platform
The method is not specific to one vendor. A Pega estate, a Salesforce org, a case management tool and a bespoke workflow engine all hold declarative rules that can be read directly, and in all of them people use the system in ways the rules did not anticipate. The steps are the same: extract the configuration, observe the execution and score the difference.
What changes is the volume. Doing this by interview across hundreds of flows does not scale, while doing it from the platform and the observed behavior does. Workshops can then be used for confirming findings and making decisions.
Where to Go Next
- See how Modernization Intelligence reads rules and behavior together.
- Read the Pega-specific discussion: Reimagining a Pega Estate Starts With Requirements Recovery.
- Learn how the layers fit on the Systems, People, Action page, or book a demo.