Closed Loop Architecture: A Complete OS in Four Flat Lists

Most software design methods produce partial views of a system. A class diagram shows structure but not behavior. A sequence diagram shows one interaction path but not all of them. A state diagram shows one component's lifecycle but not how it connects to others. Each diagram is a projection — it takes the full system and flattens it onto one plane, discarding information in the process. Understanding the system means mentally reassembling these projections into a coherent whole. This reassembly is where designs break, where assumptions diverge between team members, and where implicit dependencies hide until they surface as bugs in production. The root cause is that projection-based methods divide the system by *view type* rather than by *what the system contains*. You get a structural view, a behavioral view, a data view — each cutting across every component. No single artifact tells you everything about one component, and no single artifact tells you everything about the system from any one angle. Closed Loop Architecture takes a different approach. Instead of projecting a system onto multiple partial views, it slices the system into four flat lists. Each list is complete from its own angle. The union of all four lists is the complete system. Adding a new slice — a new component, a new feature — means adding entries to the four lists. The existing entries do not change. The new entries interact with existing ones only through declared references, never through implicit coupling. The specification is closed under addition: you can grow it without opening it up. This paper describes the method, demonstrates it by specifying a complete operating system, and examines what the specification reveals about OS design that was not previously visible.