JSON holds data beautifully but has no answer for logic. String templates are error-prone and injectable. Custom DSLs are verbose and hard to validate. JavaScript functions are not serializable. S-expressions solve all three problems: they are structured, serializable, and executable, encoded as plain JSON arrays.

What if you defined your entire application in a single file before writing any component code? Not just the database model, but the state machines, the UI structure, the routes, and the business rules. That is how .orb works: write the schema, validate it, compile it, run it.

The same .orb file runs in the browser via an interpreter, compiles to a native Rust binary, and generates production TypeScript or Python code. Three execution models from one source of truth, each optimized for its environment.

In most games, enemy AI is a black box of nested conditionals and random weights. The player reacts to opaque decisions they cannot predict or outthink. In .orb, enemy behavior is a state machine the player can read, reason about, and exploit.

Programming a robot today means writing thousands of lines of tangled imperative code where every new condition doubles the complexity, hidden state transitions breed bugs, and documentation drifts from reality within weeks. .orb takes a different approach: declare machine behavior as composable traits with explicit states, guarded transitions, and structured effects.

State machines are the foundation of every .orb program. Every trait contains one, and the compiler enforces that they are well-formed. This post explains what a state machine is in .orb and walks through a concrete example.