The Problem with Exact

The routing table had two hundred lines. Every line was an if statement. Every if statement was a bet — a bet that the string arriving at runtime would match the string you wrote six months ago, character for character, with identical spacing and capitalization and the same unspoken grammar about what to call a thing.

Most of the time, the bets paid off. But then a product manager changed the wording in a text field. Or a user typed “doctor” instead of “physician.” Or the API upstream started returning “CARDIOLOGY” in uppercase. And suddenly twenty lines of routing were wrong, and nobody knew which twenty.

This is the problem with exactness. It is not that exact matching is slow — in practice, a hash lookup is blindingly fast. The problem is that exactness is brittle. It assumes the world will ask questions in precisely the vocabulary you prepared for. The world does not cooperate.

Every if-statement is a bet. HDC is a way of making bets you can afford to lose.

The routing table is just one example. The same fragility appears in configuration parsers, intent classifiers, recommendation engines, access-control lists, and anywhere else that software makes categorical decisions about continuous human input. The underlying structure is always the same: a set of expected strings on one side, a stream of actual strings on the other, and a gap between them that grows every time the world changes.

Hyperdimensional computing is not about making the exact matching faster. It is about abandoning the exact-match assumption entirely. When you encode a concept as a point in ten-thousand-dimensional space rather than a byte string in a hash table, you gain something remarkable: the ability to answer “close enough” questions with the same computational primitives you use to answer exact ones. The “find a cardiologist” query and the “heart doctor” query land close together in the space. The query engine does not need to know they are synonyms. The geometry handles it.

This chapter tells the story of the routing table — where it came from, why it felt reasonable at the time, and what it costs to maintain. The rest of the book is about what happens when you replace it.

1.1 The Origin of the Routing Table

A routing table starts as a good idea. You have three use cases. You write three branches. The code is clean. A year later you have thirty use cases, seventeen edge cases, four legacy branches that nobody dares delete, and a comment that says “

The problem is not complexity. The problem is that each new route requires a human decision about vocabulary. What do you call the thing where a patient wants to transfer a prescription? Is it “transfer,” “move,” “switch,” or “change”? All four are valid English. All four mean the same thing. But the routing table will happily return null if the user chooses the fifth synonym you didn’t list.

match intent.to_lowercase().as_str() {
    "find a doctor" | "search providers" => Route::ProviderSearch,
    "schedule appointment" | "book visit" => Route::Calendar,
    "get prescription" | "refill medication" => Route::Pharmacy,
    "transfer prescription" | "move pharmacy" => Route::PrescriptionTransfer,
    // ... 192 more lines ...
    _ => Route::Unknown,
}

1.2 The Geometry of Meaning

What if instead of enumerating synonyms, you let the geometry handle it? Each phrase becomes a point in high-dimensional space. Points that mean similar things cluster together. The routing decision becomes: find the cluster nearest to the query point.

The remarkable fact — the one that makes hyperdimensional computing feel like cheating — is that you can build this geometry with operations that run on commodity hardware in microseconds. No neural network training. No embedding API call. No external service to go down at 3 a.m.

let probe = encode_phrase("find a cardiologist", &mut cb);
let top = query(&probe, &routes, 1);

Eight lines replace two hundred. And those eight lines generalize.

Full chapter: 3 000 words — the complete routing-table war story, profiling data, and the transition to Part II.