What a Knowledge Engineer Actually Does Today
The modern discipline covers problem framing, eliciting expertise, modeling meaning, linking evidence, testing applications, and maintaining the result.
“Can we reuse this component on this project?” is a plausible question for an AI assistant. Finding a document that names the component would be a start. It would not answer whether the document describes the right version, whether the proposed use matches a previous test, which requirements apply, or whether an exception has changed the decision. Those distinctions are part of the work a knowledge engineer does today.
The discipline is broader than a particular job title. Amazon has advertised an ontologist role involving product meanings, knowledge models, global variation, AI-assisted structure, and coordination across technical and nontechnical teams. Another employer might call closely related work knowledge architecture, taxonomy, or the back-end engineering of a knowledge platform. A title alone does not tell us which part of the discipline a person owns. (Amazon, Ontologist—Product Knowledge)
The work begins before a model exists
Someone first has to learn what decision the organization is trying to improve, who makes it, and what goes wrong now. A missing answer may result from scattered evidence, inconsistent terms, an absent owner, a difficult approval path, or a genuinely hard inference. Each cause suggests different work. Sometimes a shared vocabulary or a better human decision process is more useful than a new AI application.
Then comes investigation. The engineer interviews specialists, observes real tasks, compares cases, and looks for exceptions. Experts do not always articulate every distinction they use, so the engineer returns with examples and tests the interpretation. In the component case, the phrase “same component” may hide changes of version, supplier, material, or permitted use.
The engineer can then define terms and relationships, select relevant sources, record rules and constraints, and decide how much detail the task requires. A taxonomy organizes categories. An ontology describes concepts and relationships. A knowledge graph connects particular things. These are possible products of the work, not synonyms for the whole discipline.
The model meets the application
The next set of tasks is often shared with software and data engineers. Records must be connected across systems without erasing meaning. Applications need storage, access, retrieval, and interfaces. A language model may need current material supplied at the moment of a question. The knowledge engineer may write substantial code or supply models and specifications for others to implement; the division varies by team.
What remains distinctive is responsibility for what the information means and how it supports the task. If two sources disagree, the system should not silently choose whichever one appears first in search. If a record says a component was tested, the answer should not upgrade that to universal approval. If the evidence is old or incomplete, the application needs a way to show that condition rather than cover it with fluent prose.
Testing follows at several levels. Structural checks can find missing required fields or prohibited combinations. Case reviews can reveal a valid-looking record attached to the wrong product. User testing can show whether a person understands an answer and can inspect its basis. Operational review asks whether the system actually improves decisions and what happens when it fails. (W3C SHACL recommendation)
Maintenance is not a later phase
Owners must be able to approve changes, retire old material, investigate incidents, and see which applications depend on a revised concept. Permissions and source histories matter because not everyone should see every record or act on every claim. In AI systems these duties intersect with privacy, security, legal, and risk work; knowledge engineering does not replace those specialists.
No single employee performs every one of these activities. The full lifecycle is the discipline’s responsibility, distributed across a team where necessary. Its distinguishing feature is not a database, programming language, or job title. It is the continuing work of making meaning, evidence, and decision requirements operate together.
The next post stays with one part of that lifecycle. If a system offers a confident answer about component reuse, a person should be able to ask where the underlying claims came from and how they changed. That requires a record of the knowledge itself.
