The Bombe

Discovery Engine — Deep Dive · Turing Series, Part 2

Hiroaki Kitano

The first machine built to cross a space too large for any human to cross — and it did it by pruning, not by brute force.

The answer was built in steel

I went to see one. Standing in front of a Bombe at Bletchley Park, the first thing that registers is how mechanical it is — not a sleek electronic computer, but a wall of rotating drums, relays and wiring. It is an electro-mechanical machine, purpose-built for one job and one only: to break Enigma. I will come back to what it was like to stand there; first, why such a machine had to exist at all.

Part 1 ended on a question. The universal machine had shown that one device could perform any effective procedure; but universality, I argued, is not yet discovery. The missing rung is search — and I closed by saying that the next post was about the first machine Turing ever built whose entire reason for existing was to search.

That machine is the Bombe, and the question it answered was not abstract. By 1939 it was a matter of life and death: every day the codes went unbroken, U-boats sank Allied ships in the Atlantic, and the delay was counted in lost cargo and lost lives. Every German military message was locked by a setting chosen from a staggering number of possibilities — around 159 quintillion, as we will see. No team of people could test that many by hand in a single day. And they had only a day: at midnight the setting changed, and the search started over from nothing. The Bombe was the first physical embodiment of the idea that a machine could traverse a space humans cannot.

That is the step this post is about. Part 1's universal machine could, in principle, carry out any procedure — but "in principle" is not the same as "in time." The Bombe took that abstract capacity and aimed it at a concrete, enormous space that had to be crossed against the clock. It is where the universal machine's promise stops being a statement about what is computable and becomes a real attack on what can actually be found in the time available — where, in the language of this series, universality turns into search.

How Enigma works

First, the machine itself — because every later step in this essay attacks one of its specific parts.

Enigma is an electro-mechanical cipher machine. Press a key, and a current runs through four stages before lighting a lamp that shows the enciphered letter. First the plugboard (Steckerbrett): a patch panel where cables swap pairs of letters — press A and the current may leave as if you had pressed R. Then a set of three rotating rotors (chosen and ordered from a larger set), each an independent scrambler wired to map every letter to another. Then a reflector at the far end, which sends the current back through the three rotors by a different path, and back through the plugboard once more, to the lamp.

Two features of that design decide everything that follows.

The first is motion. After every single keypress, the rotors step — the fast rotor by one position each time, the others at intervals — so the wiring the current meets is different for the next letter. Each letter is therefore enciphered with a different substitution alphabet, which is what defeats ordinary frequency analysis (Plus Magazine, n.d.). Enigma is not one cipher; it is a new cipher every letter.

The second is the reflector, and it is the machine's fatal flaw. Because the current bounces back through the rotors and out the same side, encryption and decryption are the same operation: set two machines identically and one undoes the other. That is what made Enigma practical to use in the field. But the reflector has a side effect its designers underrated: a letter can never be enciphered as itself (Wikipedia, n.d.). This is the weakness the whole essay turns on. It is why a guessed word can be tested against the ciphertext at all — any alignment that puts a letter above its own match is impossible — and it is the property the Bombe was built to exploit.

Now the numbers can be assembled, and it is worth seeing where the difficulty actually lives. The daily key had four parts, and the key space is their product:

• Wheel order — which three rotors, in which order, from the available set: ${5 \choose 3}$ ordered, giving 60.
• Rotor start positions — each of three rotors set to one of 26: 26³ = 17,576.
• Ring settings — the offset of each rotor's wiring to its letter ring: another 26³ = 17,576 (of which two rings matter in practice).
• Plugboard — ten cables swapping twenty of the twenty-six letters: 150,738,274,937,250, more than 150 trillion, and by far the lion's share of the key space.

Multiply them and you get the figure the film made famous: 17,576 × 150,738,274,937,250 × 60 ≈ 1.59 × 10²⁰ (Plus Magazine, n.d.). But look closely at the breakdown, because it shows where the difficulty really lies. The plugboard alone is more than five million times larger than everything else combined. The rotors and their positions — the part that actually enciphers — come to only a few tens of millions. The astronomical part of Enigma is the plugboard, and, as we will see, the plugboard is exactly the part Turing and Welchman found a way to switch off.

Before going on, try the machine itself. Type a message and watch each letter light a different lamp — and notice that no letter ever lights itself.

If you would rather type or paste a longer message and read the plaintext against the ciphertext letter by letter, this second version does the same enciphering in a plainer, text-first layout:

A space no human could cross

We just built that number up from its parts. Now feel its size: about 1.59 × 10²⁰ — 159 quintillion — possible settings, written out as 158,962,555,217,826,360,000.

That number is the whole problem. You could not try them all by hand, or with any number of people, before the key changed at midnight. Exhaustive search is not merely slow here; it is impossible in the time available. If breaking Enigma had required it, Enigma would never have broken.

So the real question was never "how do we search faster?" It was "how do we avoid searching almost all of it?"

The second great question

This is a different question from the one Part 1 answered, and the difference is the spine of this blog.

In 1936 Turing answered what can be computed? The Bombe faced a harder one: what can be searched before time runs out? A space can be perfectly computable — every point defined, every test mechanical — and still be unreachable, because crossing it would take longer than the war. Computability asks whether an answer exists to be found. Tractability asks whether you can find it in time.

Universality solved computability. The Bombe confronted tractability. Discovery lives in the gap — the spaces that are computable in principle and unreachable in practice.

The 159-quintillion space was always computable; you could grind through it in principle. The whole art was to make it tractable — to reach the answer before it stopped mattering. That, not computability, is the real problem in almost every act of discovery since.

Search with deduction inside it

The popular story says the Bombe was a fast brute-force machine. It was not — but the correction usually overshoots into the opposite error, that it "deduced" instead of searching. Neither is right. The Bombe's genius was that it combined the two: it embedded deduction inside search. It did step through rotor positions mechanically, one after another; but it used the logical structure of the crib to rule out almost every candidate the instant it was tried, so the number it actually had to work through was a tiny fraction of the whole.

The method began with a crib — a stretch of plaintext the codebreakers could guess was present in a message (a weather report, a stock phrase, a predictable header). Enigma had one fatal weakness: no letter is ever enciphered as itself. That single constraint let analysts line a crib up against the ciphertext and, from the letter-to-letter correspondences, build a menu — a diagram of the logical relationships the crib implied, in which chains of letters closed into loops.

Those loops are the key. A loop is a constraint that any correct rotor setting must satisfy. The Bombe was wired to follow those loops: it took a candidate setting and traced its consequences around the menu electrically, at machine speed. When a setting led to a contradiction — and the overwhelming majority did — the machine rejected not just that setting but, through the logic of the menu, whole classes of settings at once. What it produced was not "the answer" but a small number of stops: settings that survived the deductions and were worth checking by hand.

Gordon Welchman's diagonal board sharpened this enormously. It exploited the fact that Enigma's plugboard is reciprocal — if A is wired to B, then B is wired to A — to propagate each constraint back across the whole menu, multiplying the rejection power. In modern terms the Bombe was a machine for constraint propagation: it pruned an astronomically large space by following the logical implications of a few assumptions until almost nothing was left.

This is the point to hold onto:

The Bombe did not cross the space of 159 quintillion settings. It used structure to throw almost all of that space away unexamined, and traversed only what survived. The right modern analogy is not brute-force search but constraint solving: propagate a few assumptions, detect the inconsistency they force, discard the candidate — and, through the menu's logic, whole classes of candidates with it. The Bombe is an ancestor in spirit of the constraint-propagation and early-contradiction methods that let a modern solver ignore almost everything it never needs to examine.

The collapse is easier to feel than to describe. Below, place a crib, watch the impossible positions fall away, and see the key space drop from 159 quintillion toward a handful of stops — with and without Welchman's diagonal board.

A machine shaped like the enemy's mathematics

It is worth pausing on why this worked. The Bombe is the clearest example I know of a machine built to mirror the exact structure of the problem it attacks.

Enigma had two structural gifts, both consequences of its reflector and plugboard, and the Bombe was built to exploit each. The first we have met: the reflector meant a letter was never enciphered as itself, so any candidate solution that produced the same letter in the plaintext and the ciphertext at the same position could be eliminated outright. The second is the plugboard's reciprocity: letters were swapped in pairs, so that if A was transformed into R, then R was transformed into A — a regularity Welchman's diagonal board exploited to vastly increase the machine's efficiency (TNMOC, n.d.).

The payoff of that second idea is best stated in numbers, because it is the whole argument of this chapter. Turing's first machine worked in principle but needed impractically long cribs to rule out enough settings; menus rarely had enough loops to give good rejection, so runs produced far too many incorrect stops. Welchman's board changed the arithmetic: by exploiting the reciprocity of the plugboard, Turing and Welchman effectively eliminated the plugboard from the Bombe's calculations — reducing 158 million million million possibilities to 60, the number of possible wheel orders. With the improved machine, menus with only a single loop, and in special cases none at all, became usable (TNMOC, n.d.).

That is the key move. The plugboard was Enigma's great multiplier of difficulty, and it was not beaten by more speed. It was removed from the problem — by spotting the symmetry inside it (A→B means B→A) and wiring that same symmetry into the Bombe. The machine's wiring is, in effect, a working copy of Enigma's own logic, built so that a wrong guess quickly leads to a visible contradiction.

This also explains the machine's shape. The Bombe is not a general computer that happens to run a codebreaking program; it is special-purpose hardware whose structure is the problem's structure. Its drums mirror Enigma's rotors, its cabling mirrors the menu's constraints, its diagonal board mirrors the stecker's symmetry. Change the cipher and you cannot reprogram it — you would have to rebuild it.

Set that against Part 1 and the contrast is exact. The universal machine's whole point was to separate the machine from the task it performs, so that one device could become any device just by changing its instructions. The Bombe is the opposite: its task is built into its physical form, like a loom or a mill. It is the last great success of the old way of building machines — one purpose, one shape — and it arrived at the very moment the universal idea already existed on paper. Turing wrote the universal machine in 1936, then in 1939 built its opposite, because the war needed an answer now, and special-purpose steel was the only way to get one in time.

Doing the arithmetic

The tractability argument becomes concrete when you put numbers to it, and the numbers are worth the detour.

Start with the clock, because the clock is the real adversary. Enigma keys changed daily, usually at midnight. Whatever was intercepted in the morning had to be broken the same day, or it was worthless — and the search began again from zero. Every calculation below happens inside that window.

Now the two sides of the gap. On one side, the key space: by 1939, rotors and plugboard pairs had pushed the figure to roughly 1.59 × 10²⁰ (Plus Magazine, n.d.). On the other, the machine: a Bombe could complete all 26 × 26 × 26 rotor positions in a little over twenty minutes, which is about 17,576 positions per run. Set those side by side and the ratio is absurd — something on the order of 10¹⁶ runs to cover the space by enumeration. A single machine grinding the full Enigma key space by brute force would need on the order of centuries (TNMOC, n.d.). The war would be long over.

So the Bombe, on its own, comes nowhere close. What closes a gap of sixteen orders of magnitude is not the machine but the structure fed into it — and here the pieces of this chapter come together.

The plugboard was the largest single contributor to the key space by a wide margin, and Welchman's insight removed it from the machine's work entirely — the reduction from 158 million million million to 60 wheel orders described above. What remains is small enough to be real work rather than fantasy: the Bombe searches all 17,576 rotor starting positions, while rotor order and type are tested separately, so the practical space is wheel orders × rotor positions — of the order of 10⁶, not 10²⁰. Going through the 60 wheel orders of the Army/Air Force five-wheel set takes roughly twenty minutes of Bombe time (TNMOC, n.d.) once the menu is good; in the naval case, with more wheels in play, both the wheel orders and the hours multiply.

That is the whole argument in one line: a 10²⁰ problem, attacked with a 10⁴-per-run machine, made soluble by structure that removed 10¹⁴ or more of the difficulty before the drums began to turn. The crib supplies the constraints; the menu's loops turn them into rejection power; the diagonal board multiplies that power; and only the residue reaches the machine.

Two consequences follow, and both matter for what this blog is about.

First, the crib is essential — everything else depends on it. Without one there is no menu; without a menu, no loops; without loops, nothing for the drums to contradict, and the machine is left facing all 10²⁰ possibilities, twenty minutes at a time. This is why so much of Bletchley's effort went into obtaining cribs: harvesting them from weather reports and stock phrases, and manufacturing them by gardening. The hard intellectual work was not building a faster machine. It was finding the structure that made the machine's speed worth anything.

Second, quality of structure translates directly into time. A weak menu produced too many false stops, each one costing human effort to check; a menu with good loops produced few. Before the diagonal board, menus rarely had enough loops to give good rejection and runs threw off large numbers of incorrect stops; after it, a single loop, and sometimes none, would do (TNMOC, n.d.). The difference between a good crib and a poor one was the difference between breaking the day's traffic before midnight and not breaking it at all.

Scale was the last multiplier. One machine was never going to be enough against a whole day's traffic on many networks, so the operation was industrialised: by 1943 more than two hundred Bombes were running in parallel (BTM, n.d.) — the scale I saw for myself when I visited.

There was no eureka in a pub

If you know one scene from the breaking of Enigma, it is probably the wrong one. In the 2014 film The Imitation Game, the decisive breakthrough arrives as luck overheard in a pub: a colleague mentions that the German messages she handles always begin with the same letters — a girlfriend's name — and contain predictable words like a weather term and a sign-off, and in that instant the team realises the cipher can be beaten by guessing plaintext. They run to the hut, rewire the machine, and Enigma falls.

It is a wonderful scene, and it is essentially fiction. There was no single epiphany. Using guessed plaintext was not a flash of insight but the founding principle of the whole operation, present from the start and pursued with industrial discipline. The real story is better precisely because it is not about luck — it is about turning the enemy's predictability into a machine.

Here is how it actually worked. A crib is a stretch of plaintext you can bet is sitting inside a message. The codebreakers did not wait for cribs; they harvested them, systematically:

• Weather reports. German stations sent them daily, at predictable times, in stereotyped language — and their content could often be guessed from Britain's own weather. A reliable crib, every single day.
• Stereotyped form. Military traffic was rigidly formatted: standard addresses, ranks, openings and closings, and stock phrases such as keine besonderen Ereignisse ("nothing to report"). Rigidity is predictability, and predictability is a crib.
• EINS. The word eins ("one") appeared in an enormous fraction of messages, so Bletchley catalogued every way eins could be enciphered under the current settings and scanned the day's traffic for matches.

And when the enemy would not supply a crib, Bletchley manufactured one. The technique was called gardening, and the name is not a metaphor invented later: "gardening" was standard RAF slang for sowing mines in rivers, ports and oceans from low heights — possibly because each sea area around the European coasts carried a code-name of flowers or vegetables. Bomber crews flew out at night to plant "vegetables" in a named patch of sea. In cryptanalysis the word came to mean encouraging a target to use known plaintext, typically by performing an action the target is certain to report (Wikipedia, n.d.).

The mechanism is simple and ruthless. Mine an area, and the Germans must warn their own shipping — by Enigma, naming the grid square, using stock words like Minen. The British chose the location, so they knew the plaintext before the ciphertext existed. And the trick was repeatable on demand: if the Germans had recently swept an area for mines and the analysts at Bletchley needed cribs, they might — and on several occasions did — request that the area be mined again (Wikipedia, n.d.).

This is the deepest point in the essay, and the easiest to miss. Gardening crossed a boundary. The codebreakers were no longer extracting evidence from a world that happened to leak it; they were acting on the world to make it produce the evidence they needed. When the search space would not expose enough structure, they intervened in reality to create some, then searched the response. Search had become intervention — the loop at the heart of autonomous experimental science: observe, find the constraint insufficient, act, read what comes back, and only now is the search tractable. It is the first appearance in this series of the question the whole blog is chasing: not how to search a space, but where the structure a discovery needs comes from, and who is allowed to make it.

And it was not free. Those sorties were flown at night, at low altitude, into defended water, and some of the aircrew who planted "vegetables" did not come back. The experiment had a price, and the price was paid in lives — worth remembering when we talk, comfortably, about machines that act on the world to generate their own data.

From a crib, the daily grind began: rule out the impossible alignments (no letter encrypts to itself), draw the menu, wire its loops onto a Bombe, set the drums, run through the positions, and collect the stops — the survivors. The WRNS operators — the "Wrens" — ran the machines around the clock; each stop was tested by hand, most were rejected, the next was tried, until one yielded German. Then the day's key was out, every message on that network could be read — until midnight, when the keys changed and the whole apparatus began again from nothing.

That is what the pub scene compresses: not a moment of genius, but a system that converted the enemy's discipline, habits and mistakes into a daily, repeatable collapse of an impossible space. The Bombe was the engine; cribbing was the fuel; and the fuel was refined on a production line, not stumbled upon in a bar.

Banburismus: search guided by evidence

There is a second, subtler idea here, and it leads directly toward the next post.

Before a menu ever reached a Bombe, Turing wanted to reduce which configurations were worth putting on the machine at all — in particular, for naval Enigma, which rotor order to try. His method, Banburismus (named for the Banbury-printed sheets it used), was a hand procedure for accumulating evidence: comparing intercepted messages for statistical coincidences and weighing how strongly each observation favoured one hypothesis over another.

To quantify that weighing, Turing introduced a unit — the ban, and its tenth, the deciban — for the weight of evidence a piece of data carries. This is, in all but name, sequential Bayesian inference: each new observation updates the odds, and evidence accumulates until one hypothesis is strong enough to act on. But it is worth being exact about what Banburismus did, because it is easy to overstate. It did not choose experiments or go looking for new data; it worked from already-intercepted traffic, ranking hypotheses to decide where to spend a scarce resource — Bombe time. The right modern gloss is not "expected information gain" but compute allocation: given more promising and less promising configurations, put the machines on the promising ones first (Good, 1979). In today's vocabulary this is an ancestor of sequential Bayesian updating — but not of active learning or Bayesian optimization, which choose where to observe or experiment next. That step — going out to get new data rather than ranking the data you already hold — appears earlier in this essay, in gardening. Banburismus ranked the possible; gardening manufactured the evidence.

So the Bombe gives us two faces of intelligent search, not one, and they are complementary:

Constraint decides where not to search. Evidence decides where to search first. The Bombe's menu-logic ruled out the impossible; Banburismus ranked the possible. Real discovery needs both.

The boundary

Two distinctions must be drawn cleanly, because both are routinely blurred and both matter.

First, the Bombe is not Colossus, and Enigma is not Lorenz. The Bombe was an electromechanical machine — relays and rotating drums — designed by Turing with Welchman's diagonal board, built by the British Tabulating Machine Company, and aimed at Enigma. Colossus was something else entirely: an electronic machine, built from valves by Tommy Flowers, operational from 1943–44, and aimed at the Lorenz teleprinter cipher ("Tunny") in Max Newman's section — not Enigma. Turing's hand method "Turingery" contributed to the Lorenz attack, but he did not design Colossus. Conflating the two — a very common error — gets both the machine and the man wrong.

Second: the Bombe searched within a space someone else had already drawn. And it is worth being precise about who. The underlying set of possible settings was fixed by Enigma's design; but the representation the Bombe actually searched through — the menu, its loops, the crib it rested on — was built by the cryptanalysts before a single drum turned. A human chose the crib, aligned it, drew the menu, and picked its loops; the machine then traversed, propagated and rejected. The Bombe never redrew the space or the representation — it ran a search a human had already set up. It shows, about as clearly as anything can, what search can do inside a fixed frame — and, for that reason, it also shows the limit of search: no amount of Bombe could invent a new way of describing the problem, only find the right point within an old one. (Later in this series I will call this kind of search intraspatial, and contrast it with the rarer act of remaking the space itself; here the plain statement is enough.) That limit is why the discoveries this blog cares about needed more than a Bombe.

Reported from Bletchley Park

Two things stay with you from the site. The first is the machine. A Bombe is emphatically not a sleek electronic computer. It is electro-mechanical — banks of rotating drums, relays and wiring, a physical contraption of moving metal built for one task only. It does real logic, but here that logic is carried out by moving parts and electric current, not electronics. Seeing one in the flesh makes the Bombe/Colossus distinction concrete in a way no diagram can: this is a machine you can watch move, not a rack of valves. It also makes plain how specialised it was — not a general computer at all, but a machine built for one cipher and nothing else.

The second is scale. There was never one Bombe. The first, "Victory," began work in March 1940; by 1944 the British Tabulating Machine Company had built more than 200 of them (BTM, n.d.), most housed not at Bletchley itself but at out-stations like Eastcote and Stanmore, and by the end of the war some 211 Bombes were being run by around 1,700 Wrens and RAF personnel (TNMOC, n.d.). And the machines were only the visible tip. At its wartime peak Bletchley Park was an operation of some eight thousand people — intercept operators, cryptanalysts, engineers, the WRNS who ran the Bombes around the clock, translators, indexers, administrators. It was not a laboratory. It was a factory for breaking codes.

That scale is what the essay's argument looks like in practice. Everything above said the same thing: Enigma was broken not by a single brilliant idea but by a system — cribs harvested and manufactured, menus drawn, machines run, stops checked, keys recovered, the cycle repeated every day against keys that reset at midnight. On the site you feel what that system cost: thousands of people and rooms full of purpose-built machines, running without pause. The romance of the lone genius does not survive the sheer scale of the place. What replaces it is more interesting — the first time people organised themselves, on an industrial scale, around machines whose job was to search: to grind through a space of possibilities far too large for any human to cross.

And Enigma was not the whole of it — something I had not expected. Bletchley's reach extended to the other side of the world: work at the Park covered Japanese diplomatic and naval traffic and later Japanese Army and Air Force messages, with Hut 7 devoted to Japanese naval codes such as JN-25 (Bletchley Park Trust, n.d.). Those numerical ciphers were attacked with statistical methods, and even once decrypted the messages were dense with codenames and abbreviations, so the Park ran its own crash course in Japanese — an eleven-week programme devised by Captain Oswald Tuck, a retired naval officer who had lived in Japan, to produce usable translators at speed (Smith, 2000). As a Japanese reader I found this a strange thing to stand next to: the same site, the same industrial method, turned on my own language.

And the site is not finished. Bletchley Park is midway through redeveloping its Block B into a comprehensive exhibition on Turing's life, work and legacy, with a new gallery devoted to the wartime cipher machines — an effort aimed not only at commemorating Turing but at drawing the next generation toward mathematics, computing and AI. In that sense, this is not settled history closed off in the past; it is still being studied, retold, and added to today.

What the Bombe could not do

It is tempting to call Banburismus a kind of "learning," since it improved its guesses as evidence came in — and that would make an easy bridge to Part 3, which is about learning. But it would not be accurate, and the accurate version is more interesting.

Banburismus changed what the analysts searched as evidence accumulated — but the adaptation lived entirely in the humans. The procedure was fixed and the machine was fixed; what updated day to day was the analyst's belief about where to look. The Bombe learned nothing. Its wiring did not improve from yesterday's failures, and its search did not change because of anything it had seen. Give it the same menu tomorrow and it runs exactly as today. Across the whole operation the division never moved: humans framed — cribs, menus, evidence, even manufactured structure by gardening — and the machine executed the search inside that frame.

So the question that ends this chapter is not "can machines think?" but the next real rung: can adaptation move inside the machine? Can a machine change how it searches because of what it has already seen? Turing began to answer it in 1948, in an unpublished report; Part 3 follows him there. The line holds: machine, then search, then learning. The Bombe searched a space someone handed it. It never learned, and it never asked where the space came from — the next two questions, and the ones this whole blog lives in.

A note on how this was written

This post is a human–AI collaboration, and it is also the product of first-hand research. Hiroaki Kitano visited Bletchley Park in person on 6 July 2026 — seeing the machines, the site, and the scale of the operation at first hand, and discussing Turing's legacy and the Block B project with the Trust — and the reported sections draw directly on that visit. The writing itself was done with Claude (Anthropic) as primary collaborator, and Gemini (Google) and ChatGPT (OpenAI) in the loop for framing, cross-checking, and reference work. Any material originating with the Trust's historians is credited where it appears. The diagram of how the Enigma machine works was generated with ChatGPT (OpenAI) and verified letter-by-letter against a historically accurate simulation of the Enigma I. Historical claims have been checked against the standard sources below and, for the reported portions, against the visit. Final editorial judgment is the author's.

There is a small mirror here worth naming. The Bombe was never an automatic oracle. A human guessed a crib, built the menu, set the drums, and checked the stops; the machine did only the part no human could do at that scale. The work was a loop — human framing, machine search, human judgement. This essay was made the same way, and the parallel is not lost on me.

The author warmly thanks Tilly Davis, Dr David Kenyon, Laura Stoker, and Natalie Askew-Conti of Bletchley Park for their generosity and time during the visit, and the Bletchley Park Trust for permission to include the footage of the Bombe.

See the Lab Notebook for this post for the visit notes, source materials, and iteration history.

Lab-Notebook for Bombe

How to use: Title the Ghost post Lab Notebook — The Bombe. Select everything below this line (Ctrl/Cmd-A), copy, and paste into the empty post body; formatting converts to native cards. Tag it Lab Notebook so it lands under /lab-notebook/, and link it from Part 2’s “See

The Discovery EngineHiroaki Kitano

@misc{kitano2026bombe,
  title  = {The Bombe},
  author = {Kitano, Hiroaki},
  year   = {2026},
  howpublished = {\url{https://thediscoveryengine.ai/}},
  note   = {Discovery Engine, Deep Dive, Turing Series, Part 2}
}