Without your knowledge it is a chat. With it, it is a colleague.
The same question gives two companies two different answers, if the source is theirs. Process documents, product files and company standards are not “a bit of extra context”. They are the difference between generic advice and an answer you can use. The three shelves are below. They are not mixed. You will recognise the AI answer that sounds smart and is wrong for your process.
Three kinds of documents, not one pile
Product development is rarely one discipline. Mechanics, electronics, firmware, software, test, quality, purchasing and manufacturing depend on each other. A change in one part of the chain hits several others. Colleag.ai therefore keeps three kinds of documents apart: what applies to the company, what describes how the company works and how the development process runs, and what applies to a single product. Otherwise a purchased ISO standard lands in the same folder as a product specification, and it is no longer clear who owns what.
Company documents
Purchased standards and company rules: ISO, IEC, design rules, the quality manual. They apply regardless of product and regardless of discipline. They set the frame. They do not describe this article’s BOM, and they do not describe how a team brings up a new product.
Process documents
They describe how the company works and how the product development process runs, from requirements and design through test, purchasing, manufacturing and release. In English they are often called SOPs, standard operating procedures. They are not a hardware list. They say how disciplines work together, who approves, which documents must exist, and how a change is handled when it hits more than one discipline.
Product documents
Requirements, specification, BOM, tests, drawings and interfaces for a single product. They follow the article. They should match the process documents and the company standards, but they are not the same as the procedures and not the same as the ISO file.
Process documents as the way you work
Product files as working knowledge
The company standard that does not live in someone’s head
Live ERP as the fourth layer
Key benefits
- AI colleagues that understand your specific processes and standards
- Decisions grounded in your product data, not generic knowledge
- Institutional knowledge preserved independently of personnel changes
- Continuously improving context as your team works
- Consistent application of your company standards across all disciplines
Read more
What separates a generic chatbot from Colleag.ai? Context. Process documents, product files, company standards and live Monitor in the same answer. Without them the model guesses. With them it can say which suppliers in China deliver 991203 and whether dual-source is required by your procedure.
Without process documents, product files and live Monitor, a model guesses. With the shelves kept apart it can say which suppliers in China deliver 991203 and whether dual-source is required by your procedure, with a source, not “check purchasing”.
Company context is not a chatbot prompt you paste in. It is files, procedures and a read ERP that follow the question. That is why two companies that both “have Monitor” get different answers.
How this differs from ERP, PLM, LCM and project systems
- ERP
- ERP is the third layer, fetched when the question is asked, not a nightly export.
- PLM
- PLM is a source. It is not the colleague that reads the process document and the drawing together.
- LCM
- LCM gives status. It does not give how you do the work.
- Project management systems
- The project tool remembers tickets. It does not remember why R1A was approved.
What Colleag.ai does here that those systems do not
- Process document, product file and live ERP in the same sentence
- Answers with a source, not with a probability
- Knowledge that stays when the person leaves