Closed Loop Architecture, described in HOWL-COMP-12-2026, specifies systems using four flat lists. The first list assigns every noun in the system a cardinality: Zero, One, or Infinity. Zero means the system references the concept but has no runtime representation of it — the concept exists in the specification so that the specification is complete, but no code creates, updates, or destroys instances. One means exactly one instance exists for the lifetime of the system — a singleton. Infinity means a population of instances exists, with members created and destroyed dynamically. In that paper, cardinality was presented as an architectural tool. Assigning cardinalities to entity groups determined their interaction patterns mechanically: One interacting with Infinity produced fan-out or convergence, Infinity interacting with Infinity produced list-to-list filtering, Zero interacting with anything produced pure event sequencing. The tool was applied to specify a complete operating system, and the cardinality assignments revealed structural properties of OS design that were not previously visible: fifteen singletons orchestrating twenty populations, nine autonomous decision points out of thirty-seven entity groups, failure handling structurally identical to normal operation. This paper makes a different claim. The three cardinalities are not an organizational tool that a specification method happens to use. They are intrinsic properties of information processing. Any system that processes information — whether implemented in silicon, described in mathematics, executed by biological cognition, or organized in human institutions — must contend with three distinct modes of existence: things it references but cannot operate on, the single unit of actual work, and multiplicities that must be reduced to a single unit before work can proceed. These three modes have fixed natures. Their interaction patterns are consequences of those natures, not design decisions. Ignoring them does not eliminate them. It produces the specific classes of problems each domain considers hardest. The paper proceeds by examining each cardinality in isolation, then their interactions, then the consequences of violating their natures, and finally their appearance across domains outside software engineering.
Geoffrey Howland (Mon,) studied this question.