Lab Notebook for Bombe

Lab Notebook — The Bombe (copy all, paste into Ghost)

Discovery Engine — Lab Notebook for Deep Dive · Turing Series, Part 2

A working log, kept openly, continuing the practice begun with Part 1: the process by which these posts are made is itself a human–machine act, and hiding it would be inconsistent with what this blog argues. Appended to, not rewritten — the wrong turns stay in. This entry set covers Part 2, from the Bletchley visit through publication.

Entry 0 — What Part 1 handed to Part 2

Part 1 ended on a deliberate hinge: universality is necessary for discovery but not sufficient; the missing rung is search; and the first machine Turing built purely to search was the Bombe. Part 2 had to make that literal. The through-line for the whole series — machine → search → learning → imitation → discovery → engine — puts the Bombe at search, so the essay's job was to show a real, physical machine crossing a space no human could cross, and to do it without overstating the Bombe's kinship to modern learning systems. That last caution was logged at the end of Part 1's notebook as the open question for the visit.

Entry 1 — Reported, not researched-from-a-desk

The defining decision was to write Part 2 as a reported piece, anchored in a first-hand visit to Bletchley Park on 6 July 2026. This shaped everything: the essay could describe standing in front of a Bombe, the scale of the site, and details that only register in person. Two first-person observations became structural — that the machine is emphatically electro-mechanical (moving drums, relays, current), and that the operation reached a scale of some eight thousand people at its peak. Both were things the author reacted to on site, then checked against sources afterward, rather than facts assembled first and dramatized later.

A related judgement, carried from correspondence with the Trust: Dr David Kenyon is a research historian, not a technical engineer, so the technical framing (the diagonal board as constraint propagation, the Bombe as pruned search) had to be checked against the technical literature and against a working simulation — not against the historians. The historians' authority is historical; the engineering claims are ours to verify.

Entry 2 — Four simulators, all verified before trusting

Part 1's lesson — check, don't recall — was applied harder here, because Enigma and the Bombe are easy to get subtly wrong. Four interactive pieces were built and each verified in code before being embedded:

  • Turing machine (carried from Part 1, unchanged).
  • Bombe key-space simulator — a schematic of the principle: place a crib, rule out positions where a letter sits above its own match (Enigma never enciphers a letter to itself), build the menu, and watch the key space collapse, with and without Welchman's diagonal board. Labelled openly as a schematic, not a working decryption.
  • Enigma encoder/decoder — a historically accurate Enigma I, text-first.
  • Enigma machine (visual) — the same engine in the real hardware layout: QWERTZ lampboard and keyboard, rotor windows, click-or-type, lamp lights, rotors step.

The verification that mattered: the two Enigma simulators are historically accurate, not approximate. Rotor wirings I–V, reflectors B/C, correct turnover notches (Q/E/V/J/Z), ring settings, plugboard, and — the easy thing to miss — the middle-rotor double-stepping anomaly were all implemented and then checked against the canonical published test: with rotors I-II-III, rings AAA, start AAA, reflector B, no plugboard, typing AAAAA must produce BDZGO. It did. Reciprocity (the same settings decipher) and the no-letter-maps-to-itself property were confirmed in code, and the double-step sequence ADQ → AER → BFS reproduced. Only after these passed were the widgets embedded.

Entry 3 — The diagram, and a genuine verification catch

The "How the Enigma machine works" diagram was generated with ChatGPT. The first version was rejected on inspection: its rotor mappings (A→D, etc.) did not match the real wiring, so a reader could have taken decorative example values for the actual Enigma I wiring. The author fed the correct wiring tables back to ChatGPT, which produced a second version built on the real wiring and carrying a fully worked example — the complete signal path for pressing A (A → plugboard → III → II → I → reflector → back → lamp) plus the AAAAA → BDZGO sequence.

That second version was then checked letter-by-letter against our own verified simulator: every stage of the signal path (A-A-C-D-F-S-S-E-B → lamp B) and all five keypress outputs (B, D, Z, G, O) matched exactly, as did the rotor positions stepping AAB, AAC, AAD, AAE, AAF. Only then was it accepted. The credit line states both facts plainly: generated with ChatGPT and verified against a historically accurate simulation. This is the on-theme point again — an AI-made asset is fine, but it is trustworthy only once checked against ground truth.

Entry 4 — What the essay actually argues (and three sections that carry it)

The draft grew well past a straight history because three ideas turned out to be load-bearing, and each earned its own section:

  • Computability ≠ tractability. The real second question Turing's era faced was not what can be computed but what can be searched before time runs out. The Bombe lives in that gap. This is the spine that connects Part 2 back to Part 1 and forward to the rest of the series.
  • A machine shaped like the enemy's mathematics. The clearest technical result to convey: Turing and Welchman did not out-run the plugboard, they removed it — the diagonal board exploits the plugboard's reciprocity (A↔B) to eliminate it from the machine's work, collapsing 158 × 10¹⁸ possibilities to 60 wheel orders. The Bombe is special-purpose hardware whose structure is the problem's structure — the exact opposite of Part 1's universal machine, and, historically, built three years after the universal machine was written on paper.
  • Doing the arithmetic. The tractability argument made numeric: a ~10²⁰ problem, a machine that clears ~10⁴ positions per ~20-minute run, and the gap closed not by the machine but by structure fed into it — the crib, the menu's loops, the diagonal board — that removes ~10¹⁴ of the difficulty before the drums turn. This makes concrete why the crib is the load-bearing element, not a convenience.

Two further sections do thematic rather than technical work. Gardening — the RAF minelaying that manufactured cribs — is flagged as the essay's deepest point: search had become intervention, the codebreakers acting on the world to make it produce the evidence they needed, and paying for it in aircrew lives. That is the first appearance of the question the whole blog is chasing: where does the structure a discovery needs come from? And Banburismus gives the complementary face: constraint decides where not to search; evidence decides where to search first.

Entry 5 — New material added on the author's steer

Several late additions came from the author pressing on specific questions, each checked against sources:

  • The Bombe / universal-machine relation made explicit (requested), so a reader sees Part 2 as the deliberate inverse of Part 1.
  • The scale and the Japanese work (requested). Bletchley reached ~8,000 staff; Hut 7 worked Japanese naval codes (JN-25); the Park ran Captain Oswald Tuck's eleven-week crash course in Japanese. As a Japanese reader, the author noted the strangeness of standing next to the same industrial method turned on his own language — a first-person beat that only the visit could produce.
  • The complexity-gap discussion (requested): the daily deadline, the key space, the Bombe's throughput, and how cribs and structure close the gap. This became "Doing the arithmetic."
  • Concrete build numbers (requested, then verified): Victory operational March 1940; 200+ Bombes built by BTM; ~211 in service by war's end, run by ~1,700 Wrens and RAF personnel; out-stations at Eastcote and Stanmore. The abstract "there was never just one" was replaced with these figures once sourced.

Entry 6 — The clarity pass: cutting the rhetoric

The largest editing effort on Part 2 was not adding but subtracting. The material is dense — key-space arithmetic, constraint propagation, computability theory — so the governing rule became: the reader's effort should go into the ideas, not into decoding the prose. A full pass (and several rounds of review comments) stripped out inversions, ornate metaphors, rhetorical scaffolding, and redundancy. A representative sample of what changed:

  • inversions removed: "Nor was Enigma the whole of it" → "And Enigma was not the whole of it";
  • strained metaphors plainerified: "that scale is this essay's argument standing in a field" → "what the essay's argument looks like in practice"; "logic worked in brass and current" → "carried out by moving parts and electric current"; "the acreage I found myself standing in" → "the scale I saw for myself";
  • opaque phrases explained: "where universality becomes search" now spells out computable vs found in the time available; "a deadline measured in shipping losses" → the plain U-boat/Atlantic statement;
  • one long convoluted sentence about the key space split into three short ones;
  • deliberate keepers: the load-bearing blockquotes ("Universality solved computability. The Bombe confronted tractability"; "Constraint decides where not to search. Evidence decides where to search first"; "Search had become intervention") were left crisp — they are the argument, not decoration.

The test throughout: readable on the first pass? This whole pass was then codified into a reusable Style & Sourcing Guide so later posts inherit the same discipline.

Entry 7 — Sourcing: grouped by claim, cited in-text, linked

Two sourcing decisions were settled here and folded into the style guide.

References grouped by claim, not by appearance order. Each group's heading names the exact figures it supports (e.g. "Bombe running time ~20 min; 200+ built; ~211 in service"), so a specific number can be traced to its sources. Sources are listed one per line. Official and academic sources are deliberately not split into tiers — grouping is by claim only. Where a museum or archive page is the most direct public source, it is cited, with scholarly works listed for readers who want to go further.

In-text citations as clickable (Author, Year), never numbered footnotes. Institution-as-author where there is no personal author (TNMOC, Bletchley Park Trust, Plus Magazine, BTM), n.d. where a page is undated. Each citation is an in-page link to its claim-group anchor, so a click jumps to the group, which holds the external URLs. Citations attach only to specific figures/claims/quotes, not to general prose.

A verification note worth keeping: when rebuilding the reference list, a few rotor-wiring URLs recalled from memory were not trusted — they were re-checked by search, the unverifiable ones dropped, and replaced with confirmed sources (D. H. Hamer's wiring tables at enigmamuseum.com; Tony Sale's rotor spec; Wikipedia's "Enigma rotor details," which carries the same AAAAA → BDZGO check). Never cite a URL you have not confirmed exists.

Entry 8 — Video permission and credit

The Bombe footage is the author's own, filmed on site. Permission to publish it was obtained from the Trust (via Tilly Davis), on the condition of a specific credit: the clip must be identified as being of the model of the Bombe machine at Bletchley Park Trust. That exact wording was carried into the caption and treated as non-negotiable — a small but real instance of respecting a source's terms. Final caption: "The model of the Bombe machine at Bletchley Park Trust, in motion. Filmed by Hiroaki Kitano on 6 July 2026. Courtesy of the Bletchley Park Trust." Hosted unlisted on YouTube and embedded.

Entry 9 — Publishing: three wrong turns before the clean path

Getting Part 2 into Ghost took more iteration than expected, and the wrong turns are worth recording because each taught the actual constraint.

  • Wrong turn 1 — one giant HTML card. The first instinct was to paste the whole body, figure, simulators, and references as a single large HTML card. This made the figure and simulators impossible to manage as separate elements, and the "Going deeper" column lost its styling (its CSS depended on the theme, which didn't define it). Rejected.
  • Wrong turn 2 — simulators as separate Ghost Pages, embedded by iframe. The three simulators were published as their own Ghost Pages (which is genuinely useful — each now has a shareable URL). But embedding a Page back into the post via iframe pulls the whole page into the frame, site header and footer included, so the simulator appeared with the site's chrome wrapped around it. Structurally unfixable from the iframe side. Rejected for in-body display.
  • Wrong turn 3 — pasting Markdown source. Pasting the raw .md body into Ghost did not reliably convert **bold** and [links]; they showed as literal markup. Fixed by pasting rendered HTML (open in a browser, select-all, copy) so formatting converts to native cards.

The clean path came from looking at how Part 1 actually worked: its Turing-machine simulator is embedded directly in the body as its own scoped HTML card — no iframe, no separate page, no site chrome. Part 2 was rebuilt the same way: native prose, the figure as an Image card, each simulator as its own inline scoped HTML card, the column as a self-contained boxed HTML card, the video as a YouTube embed, and the references as one HTML card carrying the citation anchors. A too-small references font (a leftover from the iframe attempt) was reset to body size to match Part 1.

Entry 10 — Deployment package and routing

The final assembly was captured as a deployment package so the process is repeatable: the rendered body for pasting, the figure, the three simulator cards, the column card, the references card, captions, and a step-by-step assembly guide. Routing follows Part 1: the post carries a public primary tag Turing and an internal tag #deepdive; with routes.yaml in place (/deepdive/{primary_tag}/{slug}/, filtered on tag:hash-deepdive), the URL resolves to /deepdive/turing/the-bombe/, with 301s from any old flat URL. One publish-time gotcha logged: tag order matters — the primary tag must be first, or the URL segment is wrong.

Open questions / next

  • Part 2 has no companion theory essay the way Part 1 seeded intraspatial/transspatial; the natural companion here is operational, not theoretical (see next).
  • The operational whole of Bletchley. A recurring author interest that Part 2 only gestures at: Enigma-breaking was one input to a larger intelligence factory — decrypts fused into a reconstruction of the German order of battle, fed to operations, with elaborate source-protection so the enemy never learned Enigma was broken. That fusion (fragments → whole → action) is itself a discovery-shaped process and deserves a standalone column, with the management/operational angle the author is drawn to. Needs its own sourcing pass.
  • Phase-2 integrated demo. The Enigma and Bombe simulators are currently separate. The promised next step (to the Trust as well) is to chain them: encode a message, hand the Bombe a crib, recover the settings, decode — a much heavier build than the current schematic.
  • Japanese edition of Part 2, as a parallel-voice rewrite, not a translation.
  • Part 3 — Intelligent Machinery (1948) · learning. The question Part 2 ends on: can adaptation move inside the machine? The Bombe never learned; Part 3 follows Turing to where he first asked whether it could.

AI collaborators on this post

Human author: Hiroaki Kitano. Primary AI collaborator: Claude (Anthropic), with Gemini (Google) and ChatGPT (OpenAI) in the loop for cross-checking, alternative framing, and reference work. The four simulators were built and verified in the same collaboration; the Enigma-mechanics diagram was generated with ChatGPT and verified letter-by-letter against a historically accurate simulation. The reported sections draw on the author's visit to Bletchley Park on 6 July 2026. Final editorial judgment is the author's.