AI Beyond Machine Learning
None of its own. This is a stretch page, and nothing on it is examined. It connects to A4.1.1 by showing what machine learning is not, and by explaining two applications that A4.1.1 names, robotics navigation and object detection. It also connects to A4.4.1 (explainability), A4.1.2 (why computing resources matter) and A4.3.10 (how to reason about choosing a method, HL). SL and HL students are both welcome.
“Artificial intelligence” and “machine learning” are often used as if they meant the same thing, but machine learning is one part of AI. For much of the field’s history, AI was built from symbols, logic, search and geometry, with no training data, and those methods still run games, route-finders and robots today. This page makes a claim you can check as you read: a robot can get across a building with very little learning in the system. In the robot described at the end of the page, learning appears in only one part, reading the camera; maps, search, geometry and probability do the rest. Seeing the two approaches side by side shows what machine learning replaced and what it did not. (Written July 2026 from sources dated 2019 to 2026.)
Table of Contents
- Overview
- Knowledge and Reasoning
- Game Search
- Route Search and Robot Motion
- What This Page Leaves Out
- Where This Connects
Overview
The page has three sections. The last two are both about search, and the difference between them is whether anything works against you:
- Knowledge and reasoning: facts written down as symbols, and new facts derived by logic.
- Game search: choosing moves when an opponent is working against you, so every move you consider meets their best reply.
- Route-finding and robot motion: searching for paths around obstacles that are simply there and do not react to what you do, then checking whether a robot can follow them.
Games were among the first problems AI research took on: chess and draughts programs were among computing’s earliest projects (and a famous eighteenth-century chess “machine” turned out to be a hoax with a person hidden inside). Games suit research because they offer a bounded world, fixed rules, a clear score and unlimited practice. The game examples below introduce search before the page applies it to route-finding.
Knowledge and Reasoning
Stretch. Related to A4.1.1 through the distinction between rule-based and learned methods, and to A4.4.1 through explainability.
Symbolic AI (sometimes called good old-fashioned AI) represents knowledge explicitly and applies logical rules to it. A symbol names something; a relation describes it or links it to something else. For example, teaches(Ms Rivera, Physics) states who teaches a subject. Unlike the lists of numbers (vectors) on the other stretch pages, this is readable: a person can look at it and say whether it is true or false.
The same information represented as an explicit statement and as a numerical vector.
A knowledge base is the collection of statements the system holds to be true. People build it by writing those statements down, which is a design task rather than a training run. Logic supplies the machinery: propositions (statements that are true or false), the connectives AND, OR and NOT, and truth tables to work out results. The most used piece is implication, the if/then rule, and its behaviour needs care: “if it is raining, the match is cancelled” is false only when it is raining and the match is not cancelled. Rule-based systems are built largely from rules of this if/then shape.
Inference derives new conclusions from the facts and rules in a knowledge base. This is what makes a knowledge base more than a database: the system can work out statements that were not typed in.
A conclusion depends on the facts and rules supplied. An incorrect rule can lead to an incorrect conclusion even when the inference procedure follows it correctly, so whether you agree with a derived conclusion is itself worth discussing. (One source lecture derives, by this route, that a hot dog is a sandwich; try building your own examples and arguing about them.)
Try it: derive facts nobody wrote down. A school library system holds four statements. Rules: any item with a story and a spine is a book; any book on the reserve shelf may not leave the library. Facts: the graphic novel has a story and a spine; the atlas is on the reserve shelf. What can the system derive, and what can it not derive that might surprise you?
Show the derivations
The system derives that the graphic novel is a book. If it is later placed on reserve, the system can infer that it may not leave. It cannot infer the same restriction for the atlas, because no supplied fact or rule establishes that the atlas is a book (an atlas has a spine but arguably no story, and the system knows only what it is told). The example shows two things: inference gives exactly what the rules entail and nothing more, and whether “has a story” was the right test for a book is a design decision that a person made and is accountable for.
Expert systems put this to work: a large set of if/then rules written to do part of a specialist’s job in a narrow domain. An expert system can explain its decisions. Asked why an application was refused, it can name the rule that failed and the value that triggered it. A trained neural network has no comparable trace: its decision comes from many numerical calculations, which are much harder to translate into an explanation.
The explainability trade-off: the rule-based system can explain its decision, but rule-based systems struggle with messy input such as images, which is where trained networks do well. This is the concrete version of the “black box” problem in A4.4.1’s questions about accountability. Quick exercise: write the refusal letter each system could send to the applicant, and compare what each letter can say about the reason.
Limits of symbolic rules. Try writing logical rules that recognise a hand-drawn “7”: every attempt runs into exceptions (differences in shape, angle and handwriting), because recognising images does not reduce neatly to true-or-false statements. Messy input and a changing world are where the symbolic approach struggles, and that is where machine learning comes in: it learns patterns from labelled examples instead of specifying each variation by hand.
The same idea at web scale
Writing every fact by hand does not scale, so knowledge can also be gathered by reading the web. A crawler follows links outward from a starting page to collect web pages. An inverted index records, for every word, which pages contain it, so a query can be answered by combining those lists (for example, finding the pages that appear in the list for every word in the query) rather than reading pages at the moment you search. Ranking the results is where learning comes back in, and users supply the training signal: a quick return to the results page suggests a poor answer, while a click followed by a long stay suggests a good one. Such signals are imperfect: a long visit does not necessarily mean the page answered the question.
A knowledge base can even grow itself by bootstrapping: start from a few hand-written facts, use known relationships to find new objects, use those objects to find new relationships, and repeat. Confidence comes from repetition: a fact found in many independent sources is trusted more than one found once, which is held as only possible. Repeated errors can spread too, so it matters that the sources are independent.
Symbols and relations at 2:19, knowledge bases at 3:44, truth tables at 4:30, implication at 7:15, inference at 9:44, expert systems at 10:52, the explainability contrast at 11:45 and the limits of symbolic AI at 12:04. From 2019; these ideas do not depend on recent developments.
Watch: search engines and knowledge at web scale (Crash Course AI, 11 min)
The crawler and its starting pages at 3:02, an inverted index answering a query at 3:41, ranking and user feedback at 4:55, knowledge bases at scale at 6:32, and a knowledge base growing from three hand-written facts at 7:00. From 2019, so treat the systems it names as examples from that time; the mechanisms still apply.
Game Search
Stretch. Related to A4.3.6 (HL), where exploration versus exploitation appears in reinforcement learning, and A4.1.2 through the computing resources needed for search.
Two meanings of “decision tree”. One of this section’s sources, the CS50 lecture embedded below, uses “decision tree” for a hand-written flowchart of questions for choosing a move. The syllabus (A4.3.2) uses the same two words for something different: a classifier that learns its splits from labelled data. A tree of possible game moves (a game tree) is different again. Keep the meanings separate, and check which one is being used when you read about these methods.
Start with hand-written rules. A strategy for a simple game can be written as questions: can I win with this move? If not, can my opponent win next move, so that I must block? Drawn as a flowchart, this works for a while. Keep asking “and what if neither applies?” and the rules soon run out: the system needs another way to compare possible moves, which is what the methods below provide.
Minimax evaluates moves by considering both players’ choices. Score the endings: +1 for a win, 0 for a draw, -1 for a loss. To evaluate an unfinished position, follow its branches and pass scores back up. At your turns, choose the highest score; at your opponent’s turns, assume they choose the lowest score for you.
Working backwards from the endings, the opponent’s left branch gives a score of 0, so you take the draw. On the right branch the opponent has a -1 available, so that branch can be no better than a loss for you. Alpha-beta pruning skips its remaining endings because they would not change your choice. Pruning saves work, but as the next paragraphs show, it is not enough on its own for larger games.
Try it: minimax by hand, then break its assumption. Sketch any two-moves-from-the-end position in a game you know, score the endings +1, 0, -1, and pass values up.
Then ask the sharper question
What changes if your opponent plays badly? Minimax assumes they choose the move with the worst outcome for you. Against a weak or random opponent, the “safe” branch may not be the best practical choice. Minimax is a policy of preparing for the opponent’s strongest reply; against a weaker opponent, a different strategy may do better.
Search grows quickly with every turn. Put two games side by side. In the first, nine possible first moves followed by eight replies give 72 two-move sequences; in the second, twenty first moves and twenty replies give 400. Played out completely, the small game can go roughly 260,000 ways, which a computer can check almost instantly. The bigger game passes tens of billions of move sequences within nine turns, and larger games are worse again, with more possible positions than there are atoms in the observable universe. As search goes deeper, the number of continuations soon exceeds what a program can check within its time limit.
The number of possible continuations grows rapidly with search depth, which limits how far a program can search with the time and hardware available. The principle applies well beyond games: a method that would work given unlimited time is not good enough, because efficiency is part of the problem rather than an extra. This is also the link to A4.1.2 and the hardware that computing problems need.
Try it: count the branches yourself. Multiply the first four turns: 9 × 8 × 7 × 6 against 20 × 19 × 18 × 17.
Check your arithmetic and finish the thought
The two products are 3,024 and 116,280, after only four turns. At a million positions checked per second, both are instant, which is why the problem is easy to underestimate. Continue to nine or ten turns: the second total grows to hours or days of checking, while the first stops growing because the small game ends after nine moves. What matters is how fast the number grows, not its current size.
Limiting search depth. A depth limit stops the look-ahead after a set number of moves, which creates a new problem: an unfinished position has no final score. An evaluation function estimates one. Hand-built evaluations are fragile: counting pieces may correctly show one side winning in one position, and be wrong in another where the pieces’ positions matter more than how many there are. Learning the evaluation from data, instead of writing it by hand, is one place where machine learning connects back to game search.
Monte Carlo tree search takes a different route: judge a move by simulating the rest of the game many times (in a simple version, with random moves) and counting wins. Suppose two candidate moves get a hundred random playouts each: one wins 41, the other 78. Take the second, even though the method gives no reason why it is better. How many playouts are enough? Increase the number until the answer stops changing, and accept that every playout costs time. Inside this method is a trade-off with a syllabus name, exploration versus exploitation (A4.3.6, in the syllabus at HL): a barely-tried branch with a poor record might still be better than the well-tried favourite, and deciding how often to revisit it is the same trade-off a reinforcement learner faces.
A strategy written as questions, minimax worked backwards from the endings, and exact counts of how many ways the game can be played. The segment ends at 28:59. Reminder from the warning above: when this lecture says 'decision tree', it means a hand-written flowchart, not the A4.3.2 classifier.
Watch: the history and the gentle version (Crash Course AI, 11 min)
The history of game-playing systems from 2:18, including the chess hoax with a person inside, then game trees, minimax and random playouts from 4:28, and what remains hard at 9:55. From 2019.
Route Search and Robot Motion
Stretch. Related to A4.1.1, which lists robotics navigation and object detection as machine learning applications. This section distinguishes the planning methods from the learned perception methods a robot may use.
Game search faces an opponent actively working against you. Route search faces obstacles that are simply there: walls do not react to your moves. Both explore possibilities before acting, and they form two families depending on whether anything works against you. Route search looks for a path through a map, subject to obstacles and movement costs.
One idea, two families. The game search section above was the left half; everything below is the right.
This section starts with simplifying assumptions and removes them one at a time: first a robot represented as a point on a grid, then movement costs, then the robot’s size, and finally uncertainty about its position.
Finding a route
Start with a grid containing a robot, a start and a goal. Depth first search follows a path, backtracking when it cannot continue and trying other branches. It can find a route, but does not guarantee the shortest one.
Breadth first search explores positions one step away, then two steps away, then three. Because it spreads outward evenly, when every step has equal cost, the first route it finds to the goal has the fewest steps. That guarantee comes from the order in which it explores, not from any extra cleverness.
Both searches examined 21 of the 24 open squares in this maze, so the difference here is the guarantee, not the effort saved. With equal step costs, breadth first search guarantees a shortest route; depth first search does not. Trace both on another maze and compare their routes and the number of squares examined.
Relax the grid into a graph (places as nodes, connections you may travel as edges) and both searches run unchanged: the world can now be towns on a road trip rather than squares.
Connections can have different costs. If roads are weighted by time, tolls or fuel, breadth first search can give the wrong answer, because the route with the fewest edges may not be the cheapest. Dijkstra’s algorithm restores the guarantee: when edge costs are non-negative, it finds a lowest-cost route by repeatedly expanding the unvisited node with the lowest known cost from the start, however many edges that route has.
Try it: cheapest is not shortest. Sketch five towns where the direct-looking route has four short roads costing 13 minutes total, and a longer-looking route costs 9. Which would you want from a navigation app?
Then push it one step further
Change the costs from minutes to tolls and check whether the chosen route changes. It often does: the lowest-cost route depends on what each edge’s cost represents. Choosing a method by what you care about is the same kind of reasoning A4.3.10 asks for at HL. These are search algorithms rather than machine learning models, though, so in A4.3.10 answers use the reasoning pattern, not these examples.
Using the goal’s location. Dijkstra’s algorithm orders exploration only by cost from the start, so it can do a lot of unnecessary work. Look at the squares breadth first search examined in the maze above: the whole dead-end pocket, pointing directly away from the goal. A heuristic (an estimate of the remaining cost to the goal) can direct the search towards the goal instead.
The shaded squares show the work a heuristic can save. Why not simply jump to whichever point looks closest to the goal? Because a point that took fifteen steps to reach can be worse than one that took two steps and looks slightly further away. A star search balances the cost already travelled against the estimated cost remaining. The heuristic affects which positions are explored; a poor estimate can make the search less efficient or, if it overestimates costs, lose the shortest-path guarantee. Finally, replanning updates the route when obstacles appear or clear while the robot is already moving, ideally recalculating only the parts that changed.
The robot is not a point
So far the robot has been treated as a point. Dropping that assumption is the difference between path planning (does a route exist?) and motion planning (can this physical robot actually travel it?). A car, for example, cannot slide sideways into an adjacent parking space; it needs room to turn. Knowing a route exists is not the same as being able to move along it.
A robot’s configuration is its full physical state, not just its position: a car also has a heading, and a four-jointed robotic arm is described by its four joint angles rather than by where its hand happens to be. Checking an awkward shape against obstacles at every step is hard, so engineers use a bounding shape: wrap the robot in a circle big enough to contain it. The rule is conservative: if every point of the robot is inside the circle, any route with enough room for the circle has enough room for the robot. Several smaller circles give a closer fit.
For a circular robot, grow each obstacle by the robot’s radius, then plan the route of the robot’s centre as a point.
Thicken the walls and shrink the robot to a dot: route-finding for a shape becomes route-finding for a point. The grey borders mark where the robot’s centre may not go, and any route outside them leaves room for the circular robot.
Try it: the fattened walls, on paper. Draw a floor plan with a doorway, and a robot drawn to scale as a circle. First decide by eye whether it fits through. Then redraw the plan with every wall thickened by the circle’s radius and the robot as a dot.
What you should notice
The second drawing answers the question at a glance: the dot fits wherever un-thickened space remains. If the thickened walls meet across the doorway, the circular robot does not fit through it, whichever route-finder you use. You have turned a geometry problem into the maze problem you already know how to search.
Two methods make continuous space easier to search, with different limitations:
- Real space is continuous, so there are infinitely many positions to consider. Sampling-based planning scatters random candidate points, discards any inside an obstacle or its grown border, and searches the survivors. The two costs: the route found may not be the best one, and an unlucky scattering can miss the only way through even though it exists.
- Real obstacles have irregular shapes. Cell decomposition divides the map into cells and marks any cell an obstacle touches as blocked. A coarse grid can wrongly seal a narrow gap that a blocked cell only partly covers. The repair is to split each blocked cell into four smaller cells and check again, repeating until a way through appears; the result still depends on how fine the grid becomes.
Sampling may miss a narrow passage. A coarse grid may mark it as blocked. More samples or a finer grid can help, at the cost of additional computation. Both costs come from turning a continuous space, with infinitely many positions, into a finite set that can be searched.
Where am I, actually?
The last assumption to remove is that the robot knows exactly where it is. Sensor readings and movement measurements contain uncertainty, so the robot holds a spread of likely positions (a probability distribution) rather than one certain point. A sensor reading arrives and the spread tightens; the robot moves and the spread widens again, because how far it actually travelled is itself an estimate. Estimating position this way is localisation. Estimating position while also building the map you are localising against is SLAM (simultaneous localisation and mapping).
The shaded area represents uncertainty about position. A caution for HL students: combining noisy readings can look like data cleaning (A4.2.1), but it is a different task. Preparing a dataset before training and a vehicle estimating its own position in real time (state estimation) are separate activities.
Sensing the world pairs two instruments with opposite strengths: cameras give appearance, and LiDAR gives geometry, sending out a pulse of light and timing its return across many angles. LiDAR still works in the dark when a camera does not; a camera reads a road sign that LiDAR sees only as a flat rectangle. Combining them lets each cover the other’s weakness.
The three core problems of robotics at 2:04, an analogy of finding your way in an unfamiliar building at 2:24, sensing and SLAM from 2:52, planning as actions with steps and conditions at 5:05, and control (keeping a physical machine on its plan) from 6:24, which this page does not cover. From 2019.
Where learning re-enters
Here the two approaches to AI meet. In the syllabus: object detection is an application named in A4.1.1. It finds objects inside an image: rather than labelling the whole image, it draws a box around each object, such as each pedestrian and cyclist. One approach proposes many candidate regions quickly, accepting that many will be wrong, and then uses a trained network to classify each region, including deciding that it contains nothing. Processing thousands of regions separately for every frame is too slow for a moving vehicle, so detection systems share calculations across regions or predict locations and classes together (standard practice since the mid-2010s).
So the finished robot combines several methods: maps and search decide where to go (no learning), grown obstacles and sampling decide how to move (no learning), a probability distribution tracks where it is (no learning), and a trained network reads the camera (learning, used for perception, where symbolic rules struggled). This division of labour is a more accurate picture of AI than treating AI and machine learning as the same thing.
What This Page Leaves Out
This page does not cover the following topics:
- Constraint satisfaction problems (timetabling, map colouring, sudoku), a major classical territory that teaches the same ideas well.
- How inference is actually carried out as a procedure, and logic beyond simple true/false propositions (the notation with variables and quantifiers you may see elsewhere).
- Probabilistic reasoning, including methods used for localisation.
- The rise and fall of expert systems in the 1980s, including their uses and limitations.
- The bookkeeping of pruning, named A star guarantees, and the data structures (priority queues, frontiers) underneath the searches: methods here are described by behaviour only.
- Named sampling-based planners and formal treatments of SLAM and planning languages.
- Multi-agent and swarm systems.
- Ethical questions about autonomous systems, such as who is accountable when a self-driving vehicle causes harm, which is a strong topic for an A4.4.1 discussion. The explainability comparison provides a starting point for discussing accountability.
Where This Connects
- In the syllabus: What Machine Learning Is (A4.1.1: this page shows what machine learning is not, and explains two named applications, robotics navigation and object detection; A4.1.2: the rapid growth of game search is one reason hardware and feasibility matter).
- In the syllabus (HL): Types of Learning for learned decision-tree classifiers (A4.3.2) and reinforcement learning (A4.3.6), where exploration versus exploitation reappears with rewards; Training and Evaluating a Model for model comparison (A4.3.10, the reasoning pattern only) and CNNs (A4.3.9, the kind of network used inside object detection).
- In the syllabus: Ethics of Machine Learning (A4.4.1) for explainability and accountability.
- Stretch: How Large Language Models Work and How AI Image Generation Works cover learned approaches to text and image generation.
- Elsewhere on EduCS: the search ideas here are related to Searching Algorithms (B2.4.2), and the graphs to Data Structures; those pages are assessed material, and this one is not.
Sources and dates for this page
Written July 2026, drawing on: Crash Course AI episodes on Symbolic AI, Web Search, Robotics and AI Playing Games (2019); CS50x 2026 “Artificial Intelligence” (2026); and CS50’s “Fundamentals of AI” lectures Playing and Moving (2026), which are long live recordings and so are linked rather than embedded. All worked examples, mazes and diagrams on this page are original.