How Decision Making Evolved
evolution
/ˌiːvəˈluːʃ(ə)n,ˈɛvəluːʃ(ə)n/
- noun
gradual change over time; in decision systems, a shift from hand-coded rules to models, and back to clear, testable logic.
Decision logic keeps changing. Requirements often move faster than code, and static rules reach their limits. Teams shifted from hard-coded logic to predictive models as business needs grew.
Since the first computers, people have encoded decision logic. The "if X then Y else Z" pattern existed from the start. Leaders saw the value of machines making repeatable decisions, and automated decision making spread.
A manager picked a decision to automate. An analyst mapped the rule flow, approved it, and IT wrote the hard code to run it. At the time, that was a major step forward.
It looked simple. In practice, custom systems were slow to change and expensive to maintain. By the time coding, testing, and deployment were done, requirements had often changed, so automation lagged behind the business.
Hard coding exposed the limits of simple if-then logic. Complex decisions and predictive outcomes were hard to express in static code. Too many variables mattered, and the systems could not handle that complexity well.
Next came rules management systems. These platforms gave users direct control over rules and decision processes. That was a clear shift.
Code still played a role, but the languages were simpler and easier to read. Rules management became a practical way to work. Deployment became faster, and changes to automated processes were easier to govern.
Progress then led to platforms that need no code. Visual interfaces let teams build and manage complex decision logic. The field matured and gave teams more options.
The next phase in this evolution is predictive analytics. More recently, large language models and agentic AI changed how teams prototype decision support and orchestrate tools.
Many important business decisions are complex, with many factors shaping outcomes. Some high-stakes decisions remain manual for that reason. LLMs are useful for exploration, but they are probabilistic and can vary from run to run. In finance and insurance, final decisions must be deterministic and replayable.
Predictive models analyze complex data sets, and statistical methods are used to build them. Specialists often design and maintain these models, which can slow adoption and limit access. Agentic systems can coordinate tasks across services, yet they still benefit from explicit controls.
This is where Automated Machine Learning, or AutoML, helps. Historical data trains a model that can generate future predictions. For example, to assess whether a person can repay a loan, you train on past repayment data to forecast the likelihood of payment or default.
Decision automation has matured. AutoML adds another way to build faster, data-led decision support. Use models and LLMs to inform, and enforce decision logic so every outcome is traceable and auditable.
Frequently asked questions
How should we move an existing lending decision out of hard-coded code?
Start with one decision that changes often or costs significant engineering time to update. Document its inputs, policy rules, exceptions and current outcomes, then recreate the decision logic in a controlled environment. Compare the new version with historical decisions and investigate every material difference before release. Keep the current implementation available until the policy owner approves the change.
How do we decide whether AutoML is worth adding to a credit decision?
Compare the model’s predictions with the current approach on data it did not train on, then estimate whether the improvement changes lending outcomes enough to justify the added cost. Include the work needed to check data quality, monitor performance and retrain the model. If the prediction does not improve a decision the lender can act on, keep the simpler approach.
What should we test before releasing a change to lending decision logic?
Test the revised logic against historical applications with known outcomes, including boundary values, missing information and common exceptions. Compare approval rates and other relevant outcomes with the current version, and investigate unexpected changes before release. Have the policy owner review and approve the change, and agree how to restore the prior version if live results differ from expectations.
How often should we review deployed credit decision logic?
Monitor portfolio outcomes monthly and schedule a formal policy review at least quarterly as a starting point. Review sooner when lending criteria, economic conditions, data sources or observed losses change materially. The right cadence depends on how quickly the portfolio changes and how much harm an outdated decision could cause. Record the reason for each policy change and who approved it.
