What we were testing ?
Process analysis appears to be a natural GenAI use case: provide process documentation, reconstruct the workflow, identify inefficiencies and propose an AI-enabled future state.
The real problem emerged when we challenged how much of that reconstructed workflow was actually known, and more importantly real.
What we observed ?
When assessing a process or workflow, any incomplete evidence can create ambiguity because a missing step can mean:
- the activity does not exist;
- the activity exists but was never documented;
- it occurs only in exceptions;
- users bypass the prescribed process;
- a tool limitation creates additional work;
- poor data creates an apparent process problem.
An LLM can produce a plausible interpretation for each of these situations. However, plausibility is only useful for generating a hypothesis : it cannot be enough to establish the factual process baseline.
If the system fills missing information through inference and then redesigns the reconstructed workflow, it may end up optimising a process that never actually existed !
What we changed
Two major elements had to be separated: reconstruction versus optimisation.
The working sequence became:
Evidence
↓
Factual AS-IS
↓
Human validation
↓
Diagnosis
↓
AI suitability assessment
↓
Potential redesign
Process extraction became an important visible step rather than an invisible intermediate result.
Each extracted step exposes information such as:
activity
role
system
decision point
description
This allows the reconstructed process to be challenged before downstream scoring or redesign begins, while AI inference remains useful for identifying:
- possible missing activities;
- inconsistent handoffs;
- unexplained decisions;
- suspected exceptions;
- opportunities for automation or augmentation.
But we retain them as hypotheses until they are validated.
What we retained ?
The practical rule is simple:
AI can propose what might be missing, but it should not silently convert that proposal into process fact.
During assessment, information therefore needs to be treated differently depending on its status.
A - Evidence-backed
The information is directly supported by the available material and can contribute to the factual baseline.
B - Inferred
The system has identified a plausible missing step, relationship or explanation.
It can generate a question or hypothesis, but cannot yet be treated as part of the AS-IS.
C - Validated
The proposed interpretation has been confirmed during review and can now become part of the baseline.
This creates a useful operating rule:
Evidence-backed
+
Validated
→ baseline
Inferred only
→ hypothesis / validation required
This distinction becomes critical because every later assessment - friction analysis, AI suitability, automation potential and redesign - inherits the quality of the baseline.
A wrong baseline does not simply create a wrong process map; it contaminates everything that follows.
Takeaway
Inference is valuable during process assessment. Redesign should only begin once a sufficiently reliable baseline exists otherwise AI risks optimising its own reconstruction, which would then turn a plausible hypothesis into a very convincing hallucination.