Core concepts

Organizations and projects

Your company is an organization in Edmund. Inside it you create projects. A project maps to one real thing on your shop floor — a single machine or a single production line. Keeping one project per machine is what lets Edmund give precise answers: when you ask a question, it looks only at the knowledge attached to that machine, not the whole plant.

Every project has its own QR code. Print it, stick it on the machine, and anyone can scan it to open that project directly — no hunting through menus. An administrator can download all the codes at once to label a line in one pass.

Knowledge: the four sources

A project is only as useful as what you put into it. Edmund draws on four kinds of knowledge, each added inside the project:

• Documents — manuals, datasheets, schematics and other files (typically PDF). After upload, each document is indexed so Edmund can search inside it and cite the exact page. How to add documents →
• PLC programs — exported program files. Edmund reads the structure, logic, tags and alarms so you can ask about them in plain language. This feature is still alpha.
• Data sources — a live, read-only connection to an operational database, so Edmund can answer questions about current and historical values, not just documents. How to connect data — and stay safe →
• Maintenance journal — short entries describing a problem and how it was solved, with photos. Over time this becomes the plant’s institutional memory, and Edmund can draw on it.

Chat is always inside a project

Edmund’s chat is scoped to one project at a time. When you open Chat, Edmund first asks which project you mean (scanning a machine’s QR code does this for you). From then on, every answer is grounded in that project’s documents, PLC programs, data source and journal.

This is deliberate. A question like “why is the line tripping on overtemperature?” only has a useful answer in the context of a specific machine. Scoping the chat keeps answers relevant and citable.

How Edmund answers

Edmund is built for trust on the floor, so its answers behave differently from a general chatbot:

• Grounded in your data. Answers come from the project’s own knowledge — not the open internet — and Edmund points to the source page, document, tag or row it used.
• Honest when it doesn’t know. If the knowledge to answer isn’t in the project, Edmund says so rather than guessing. Usually that means something still needs to be uploaded.
• Suggested follow-ups. Each answer offers next questions, so you can dig in without knowing the right phrasing.
• Rateable. Every answer has a thumbs-up / thumbs-down. That feedback is how experts and admins find weak spots and improve the knowledge behind the answers.

What Edmund can and can’t do today

We’d rather set expectations than oversell. As of now:

• Edmund answers from a project’s documents, PLC programs, connected data source and journal — and only from what’s actually present. If a document failed to index (it shows No text instead of Indexed), Edmund can’t read it yet. How to fix that →
• PLC programs is an alpha feature: you can upload and index a program, but there’s no deep drill-in view of it yet.
• Data sources are powerful — Edmund writes and runs database queries for you — which is exactly why the connection must be read-only. Read the safety note before connecting →

Who can do what

Not everyone needs every capability. Edmund has three roles — administrator, expert user, and user — that decide who can chat, who can manage knowledge, and who can change settings. See the roles and permissions →