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 AI
Foreman
On line 3 we're getting scratches on the visible part after painting again, just like last month.
Best Practices · in a few seconds
Understanding

You're reporting a recurring increase in scratches on visible parts from line 3 after the painting process.

Similar cases
  • 2026-03-12 (line 3) · solved by J. Novák. Cause: wear of the guide rail before the paint box. Result: rail replaced, problem solved for 4 weeks.
  • 2025-11-04 (line 7) · similar defect. Cause: compressed-air contamination. SOP: check the filter every 14 days.
Proposed solution

Hypothesis: guide-rail wear (high probability given the 4-week cycle).

  1. Inspect and replace the rail.
  2. Add a preventive check to the line 3 checklist at a 4-week interval.
  3. Check compressed-air filtration (from the November case).
The foreman confirms the proposal → action items are written as 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&M 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