Artificial Intelligence · AI Foundations
Knowledge Engineering and Hybrid Systems
In AI because real systems mix learned perception with authored constraints — from expert systems to LLMs gated by validators — and someone has to own each layer's failures.
Hand-authored knowledge did not lose to machine learning; the two split the work. This lesson is where the split runs in practice — what rules cannot reach, what the 1980s expert systems taught about maintenance, and how modern stacks, LLMs included, put a logical gate around a learned proposer.
- Artificial Intelligence
- Medium level
- 5 concepts
1Where rules cannot reach
Try to write the rule base for 'this photograph contains a cat'. Whatever pixel conditions you author, the next photo — the cat behind a plant, at night, upside down in a basket — falls outside them, and there is no finite list of exceptions, because the category lives in statistical texture rather than in clean fields a rule can test.
Rule chains also fail differently from models: each clause is exact, so an unanticipated case does not degrade the answer, it breaks the chain. Learned systems degrade; authored ones shatter.
None of which retires logic. Where the conditions are exact, stable and must be auditable — age limits, date ordering, spending caps, regulatory tests — a written rule is correct by construction, costs nothing to run, and can be read by the regulator. The engineering question is never 'rules or learning'; it is which claims deserve which tool.
Figure. Where conditions are exact, stable and auditable — age limits, date ordering, spending caps — a written rule is correct by construction. The rule base for 'this photograph contains a cat' has no finite list of exceptions; authored chains shatter, learned systems degrade.
Which of these tasks is the worst fit for a hand-authored rule base?
- Checking that a booking's end date falls after its start date
- Refusing an alcohol purchase to a user under 18
- Deciding whether a photograph contains a cat
- Verifying that a circuit matches its truth table
The other three are short, crisp conditions over clean fields. Nobody can write the rule that separates cat pixels from sofa pixels, which is exactly where learning earns its keep.
2Beyond propositions: first-order logic
Propositional logic cannot say 'every transfer over the cap is blocked' except as one atom per transfer. First-order logic (FOL) adds objects, relations and quantifiers — all, some — so one quantified rule covers unboundedly many cases. The symbol \forall x\, P(x) means every object x satisfies P. The symbol \exists x\, P(x) means at least one object x satisfies P.
The expressiveness bill is steep and precisely known. Gödel's completeness theorem gives FOL proof procedures that are sound and complete; Church and Turing showed its entailment is only semi-decidable — a true consequence will eventually be proved, but a non-consequence can keep a prover searching forever.
That asymmetry is why production rule engines stay inside decidable fragments, why databases and description logics restrict their quantifiers, and why this course does its reasoning in propositional logic: entailment, soundness and completeness are all already visible there, minus the halting risk.
| Propositional | First-order | |
|---|---|---|
| talks about | whole statements | objects, relations, all/some |
| one safety rule | one atom per case | one quantified clause, all cases |
| entailment check | decidable, up to 2^n worlds | semi-decidable — yes halts, no may not |
| quantifier symbols | none — each case is its own atom | all = \forall, some = \exists |
3The knowledge-engineering bottleneck
Every clause in an expert system was interviewed out of a person, written down, and kept true by hand. That labour — not inference — is what capped the 1980s systems: MYCIN matched infectious-disease specialists in blind evaluation yet never ran in a clinic, and the commercial bases that did ship grew into thousands of interacting rules whose maintenance consumed the teams that built them.
Experts disagree, edge cases multiply, and the domain moves: a rule base is software with the update rate of the world it describes.
Learning did not delete the labour; it relocated it. Labels are the learned system's rules — collecting, cleaning and adjudicating them inherits the same disagreements and the same staleness, plus failure modes of its own: a labelling guideline is itself a rule base about rules. Frontier teams budget for data operations the way the eighties should have budgeted for rule maintenance.
Figure. Every clause was interviewed out of a person, written down, and kept true by hand. Elicit discovers contradictions; integrate means new clauses interact with thousands of old ones; maintain is the domain shifting and clauses going stale — the cost that ended the boom.
Life of a rule base
- ElicitInterview the expert; write the clause down; discover it contradicts the last expert's clause.
- IntegrateNew clauses interact with thousands of old ones — no change is local anymore.
- MaintainThe domain shifts and clauses silently go stale: the cost that ended the boom.
Choosing learning over an expert system does not remove the human labour. What does it do to it?
- It removes it, which is the point of automating the task
- It shifts all of it onto the deployment and monitoring team
- It relocates it, from writing and maintaining rules to collecting, labelling and curating data
- It roughly halves it, since a fitted model needs no upkeep
Both approaches run on human effort; they differ in what the effort produces. Labels are the learning system's rules, and they need the same authoring, review and maintenance.
4Hybrid systems: learned proposers, logical gates
Deployed systems settle the rules-versus-learning question by splitting it: a learned layer reads the messy signal and proposes; a rule layer holds the claims that must never bend, and disposes.
A payments stack is the canonical shape. The fraud model scores every transfer — perception: plausible, tunable, allowed to be wrong. The legal transfer cap is a hard constraint checked by a rule — necessity: auditable, and deliberately impossible for a score to outvote.
The design discipline is failure ownership: every bad outcome must have exactly one owning layer. A transfer over the cap going out is a rules bug even if the model also scored it low; a novel fraud pattern missed is a model bug even though a one-off rule could have caught that case. Blur the ownership and both layers rot.
Figure. The learned layer proposes and the rule layer disposes: every transfer flows through the fraud model's score, but the legal cap is checked by the gate on the way out — a constraint the score cannot outvote.
| Failure | Owner | Why |
|---|---|---|
| over-cap transfer goes out | rules layer | a legal constraint was never the model's to decide |
| novel fraud pattern missed | model layer | patterns in messy signal are what the learned layer is for |
| legitimate user blocked at the cap | rules layer | the constraint fired as written — change the policy, not the weights |
Coding lab. A rules gate over model scores runs in the app, with checks on your output.
5LLMs, tools and guardrails
The 2020s hybrid is an LLM with tools: the model drafts an action — a query, an API call, code — and a logical layer decides whether it runs. Schema validators, permission allowlists, rate and spend caps, sandboxes: the rules gate again, wearing modern names.
The previous lesson's distinction does the design work here. Generation is plausibility — a fluent answer is a proposal, not a proof — so any claim that must hold is moved out of the model and into the checker, where it becomes a proposition with a definite truth value: the JSON parses or it does not; the call is on the allowlist or it is not.
This is why the constraint layer is having a renaissance rather than a retirement: the stronger and more general the proposer, the more of the system's guarantees must live in the one layer that can actually give them.
Picture the payments pipeline from the previous figure with its nodes renamed: the LLM where the fraud model stood, drafting a tool call instead of a score; the validator where the rules gate stood, checking schema, allowlist and limits; and the tool executing only on the gate's yes — the same architecture, one generation newer.
One gated action
- ProposeThe model drafts the tool call, arguments and all — plausible, unverified.
- ValidateSchema, allowlist, limits: each check is a proposition that must come out true.
- Execute or refuseOnly a call that passes every check runs; a refusal goes back to the model with the reason.
Notes
- Knowledge engineering, its cost, and hybrid learned-plus-logical systems.
- Hand-authored rules cannot cover messy perception, but stay the right tool for exact, auditable constraints.
- Expert systems taught that rule maintenance is the dominating cost.
- Modern stacks gate learned proposers — LLMs included — behind rules and validators.
Exam traps & shortcuts
- A constraint that must never bend cannot depend on a score — put it in the rules layer, after the model.
- Rules shatter where models degrade: plan explicitly for the case no clause anticipated.
- An LLM's fluent answer is a proposal, not a proof — gate it with a validator before it acts.
Recap
Hold these points before the next lesson.
- Where rules stop
- No finite rule list separates cat pixels from sofa pixels; perception belongs to learning.
- The bottleneck
- Every rule is authored and maintained by someone — the labour that ended the expert-systems boom.
- Hybrid ownership
- Learned layers propose, rule layers guarantee; every failure has exactly one owning layer.
- LLMs need gates
- A fluent answer is a proposal, not a proof — validators and allowlists are today's logic layer.
Practise Knowledge Engineering and Hybrid Systems
Reading is free and needs no account. Practice, mocks and progress live in the app.
- 2 quick checks with worked explanations
- Timed mocks scored with the real marking scheme
- Readiness tracked per topic, kept on your device