How can a system infer business logic without turning every historical habit into a rule?

Why it matters

Modernising an application, documenting an ERP or giving context to an agent requires understanding the existing business logic. Part of that logic appears explicitly in rules, code or configurations. Another part can only be inferred by relating artefacts, data, incidents and observed behaviour.

The risk consists in automatically turning what the system has done into what the organisation wants to go on doing.

A historical behaviour may be a valid rule, a contextual exception, an operational shortcut, a manual correction, an obsolete decision or a defect. If they all receive the same status, the reconstruction consolidates the past instead of making it examinable.

What we know so far

An inference of logic needs to keep more than a convincing description.

It has to include:

• the specific evidence that suggests it;
• the scope in which it has been observed;
• examples that support it and possible counter-examples;
• the method by which it was extracted or deduced;
• the sources that contradict it;
• its state: observed, inferred, confirmed, rejected, obsolete or unknown;
• the people or tests capable of validating it.

It also helps to separate two maps: the logic the system appears to execute today, and the logic the organisation decides to keep. The difference between the two is not a documentation error; it may be the main object of the work.

Before generalising a rule, we look for variations of context: business unit, product, client, jurisdiction, version, channel, moment in the process or type of exception. Many incorrect inferences arise from leaving out the scope.

What remains open

It remains open how to weigh evidence that expresses different authorities. Executed code may contradict the approved procedure; the data may reflect a recurring practice nobody recognises as a rule; and an expert may describe the intention without knowing all the variants that were implemented.

It also remains open which combination of recurrence, causal explanation and human validation allows an inference to be promoted to a reusable rule without making the review as costly as reconstructing the system by hand.

And how to present the difference between what is observed and what is wanted in a way that helps decide, without automatically legitimising a historical practice or hiding it because it is uncomfortable.