Density = Sovereignty

density = sovereignty

The phrase “density = sovereignty” is not a slogan. It is a design axiom that appears throughout Sigil’s spec system and informs several concrete language decisions.

What it means

Density in this context means: how much semantic content fits in a given surface area of code or specification.

A function signature that encodes its effects, its coordinate-space invariants, and its resource requirements is denser than one that just lists parameter types. It contains more information about the function’s contract, expressed more precisely, in less space.

Sovereignty means: the ability to reason about a system without depending on external context, conventions, or trust.

A codebase where invariants live in the type system is more sovereign than one where invariants live in documentation or code review culture. If the type checker enforces the invariant, you don’t need to trust that all contributors remembered the convention. The compiler is the sovereign enforcement mechanism.

The axiom says these are the same thing: as density increases, sovereignty increases. Sparse, convention-dependent code requires trust in the humans who wrote and maintain it. Dense, type-system-enforced code requires trust only in the type checker.

How it shows up in language design

Phantom types are a density mechanism: Vec3<Clip> carries more information than Vec3 in the same four characters.

Effect annotations are a density mechanism: fn foo() !io encodes in one token what would otherwise require documentation.

The ∂ operator is a density mechanism: one symbol encodes the full intent and semantic of differentiation.

The six non-negotiables F1–F6 are enforced rather than documented because documentation is low-density relative to type errors.

See also

• §E.1 Design Synthesis — R1–R18, the design rationales
• §A.4 Quick Orientation — F1–F6 non-negotiables