Open Manual

<!-- nytrix-doc: {"audience":"contributor","featured":true,"group":"learn","order":190,"summary":"Comprehensive guide to Nytrix system architecture, 17 design principles, module boundaries, type system discipline, and subsystem seams."} -->

Architecture & System Design

Nytrix is built around single-owner layers, deep modules, strict type discipline, and clear subsystem boundaries. This document outlines the architectural principles, design workflows, and invariant boundaries that govern the codebase.

1. Design Workflow: Design Before Implementation

Before implementing significant changes or refactoring subsystems:

1. **State the Problem**: Define the precise behavior that is broken, missing, or under-specified.

2. **Exhaust the Design Space**: Formulate and evaluate at least three concrete alternative approaches before writing code.

3. **Redesign from First Principles**: Avoid stacking patches or shims on top of structural defects; address the root cause in the owning layer.

4. **Subtract Before Adding**: Remove obsolete pathways, redundant abstractions, and dead state before introducing new machinery.

5. **Outcome-Oriented Execution**: Define measurable, verifiable success criteria and executable proofs upfront.

2. The 17 Core Design Principles

Nytrix development follows 17 design principles categorized across structural, code quality, and process axes:

Structural Principles

Code Quality Principles

Process Principles

3. Subsystem Ownership & Boundaries

Every behavior in Nytrix has exactly one owning layer:

SubsystemSource LocationOwned Responsibilities
**Language Frontend**src/code/Grammar, AST, semantic analysis, Hindley-Milner type inference, compile-time evaluation.
**Intermediate Representation**src/code/native/ir.h<br>src/code/native/ir/Target-independent SSA optimization, canonical control flow, loop analysis, verifier authority.
**Native Code Generation**src/code/native/Machine form representations, register allocation, ABI lowering, object emission.
**Runtime & Execution**src/rt/Memory allocator, garbage collection, dynamic value dispatch, platform primitives.
**CLI & Tooling**src/cmd/Standalone CLI tools (ny, test, fmt, fuzz, perf, doc, web, dap, lsp).
**Standard Library**lib/Public user-facing modules, collections, operating system bindings, and networking.

Boundary Invariants

4. Architectural Decision Records (ADRs)

When proposing major architectural changes, document the decision with: