Skip to content

Architecture Decision Records

Every system is shaped by the decisions made early — and the ones nobody questioned later. This section documents the why behind Nexus OS: what was chosen, what was rejected, and what the consequences are.

These are not post-hoc rationalizations. Each decision has trade-offs, and we list them honestly.

Decision Log

IDDomainDecisionKey Trade-off
K1KernelUnikernel over monolithic kernelPOSIX compat needs Membrane translation
K2KernelZig HAL + Nim kernel logicTwo runtime ecosystems to maintain
K3Kernel12 frozen syscalls over full POSIXNo dynamic extensions possible
K4KernelION Rings over pipes/socketsRequires pre-allocated ring capacity
K5KernelTickless event-driven schedulerSoftware timeouts need explicit registration
K6KernelFibers over processes/threadsNo true parallelism on single core
A1KernelSingle address spaceRequires static VA partitioning
A2KernelSysTable frozen ABICannot extend beyond 240 bytes
A3KernelDragonflyBSD LWKT scheduler modelNot perfectly fair for batch workloads
A4KernelNo microkernel message-passingApps implement own protocols
S1SecurityCapability algebra (7 verbs)Requires app rewrite for POSIX compat
S2SecurityPledge/Unveil over SeccompNo runtime policy changes
S3SecurityKinetic economy (energy-budget DoS)Applications see rate limiting as latency
S4SecurityTOFU+ over PKIVulnerable to MITM on first contact
ST1StorageGraph-native filesystem (NexFS)Hash computation on every write
ST2StorageNo /dev, /proc, /sysLegacy tools need Membrane translation
ST3StorageCBOR wire formatLarger than hand-optimized binary
N1NetworkTCP/IP in userland (LwIP)50-100 KB memory per application
N2NetworkUTCP over QUICLimited to Nexus ecosystem
N3NetworkL2 switching only in kernelARP less efficient on large segments
H1HypervisorType-1 hypervisor (RumKV)Must support each hardware platform directly
H2HypervisorDual-Pledge enforcementHypervisor debugging harder
H3HypervisorSpatial-only partitioningUnused cores wasted on idle cells
P1PackagingSix package typesHigher learning curve for developers
P2PackagingGraft → Evolve → SovereignizeMixed code quality in intermediate versions
P3PackagingGoboLinux hierarchyBreaks FHS-dependent tools
P4PackagingKDL over YAML/TOMLNew language, immature tooling

Format

Each record follows a consistent structure:

  • Context — What problem prompted the decision
  • Decision — What was chosen
  • Alternatives — What was rejected and why
  • Consequences — What this means (good and bad)

Decisions marked Accepted are in effect. Decisions marked Superseded have been replaced by a later ADR. We don't delete superseded records — they document the evolution.