explaingit

ramxx/machinery

Analysis updated 2026-05-18

7GoAudience · developerComplexity · 5/5Setup · hard

TLDR

A design methodology and toolchain that turns a software state machine design into machine checked tests, architecture rules, and formal proofs of correctness.

Mindmap

mindmap
  root((machinery))
    What it does
      Models as state machine
      Derives tests and docs
      Proves correctness
    Tech stack
      Go
      TLA+
      Alloy
    Use cases
      Formal verification
      Agent design
      Coding agent handoff
    Audience
      Software architects
      Senior developers
      Agent builders

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

What do people build with it?

USE CASE 1

Design a system as a state machine up front, then generate tests and build instructions from that single source of truth.

USE CASE 2

Formally verify that a system design terminates correctly and has no deadlocks using TLA+ and TLC.

USE CASE 3

Give a coding agent a detailed, unambiguous build document to implement a feature under strict test driven development.

USE CASE 4

Model the control loop, budgets, and approval gates around an AI agent as a provable state machine.

What is it built with?

GoTLA+AlloyXStateTLC

How does it compare?

ramxx/machinerydemomanito/helperemersion/minilustre
Stars777
LanguageGoGoGo
Last pushed2023-03-072019-01-07
MaintenanceDormantDormant
Setup difficultyhardeasymoderate
Complexity5/51/54/5
Audiencedevelopergeneralresearcher

Figures from each repo's GitHub metadata at analysis time.

How do you get it running?

Difficulty · hard Time to first run · 1day+

Requires learning machinery's layered modeling approach and the TLA+ and Alloy formal verification tools it relies on.

No license terms are given in the README excerpt.

In plain English

machinery is a design methodology and toolchain built around one idea: describe your software as a state machine first, and let everything else, tests, architecture rules, build instructions, and formal mathematical proofs of correctness, be generated from that single description instead of written by hand and then hoped to match it. The project exists because AI coding tools make it easy to write software quickly but do not make it easy to write software that stays correct as it grows. On anything beyond a small toy project, the actual code tends to drift away from the original design over time, an important rule gets broken somewhere far from where it was defined, and problems only surface once something breaks in production. The usual fix, reviewing code carefully by hand, really just means trusting the AI model, and that does not hold up at scale. machinery instead treats correctness as something you build and check mechanically, not something you simply hope for. To do this, machinery splits a software design into three layers that build on each other: a domain model describing the entities and rules that must always hold true, an architecture layer describing the system's components and what happens when each dependency fails, and finally state machines describing every state, transition, and failure mode, much of which is automatically derived from the earlier layers rather than written from scratch. The end result is a build document detailed enough for a coding assistant with no prior context to implement it under strict test driven development, plus the state machines themselves, which double as both the tests and the formal specification. The formal checking is done with established academic tools rather than invented ones: TLA+ and its model checker TLC exhaustively verify that a design terminates correctly and avoids deadlocks, while a separate tool called Alloy checks structural rules that are not about sequences of steps over time, such as access control or uniqueness constraints. The project also applies this thinking to AI agents themselves, modeling the surrounding control loop, tool calls, budgets, and approval steps as a provable state machine, while treating the AI's own decision making as something it constrains but does not try to formally prove. The project is written in Go and ships continuous integration, formal verification, security, and nightly test pipelines, visible as badges on its repository page.

Copy-paste prompts

Prompt 1
Explain machinery's three layer design: domain model, architecture, and state machine.
Prompt 2
Walk me through how machinery uses TLA+ and TLC to formally verify a state machine design.
Prompt 3
Help me understand how machinery generates a BUILD.md file that a coding agent can implement from.
Prompt 4
Show me how machinery models an AI agent's tool calls and approval gates as a state machine.

Frequently asked questions

What is machinery?

A design methodology and toolchain that turns a software state machine design into machine checked tests, architecture rules, and formal proofs of correctness.

What language is machinery written in?

Mainly Go. The stack also includes Go, TLA+, Alloy.

What license does machinery use?

No license terms are given in the README excerpt.

How hard is machinery to set up?

Setup difficulty is rated hard, with roughly 1day+ to a first successful run.

Who is machinery for?

Mainly developer.

Open on GitHub → Explain another repo

This repo across BitVibe Labs

Verify against the repo before relying on details.