Using AI in Lean Six Sigma without losing statistical rigour

The genuine bottleneck in most improvement projects is not arithmetic. Software has computed p-values reliably for forty years. The bottleneck is interpretation, writing and judgement: turning a set of outputs into a claim a sponsor will accept, drafting a charter that survives challenge, noticing that the project has no validated root cause four weeks before the Improve gate.

Those are exactly the tasks where a well-grounded language model helps. Given the actual numbers, a model can explain what a Cpk of 0.78 with a 2-gram offset means in business terms, suggest which assumption to check next, and draft the stakeholder sentence that belongs under the chart. It compresses hours of writing into minutes and raises the floor for less experienced belts.

Statistics must be computed deterministically. A language model asked to calculate a control limit, a capability index or an ANOVA table can produce a plausible, confident and wrong number. Plausible and wrong is far more damaging than obviously broken, because it passes casual review.

The correct architecture is strict separation. Deterministic code computes every statistic, chart series and index. The AI receives those computed results as input and produces interpretation only. This is how Ci Flow is built: the tools calculate, and the AI reads the calculation. Ask of any AI feature in improvement software: if the model were switched off, would the numbers change? If the answer is yes, the design is unsafe.

The most valuable AI application in a project is not interpreting a chart; it is telling a team what is missing. A coach that reads the actual project evidence, meaning which tools have been worked, what the metrics say, which phase gates are open and what the deadlines are, can answer 'are we ready for the Analyze gate?' with specifics rather than encouragement.

The critical design detail is transparency. The coach must show what it assessed before it answers, so the practitioner can see that its conclusion rests on the real evidence set rather than on a guess. An assessment you cannot audit is an opinion with better grammar.

Classic decision trees for tool choice, such as 'is your data continuous or discrete?', are useful in training and clumsy in practice, because they ignore everything the project already knows. By the time a team reaches Analyze, they have a process map, a baseline, a stratification and possibly a Pareto. A recommendation that reads that context is more useful than a questionnaire that ignores it.

The design rule is that the recommendation is always a suggestion with reasoning, never an automatic selection. The practitioner chooses. Removing the choice removes the learning, and a programme that cannot explain its tool choices to an auditor has traded competence for convenience.

Set three rules before you deploy AI across an improvement programme. First, no AI-generated number enters a deck without a deterministic source. Second, every AI interpretation is reviewed and owned by a named practitioner. The model is not an author of record. Third, sensitive data handling and usage limits are administered centrally rather than left to individual users.

With those rules in place, AI stops being a novelty and becomes what it should be: a fast, tireless assistant that raises the quality of writing and the speed of review while the statistical integrity of the programme stays exactly where it belongs, in the calculations.