The first commit didn’t contain code. It contained rules.
January 5th, 2026. A new GitHub organization: canonic-machine. Commit 11affab.
Most organizations begin with a README that says “TODO.” A boilerplate license. Maybe a .gitignore. The code comes first. The governance — if it comes at all — arrives months later, usually as a crisis response to something that went wrong.
canonic-machine began with CANON.md.
Not a README. Not a LICENSE. Not a line of executable code. A governance document. A set of constraints. A declaration of what the system believes, what it must do, and what it must not do. The rules arrived before the implementation, the way a constitution is ratified before a government operates.
This wasn’t philosophy. It was architecture.
Why Rules First
I’ve spent 13 years writing code. In every project — HadleyLab, MammoChat, CovidImaging, MedBrain — the pattern was the same: build first, govern later. Ship the feature. Write the tests afterward. Document it when someone complains. Add compliance when the auditor calls.
The result is always the same. Technical debt compounds silently. Governance gaps become load-bearing. By the time someone notices, the foundation is cracked and the building is occupied. You can’t fix the foundation of a building people are living in. Not without evacuating. And nobody evacuates.
So I inverted it. Rules first. Code second. Define what’s valid before you build anything. Then every commit that follows is either consistent with the rules or it isn’t. The governance framework is the compiler. The rules are the grammar. Invalid states don’t compile.
The First Nine Lines
The first CANON.md in canonic-machine was nine lines. An axiom. Three constraints. A closing tag. That’s it.
Nine lines that said: this is what we believe. These are the constraints. Everything downstream inherits from here.
Nine lines. And from those nine lines, everything that followed — the triad, the inheritance model, the validators, the language specification, the ledger — was a consequence. Not an addition. A consequence. The way a tree is a consequence of a seed, not an addition to it.
The Paradigm
Software engineering has paradigms. Object-oriented. Functional. Declarative. Imperative. Each one answers the question: how should code be organized?
Governance-first programming answers a different question: what should code be allowed to do?
Not “how do we build it” but “what constraints must hold.” Not “what features do we ship” but “what invariants must survive.” The governance is not an afterthought. It’s not a layer on top. It’s the foundation — and everything else is built on it or it isn’t built at all.
MUST. SHALL. SHOULD. MAY. MUST NOT. The keywords of RFC 2119, repurposed as governance primitives. Constraints expressed in plain English, enforced by validators, inherited by every scope in the tree.
What Happened Next
Commit 11affab was the first of what would become 867 commits in 19 days. But on January 5th, it was just a file. A CANON.md in an empty organization. Rules in a room with no furniture.
The furniture was coming.
Figures
| Context | Type | Data |
|---|---|---|
| post | pipeline | steps: Define → Build → Validate → Deploy |
CANNON — Rules before code.