Skip to content

Weirich — Connascence (Grand Unified Theory of Software Design)

Connascence is a taxonomy of coupling: two components are connascent when a change in one requires a corresponding change in the other to stay correct. Page-Jones named it; Weirich revived it as a “grand unified theory” with a spectrum from weak/static (connascence of name — agree on a name) through stronger static forms (type, meaning, position, algorithm) to the dynamic ones (execution order, timing, identity). It comes with two operating rules:

  • Rule of Degree — convert strong connascence into weaker connascence.
  • Rule of Locality — the farther apart two elements are, the weaker the connascence between them must be.

It’s the sharpest available vocabulary for reasoning about where to put a boundary and how much the two sides are allowed to know about each other.

  • NoshAPI is connascence-of-name by design — the weakest static form, at the greatest distance. Carts couple to the runtime only by agreeing on the names of ~54 FFI primitives (text-puts, spawn-cell, advance-phase, …). Cart and runtime are maximally distant (separate repos, separate authors, separate release cadence), so Rule of Locality demands exactly the weak, named coupling the FFI surface provides. This is why the contract is a flat symbol table and not a shared struct layout.
  • The capability boundary is a connascence firewall. “Loading the System- tier UI kit into a cart context raises ‘unbound symbol’ by design” (kn-86 CLAUDE.md) — the runtime refuses to let carts form connascence with privileged internals. That’s Rule of Degree enforced by the interpreter.
  • A review heuristic for the C Engineer / QA. When a runtime change forces a matching edit in every cart, that’s strong connascence leaking across the widest boundary in the system — the thing to refactor toward name/type. Worth naming explicitly in the cart-authoring grammar and FFI-versioning docs.