AI · Best Practices · in production

Company memory that doesn't leave with people

Your best process engineers are in the heads of people who may have left long ago. From your records, solved cases and closed findings we build a memory the whole plant can rely on. Best Practices works as a virtual senior process engineer you always have on hand.

Standalone module in productionChat interface · structured output with sources · approval workflow

Works exclusively on your history and data

1
standalone module in production
5
steps from question to a verified solution
100 %
of outputs with a traceable source
Problem

Organizational amnesia costs shifts

  • An operator reports a defect and looks for the solution in the head of the nearest senior.
  • When the senior is on vacation, the problem waits.
  • When they retire, the know-how leaves with them.
  • SOPs, audit records and historical solutions exist, but nobody has time to search them.
  • The same defect is solved three times a year, a different operator each time, each time from scratch.

The cost: repeated searching means lost shifts, inconsistent procedures between lines, a new process engineer has nowhere to gain experience, and at an audit you can't explain why you solved it that way.

How it works

Five steps from question to a verified solution

1
Describe the problem
In your own words, like at the morning meeting. No forms, no categories.
2
The module understands context
It grasps what you're working on, at which workstation and with which product.
3
It finds similar cases
It searches the internal solutions database, closed findings, SOPs and history across plants.
4
It presents a proposal
A structured output: understanding of the problem, similar cases, proposed solution.
5
You decide
Status draft → proposed → approved → implemented. Nothing happens without your approval.
Scenario in practice

Morning shift, a recurring defect

iDomino - Best Practices: proposed solution for a reported oil leak on the LIS-400 press
The Best Practices module in the app · a proposed solution with recommended steps and feedback.
iDomino AI
Operator
On LIS-400 (workstation LISOVNA - HL II) hydraulic oil is leaking. I don't know yet whether it's a hose, a coupling, the piston rod or a valve.
Best Practices · in a few seconds
Understanding the problem

The operator reports an oil leak at workstation 2. LIS-400, station LISOVNA - HL II, in a hydraulic system component. It is not yet specified whether it is a hose, a coupling, the piston rod or a valve.

Similar cases
  • 2026-02-18 (LIS-250) · solved by M. Dvořák. Cause: a loose quick coupling on the pressure branch. Result: retightened and the fitting replaced, leak stopped.
  • 2025-09-30 (LIS-400) · similar defect. Cause: a chafed hydraulic hose near the piston rod. SOP: visual hose inspection during weekly maintenance.
Proposed solution

Hypothesis: the closest matches are leaks from hydraulic joints, hoses or the piston rod. If the same leak point is confirmed, it makes sense to first check the tightening of the joints, the condition of the fittings and possibly a damaged hose or seal.

  1. Check the hydraulic joints, hoses and quick couplings at the leak point.
  2. Verify whether it is a loose joint or a damaged seal.
  3. If wear is confirmed, replace the hose or fitting and write the result back into Best Practices.
The operator marks whether the solution helped → the confirmed procedure is written into company memory and action items become tasks with owners and deadlines.
Scenario B

New process engineer, unfamiliar production

A junior started a month ago, the senior left. Instead of fumbling, they ask the module and get a data-backed proposal with links to historical cases. They learn faster and make fewer mistakes.

Scenario C

Audit and compliance

“Why did you solve the defect that way?” Instead of “because Pepa told us” you have a documented chain in the system: problem → proposals → approver → implementation → result.

Recommendations

Do and don't

✓ Do
✗ Don't
Write problems descriptively, not as a question. “Scratches on the visible part from line 3 after painting” works better than “why is it broken?”
Don't expect the module to solve something with no data in the internal system. It works on your history, not the internet's general knowledge.
Close cases with the “implemented” status and a short note on the result. That feeds future similar cases.
Don't use the module for decisions that require measurement or testing. When it needs a gauge or a lab, go there.
Keep the internal knowledge base up to date: SOPs, defect photos, procedures. Only then can the module find relevant citations.
Don't take the first proposal as final. The “proposed solution” is a hypothesis, not an SOP. A process engineer always reviews it.
Teach the module your vocabulary. If your term for a defect is “fly”, add it to the glossary. The module will learn it.
Don't skip the approval step. The “implemented” status isn't set automatically - a human must confirm it.
During an audit, use the module as a decision trail. Every proposal has source citations.
Don't treat the module as a replacement for the process-engineering department. It's an assistant, not a substitute for people.
Guardrails

What the AI does NOT do

Just as important as what the module can do is what it must not. Without these safeguards, the assistant would become a risk.

It doesn't decide for you
The module proposes, people approve. Every action carries the signature of a responsible person.
It doesn't cite without a source
Every similar case has a traceable citation: who solved it, when, with what result.
It doesn't make things up
If there's no relevant precedent in the knowledge base, the module says so. No hallucinations.
It doesn't fake certainty
A proposed solution is a hypothesis with a reason, not an order. You see the level of certainty.
It doesn't leave your environment
Your data stays with you. No sharing between customers.
It doesn't overwrite production systems
The module only reads and proposes. Changes in production are made by operators and process engineers.
Input data

What the module draws on

Knowledge base SOPs, process procedures, manuals.
Best Practices history Closed cases in the “implemented” status and a note on the result.
Action plans Closed projects, measures and results from the Action Plan module.
Reports from TPM and Production Management Faults and scrap as context for the problems being solved.
Terminology glossary Your internal terms and abbreviations, kept separately for each customer.
Current context What the operator or foreman is writing and what the workstation is working on.

Technical prerequisite: a deployed iDomino platform with a populated knowledge base and a defined Best Practices workflow. The module improves as the database grows, so you can fill it gradually. Optionally a local AI model for customers with strict data-residency requirements.

FAQ

What we're asked most often

The module starts working from the first closed Best Practice. Value grows with data volume, but even the first 50 cases make a noticeable difference.

Yes. A Best Practice from one plant can help another if you allow that visibility - with automatic translation into each user's native language when you also use the Live data translation module. The default is separation of data between individual customers and plants.

The module understands short, informal descriptions. You don't have to address it as “Dear assistant”. A few words are enough.

Technically days. Realistically it depends on the state of your knowledge base. We help structure it.

The Best Practices workflow connects to your existing task and action-plan system. Commitments and deadlines go into your existing environment; we don't create a parallel store.

Want to see the module in action?

In 60 minutes we'll show you how the module finds a similar case from history and how it becomes company memory.

Book a presentation