On this page
Editorial methodology
This page explains how each section of the site was produced, so a reader can judge how much weight to give it. The short version: most of the technical content here is faithfully extracted and cited, not independently validated. Where that distinction matters — and for anything safety-critical it always matters — the details below say exactly what was done and what was not.
How the Design Guide was made
The Design Guide’s 1,545 rules were machine-extracted from 143 source documents of the accelerator literature by AI extraction agents working in successive passes: a first pass over documents with usable text layers, a second pass over a dozen scanned classics that were freshly OCR’d for the purpose, and further passes over each new group of recovered documents as the Construction Classics collection has grown. Each rule carries the formula where its source gives one, a verbatim quote, a page-level citation, and an applicability note calibrated to a tabletop-class machine. Quotes and numbers were checked against page images wherever the OCR looked suspect — a check that earns its keep: in one case a detector bias voltage OCR’d an order of magnitude too high and was caught only against the page image.
Be clear about what this process produces. The rules are source extracts: faithful to their sources, but not independently validated engineering requirements. No one has re-derived each formula, rebuilt each machine, or reconciled the whole set into a consistent specification. Sources span eight decades; some are old, some describe one specific machine, some simplify, and some contradict each other. Transcription errors can also survive spot-checking. Any rule that drives a real design decision should be re-read at the cited page of the source before you rely on it.
Two checks run against that risk. Rules are audited by an external language model that does not see this site’s own reasoning, scoring each on fidelity to its quote, physics, overreach, and safety conservatism; every new batch of rules is audited before it is announced, and a random sample of the back catalogue is audited monthly. Every failed or flagged rule gets a written disposition — corrected, or declined with a stated reason. Corrections to published rules are made in place with a dated bracketed note, leaving the original source quote untouched, so a reader can see both what was said and what was wrong with it. The process exists because a review found a genuinely misleading safety rule that page-level proofreading could not have caught: the extraction was faithful, and the error was introduced by the editorial note written around it.
Each rule also carries an applicability level, 1–5, answering one question: how early and how universally does this rule bind a cyclotron design? Level 1 governs the feasibility of any machine; level 2 is first-order subsystem sizing; level 3 is commissioning and optimization; level 4 is second-order refinement or specific configurations; level 5 applies to large, unusual, or professional machines only. Levels are editorial, judged relative to the machine class each rule addresses, and they rank breadth, not weight — a level is never permission to skip a rule whose trigger a machine has, and safety rules are never skippable on level alone. They were assigned by a language model working from a written rubric with tie-break conventions and a hand-reviewed anchor set of about 85 rules (2026-08-23): a two-pass calibration on a 100-rule sample was required to meet predeclared agreement thresholds before the full run (it scored 88% exact and 100% within one level, against required minimums of 60% and 95%), every level-1 assignment plus a random sample was then re-audited, and two demotions from that audit were applied before publication. Future rule batches are ranked against a frozen benchmark set: a ranker must reproduce the calibration sample within one level 95% of the time before its rankings are accepted. Some domains have no low-level rules by structure rather than omission — no beam-measurement rule gates feasibility, for example — so a domain whose levels start at 2 is being described, not short-changed.
How the Library was indexed and scored
The Library is an annotated index of 261 documents. Each entry is scored on two editorial axes: amateur relevance (how useful the document is to someone designing or building a small cyclotron) and hands-on (concrete engineering content versus pure theory). The scores and annotations are editorial summaries — a reading lens, not a measure of a document’s scholarly quality.
The Library is a bibliography first. Outbound links are added only where a document is legitimately available (DOI, OSTI, arXiv, publisher, or open archive), and each link is verified before it is added. Where rights permit — principally US Government reports of the AEC era, which are public domain — the site also preserves its own verified copy, so that a document the Design Guide draws rules from stays readable at a stable address. Those 51 entries are marked “hosted” and link to a document page carrying the full citation, the PDF, and a written rationale stating exactly why hosting that document is lawful. Nothing is hosted without that rationale, and the copyrighted majority of the collection remains cite-only. The rights basis is established by reading the scan itself rather than inferring it from a report series: a laboratory report number can still wrap a copyrighted journal reprint, conference proceedings are frequently copyrighted, foreign works are not US public domain, and a university thesis belongs to its author even when the work was federally funded.
How the Legal survey was produced
The Legal survey is multi-source desk research. The federal layer and all 51 US jurisdictions (50 states plus DC) were independently verified against the current text of the relevant statutes and regulations, as of August 2026. Where secondary sources disagree with each other or with the statute, the survey presents the more conservative reading. It is a dated snapshot of published law, compiled by non-lawyers: it is information, not legal advice, and anyone planning an actual machine should confirm requirements with the cited regulator.
How Locations data is verified
The Locations database is hand-curated against primary sources — facility websites, operator publications, national regulators, and international registries. The sources themselves are published as an annotated registry directory, with the coverage and known failure modes of each. Facilities change status quietly, so each record carries a last-verified date in the source data, and entries not re-verified within five years are flagged there rather than silently presented as current. Because most sources announce new installations and almost none announce shutdowns, periodic national publications are weighted heavily: they are the only reliable evidence that a machine has gone.
How calculators are validated
Each calculator states the physical model it implements, lists its assumptions and limits of validity, and links the derivation. Before publication each was checked against worked numerical examples with known answers — textbook cases and published machine parameters. They are design-study tools built on standard, cited physics; they do not replace detailed engineering analysis of a real machine.
Status vocabulary
To keep the site’s claims exactly as strong as they deserve to be, technical content is described with four status terms:
- source extract — faithfully extracted from a cited source, quote and citation preserved; not independently checked beyond OCR/transcription spot-checks. This is the current status of every rule and quote in the Design Guide. It does not cover the editorial note under each rule: that note is this site’s extrapolation of the source to a tabletop-class machine, written here, and is labelled as such on every card. The external rule audit scores those notes for overreach precisely because they are the one layer the source cannot vouch for; the first monthly sample found the extraction sound (two fidelity findings in fifty) and nearly every defect in the notes.
- editor-checked — additionally verified by the site’s editorial process: numbers recomputed, links and citations confirmed, or claims cross-checked against a second source. Calculators, the legal survey, and outbound links are in this category.
- independently reviewed — reviewed by a qualified person unaffiliated with the site’s production. No content currently carries this status.
- field-validated — confirmed against a real, operating machine. No content currently carries this status.
Today, everything technical on this site is source extract or editor-checked. The vocabulary exists so that if content is ever upgraded — an independent review, a validation against a running machine — the upgrade will be visible and dated, rather than implied by tone.
AI disclosure
The extraction of design rules, the indexing of the library, and the assembly of this site were performed with AI assistance, working under editorial rules that require every claim to keep its source citation and every safety bound to take the conservative reading where sources disagree. AI extraction is what made a corpus of this size and citation density practical; it is also why the Design Guide’s rules are labeled source extracts rather than validated requirements, and why every rule tells you exactly which page to verify it against.
Corrections
Errors reported to [email protected] are corrected in place, and substantive corrections are noted in the changelog. Reader corrections are welcome and credited on request.