CommonKADS Asked About the Work Before the Rules
CommonKADS widened knowledge engineering from rule collection to the organization, tasks, people, and communication a system would support.
A team asks for an expert system because a decision is taking too long. The obvious next step is to find the expert and write down their rules. But perhaps the delay comes from two departments using different definitions, from a missing approval, or from evidence stored where the person making the decision cannot reach it. A good rule engine would execute the wrong solution faster.
The move from knowledge transfer to knowledge modeling made this possibility difficult to ignore. CommonKADS, developed as a structured approach to knowledge-intensive systems, began with the organization and its tasks rather than assuming the first useful artifact must be a rule base. It examined where knowledge mattered in the work, who used it, how people communicated, and which system could help. (CommonKADS, basic principles)
The task is larger than the expert’s answer
Take the component-reuse question from the previous post. An engineer may know how to judge a component. The project team may still need to identify the exact version, find its test history, establish which standard applies, and obtain approval from someone with the right authority. Those steps are not all “expert knowledge” in the narrow sense. Some are information retrieval, some are communication, and some are organizational decisions.
A task model asks what work is being done and what the work requires. An organizational model asks where the task sits and why it matters. A model of the participating people or systems asks who supplies information and who acts on the result. Only then can a knowledge model state which concepts and inferences the proposed software actually needs. These models need not become a ceremonial stack of documents. Their value is that they keep the engineer from encoding one specialist’s answer while missing the process that makes the answer usable.
The method also creates a useful stopping point. If the organization has no owner for the relevant standard, or no reliable record of a component’s version, a program cannot repair that condition by adding more inference rules. The project may need a clearer vocabulary, a revised responsibility, or a better record before it needs AI. A knowledge engineer who finds that out has done valuable engineering work.
Communication is part of the model
The early expert-system arrangement often placed an expert on one side and a program on the other. Real organizations have more participants. A design engineer may propose reuse, a supplier may provide evidence, a quality team may interpret tests, and a project lead may accept the consequence. The system must support the handoffs without pretending every actor shares the same question or authority.
That means a model should sometimes preserve disagreement. One team may use “approved” to mean technically suitable, another to mean approved for purchase, and a third to mean accepted on this project. If software treats these as one status, its tidy data will hide a working conflict. The conflict is not a nuisance to be normalized away. It is information about the task.
CommonKADS connected knowledge analysis with business processes and system development. It did not claim to be all of knowledge management, and the distinction matters. Knowledge management concerns how an organization develops, shares, retains, and uses knowledge across many settings. Knowledge engineering makes selected knowledge usable in systems for defined work. The two disciplines meet when a proposed system depends on the surrounding human practice. (CommonKADS, basic principles)
Once the task and its language had been modeled, another possibility opened. The concepts might serve more than one program. A shared description of the domain could be maintained separately from the application that first needed it. That is where ontologies enter this history.
