Explainable decision support for manufacturing problems
Diagnose the problem first,
then choose the methodology.
Manufacturing problems look alike on the surface; different problem characters demand different ways of thinking. Manufacturing Decision Engine tries to tell those characters apart and to explain why one methodology fits better than its neighbours.
Natural language is used to structure the problem; methodology selection is performed through explicit, testable decision rules.
No account required. The application interface — diagnostic questions, workspaces and reports — is currently Turkish only; this page is the English overview.
How a decision is formed
Six stagesThe system does not send your text to a language model and ask “which methodology should I pick?”. The text is read only to structure the problem; the selection is made by written, testable rules.
- 01
Problem structuring
Free text is read and mapped onto three-valued diagnostic features (yes / no / unknown). No decision is made here — only fields are filled.
- 02
Discriminating questions
Expected information gain is computed for every unknown feature; the question that reduces uncertainty most is asked. Not a long questionnaire — questions that separate hypotheses.
- 03
Rule evaluation
Explicit rules run against KNOWN features only. Each rule carries a written rationale and states how much it supports or suppresses each methodology.
- 04
Evidence sufficiency
Every methodology declares the independent evidence dimensions it must satisfy. A high score alone does not make a result confirmed.
- 05
Conflict and contest detection
Mutually inconsistent answers, and problems that genuinely carry two characters at once, are flagged rather than hidden.
- 06
Recommendation with rationale
The primary methodology is presented together with supporting evidence, opposing signals, and the reason each alternative ranked lower.
Methodology discrimination
The question that separates themThe value is not in how many methodologies are listed, but in modelling the conditions under which similar-looking ones diverge. Each row corresponds to a rule pair and a regression test.
- RCAorDMAIC
Did the deviation start after a specific date, or has it fluctuated the same way for a long time?
- TPMorTOC
Does the machine limit total system output even when it is not broken down?
- TOCorYalın/VSM
Is performance limited mainly by a single system constraint, or are losses spread along the flow?
- SPCorDMAIC
Is the process capable today — are we looking for causes, or holding a level already earned?
- SDCAorPDCA/A3
Does everyone do the same job the same way; is there a stable baseline to improve on?
- FMEAorDMADV
Are we assessing risk in an existing process, or designing something new from scratch?
- 8DorRCA
Is interim containment needed right now to protect the customer, and is the event recurring?
15 methodologies are supported. The count is secondary information — the discrimination is the point.
Decision engine architecture
Six layersPure decision core
Rules, scoring, question selection and the decision trace live in one dependency-free layer. No language model, no database — the same input always yields the same output.
Bounded role for the LLM
Natural language is used only to structure the problem, phrase questions naturally and write reports. Methodology selection is never delegated to the model.
Evidence profiles
Each methodology defines the independent evidence dimensions required before it counts as confirmed. The same definition drives both the question route and the conclusion gate.
Decision trace and counterfactuals
The chain of answers behind a decision is retained; “what if this answer were reversed?” scenarios are recomputed by the same engine, not narrated by a model.
Execution and verification
The selected methodology hands off to a workspace carrying its own steps. Whether an action was implemented and whether it was effective are separate states.
Regression shield
Rule weights are pinned by case tests that check not only that the right methodology is selected, but that the wrong ones are not triggered.
Regression-tested decision rules
What the tests assertDecision rules are verified by case tests that check both directions: that the right methodology is selected, and that the wrong ones are not triggered. Raising one methodology’s weight must not break its twin’s negative case.
- Customer impact alone must not select 8D.
- A single machine breakdown must not confirm TPM.
- DMAIC must not surface for a stable, capable process.
- A numerically verified bottleneck must support TOC.
- Without queue and starvation evidence, TOC must not be auto-selected.
- Missing standard work must be able to rank SDCA ahead of PDCA.
- Without sufficient discriminating evidence, no definitive result is produced.
- Contested signals must stay visible.
Terminology
TR · EN- Kök neden
- Root cause
- Saha kanıtı
- Field evidence
- Karşı-olgusal test
- Counterfactual test
- Etkinlik doğrulaması
- Effectiveness verification
- Yatay yayılım
- Horizontal deployment
- Metodoloji desteği
- Methodology support
- Karar izi
- Decision trace
- Çakışan sinyaller
- Contested signals
- Kanıt yeterliliği
- Evidence sufficiency
- Ayırt edici soru
- Discriminating question
- Stabilizasyon kapısı
- Stabilization gate
- Kural desteği skoru
- Decision support score
Scope of the decision support
It does not replace expert judgement
Rather than automating the expert’s decision, the system structures problem signals, compares methodology alternatives and makes the rationale visible. When there is not enough discriminating evidence, it says so. Scores shown are rule support, not a probability of success.