Comparison

RAHN vs Git

The most common description of RAHN is "Git for networks". It is a useful gesture and a misleading summary. RAHN borrows Git's central mechanism — content-addressed objects forming an immutable history — but its payload, change model, and safety model are all different. This page makes the comparison precise, without attacking Git: for source code, Git is the right tool.

The real similarity

Both systems store immutable, content-addressed objects; both let you branch, diff, and merge; both make history a first-class structure rather than a side effect. RAHN's canonical serialization and SHA-256 ids are deliberately in that lineage, because the properties that made Git transformative for code — integrity you can verify, history you can traverse, identity independent of location — are exactly what network state has never had.

Where the analogy breaks down

1. Source code is text; network state is a typed model with semantics

Git's unit of meaning is a line of text in a file. RAHN's unit is a typed object — a node, an interface, a link — with topology semantics: reachability, isolation, connectivity. A "change" to network state can invalidate the meaning of the whole model even when every individual edit looks local. Text diffs cannot see that; semantic diffs are required, which is why RAHN's diff operates on the object model rather than on bytes.

2. Commits vs transitions

A Git commit is whatever you staged. A RAHN transition is an explicit operation from a closed vocabulary, applied purely to produce a new state value. The vocabulary is part of the contract: the set of possible changes is enumerable, inspectable before application, and explainable afterwards.

3. No verification gate in code hosting

Git will happily commit a repository that does not compile. RAHN will not commit a state that violates its constitution: verification precedes the commit, and the execution of any plan is structurally unreachable without a verification result. In Git-based infrastructure, correctness checks live outside the VCS in CI; in RAHN, the gate is part of the state machine itself, because the cost of a bad change is a broken network, not a broken build.

4. Merging means preserving meaning, not combining text

A three-way text merge combines lines. A network-state merge must combine semantics — two changes that are individually valid can be jointly invalid (both sides touching the same object, conflicting connectivity). RAHN's merge fails closed: conflicts are detected and explained, never silently resolved, at the known price of rejecting some mergeable states (a recorded limitation). Git's merge model would be actively dangerous here.

5. History has epistemology

Git history records what changed. RAHN history is annotated with causal memory — explicit edges between observations and commits, labeled with epistemic status — because in networking, "what changed" is usually asked after an incident, with the follow-up "what caused it?".

The honest summary

RAHN is what happens when you keep Git's content-addressed discipline and rebuild everything else for a domain where state has topology semantics, changes have physical consequences, and "verified" must mean something. If you want the one-sentence version: Git versions text; RAHN versions the meaning of a network — and gates every change on proof.

Go deeper