Operating systems mediate memory, process execution, storage, devices, and communication, but their security mechanisms do not automatically constitute a reviewable governance order. An access-control decision may be enforced without binding the exact subject, authority chain, policy revision, intended effect, observed outcome, and later repair route into one inspectable lineage. This paper proposes the Constitutional Operating System (COS) discipline: a specification framework for operating systems whose consequential operations are attributable to stable constitutional identities, admitted under finite delegated authority, subject to typed decisions and refusals, and connected to evidence and revision through integrity-protected records. COS is not an operating system and does not prescribe one kernel architecture. It defines obligations that candidate realizations must interpret, implement, and test. MosaiCOS is the paper's proposed Instance Configuration for general-purpose constitutional computing. It combines process and artifact identities, constitutional capability tokens, pre-effect decision commitments, post-effect observations, typed refusal, declared governance and bootstrap boundaries, governed sessions, hardware-effect attribution, and epoch succession. These are proposals and proof obligations, not evidence that a conforming kernel already exists. The paper corrects three important category errors. First, a hash-linked receipt can preserve a decision record without proving that the record is truthful, complete, independently observed, or causally effective. Second, a stable program identity is not the same as a unique execution-instance identity or a continuity relation across restart. Third, a user-space governance layer on Linux or OpenWrt may be a valuable transition profile without thereby becoming a COS-conforming kernel. The source's comparisons among Linux, seL4, Redox, Genode, and Fuchsia are therefore retained as hypotheses for a primary-source protocol-archaeology study, not as established compliance findings. The paper supplies that study design, a full Possibility-Specification-CM1-CM2-Instance Configuration-Implementation Realization-Evidence-Revision map, conformance levels, counterevidence conditions, and a bounded deployment spectrum. No implementation, conformance, novelty, or superiority claim is granted by this candidate.
No takes yet. Share an insight, caveat, or question.
Adam Ableman (2026) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: