In responding to a recent security problem I had to consider the idea of intent in computer software, so I looked to see what Margaret Hamilton ↗ has to say. Hamilton proved her ideas spectacularly during the first Apollo moon landing in 1969. A hardware failure generated unexpected errors ↗ , but the software coped by running the highest-priority tasks despite the barrage of errors and prevented an abort just seconds before landing on the surface. I eventually found two 1994 articles of hers in Electronic Design magazine: one explaining her Development Before the Fact philosophy , and one describing the tools built from it . After discussion with the current magazine editor, I was able to clean up the scanned text of both and document Hamilton’s prescience.

I want to apply her observations on reliable and secure systems. Despite spending four decades telling the world how to make reliable software very few people have put her ideas into practice, and none in the integrated manner she promoted.

Margaret Hamilton at the Apollo command module simulator
Margaret Hamilton at the Apollo command module simulator. Image courtesy MIT Museum (GCP-00009683).
Cover of Electronic Design Software Engineering Supplement, 4 April 1994
Electronic Design Software Engineering Supplement, 4 April 1994. Click to read the reconstructed PDF.

Hamilton’s vision

The finding that started it came from Apollo. Hamilton reports that interface errors accounted for about 75% of all defects found in the flight software during final testing, and that Development Before The Fact was derived to make that entire class impossible to express.

In the article, Hamilton describes a system design language built around behaviour in time and space: FMaps for what a system does over time, TMaps for the data and objects it acts on. The piece reads to 2026 eyes as though it describes:

  • algebraic data types, what we call generics in Rust, Haskell, OCaml and TypeScript.
  • constraints as first-class citizens of the language, with niche implementations in Liquid Haskell, F* and a few others.
  • named domain patterns with attached rules, which Rust calls typestate and which appear in the literature as session-types.
  • runtime instances typed by static structure, which seems to be pretty close to formal verification methods now used by many organisations ↗ but few overall
  • end-to-end object traceability, where any specification, bug or feature can be followed through its implementation and execution

In the decades since we have seen slow progress in implementing parts of this vision here and there, but nothing integrated in the way she advocated. Hamilton published a companion article ten weeks later describing the 001 Tool Suite, the commercial environment intended to implement Development Before The Fact in practice. I have reconstructed that article too.

Different kinds of intent

If we divide intent into two kinds, we can see Hamilton and just about everyone else focusses on only one of them:

Horizontal intent is the question Margaret Hamilton asked: “does what we say in code match what we actually wanted?” This is the realm of requirements engineering, or what is now called AI alignment and specification gaming.

Vertical intent is the question that very few focus on, that of whether what we say in code is faithfully transmitted by the toolchain down to the running silicon. This is Ken Thompson’s Reflections on Trusting Trust ↗ , and the xz supply chain incident ↗ .

Vertical intent checking is missing

Hamilton has nothing to say about vertical intent, although some aspects of reproducible builds, diverse double-compiling and a few niche technologies do address it. The idea of the Trusted Computing Base (TCB) is an important starting point, where we establish the correctness of the set of hardware, firmware, compilers, libraries etc before we can make any promises about how a piece of software will run. But the community that works on these topics seem quite far removed from the everyday tools that need to be made reliable. Most engineers have little idea what is in their own toolchain’s TCB, and do not have integrity checking in place in this vertical sense. Reproducible builds are becoming more common and that helps, but it seems ‘intent’ in this sense is not well-addressed.

And so I discovered that even Margaret Hamilton couldn’t help with this particular kind of software integrity.

Margaret Hamilton at the Intrepid Museum, 2019
Margaret Hamilton at the Intrepid Museum, 2019.

The 001 Tool Suite

Cover of Electronic Design Software Engineering Supplement, 13 June 1994
Electronic Design Software Engineering Supplement, 13 June 1994. Click to read the reconstructed PDF.

Hamilton’s June 1994 companion article, 001: A Full Life Cycle Systems Engineering and Software Development Environment , shows what Hamilton Technologies built from the April theory. Development Before The Fact was meant to prevent errors by making the system definition strong enough to rule out bad designs. The 001 Tool Suite was the commercial product built around that idea, covering requirements, design, generated code, simulation, documentation and project management.

The suite had names that now sound like a private language. The pieces are understandable. Manager(x) manages project objects and workflows. RT(x) traces requirements through the system. RAT generates code and documentation from the FMaps and TMaps. Datafacer builds user interfaces from the data definitions. Xecutor runs the model before production code is generated. In modern terms, Hamilton was describing an integrated development environment where requirements, types, execution, testing and builds all knew about each other.

Hamilton reported that the 001 suite generated itself: about 800,000 lines of code per platform across the HP 700 series, the IBM RS/6000, SunOS and Solaris, and Digital’s Alpha Unix, with about seven million generated lines across versions. She claimed productivity improvements from 10:1 to 100:1 over traditional C development, and that the ratio rose with the size of the system because reuse compounds. The National Test Bed put that to an independent test, giving the same real-time distributed problem to three contractor teams under 2167A rules. Of the three, only the 001 team generated fully production-ready code, running in both C and Ada from one definition. The big claim was that one systems language and one suite could carry intent from requirements through to running software.

A lot of the pieces became ordinary. VS Code extensions let developers reshape their working environment. OpenAPI and protobuf generate client and server code from specifications. Simulink and SCADE let safety-critical engineers simulate models and generate code. GitHub Actions and similar systems connect source, tests and deployment. They are familiar answers to questions Hamilton was asking in 1994.

The industry adopted the pieces through text formats, open protocols and separate tools. Programmers wanted files they could diff, grep, merge, review and feed to other programs. Testing survived. Her closing section expected otherwise, saying that verification becomes an obsolete process and that testing tools for finding the majority of errors are no longer needed because those errors no longer exist. That is the one prediction that went the other way. Generated systems still need trusted generators, verified compilers, fuzzing, property tests, model checking and production monitoring. The June article deepens the point about horizontal intent: Hamilton understood the need to connect intention to implementation better than almost anyone, and much of the field moved in her direction without adopting the 001 Tool Suite itself.

Vertical intent is the one thing the 001 suite could not supply. Everything it produced was only as trustworthy as the generator that made it, and that question was open in 1994. It is still open now.