nox explanations
conceptual documentation — why nox works the way it does, the design choices behind it, and the consequences that emerge.
these pages illuminate the architecture. for formal definitions, see reference/. for task-oriented instructions, see docs/guides/ (when available).
pages
| page | topic |
|---|---|
| why-nox.md | the frozen foundation — what nox enables and why the patterns never change |
| lineage.md | from combinatory logic to nox — two lineages meet: minimalism and convergence |
| completeness.md | why exactly these instruction groups — structural, field, bitwise, hash, hint |
| structural-patterns.md | the five tree patterns — axis, quote, compose, cons, branch |
| field-patterns.md | the six field patterns — add, sub, mul, inv, eq, lt over Goldilocks |
| bitwise-patterns.md | the four binary patterns — xor, and, not, shl and the two-algebra problem |
| nouns.md | the one data structure — binary trees of field elements, and why nothing else is needed |
| triple.md | object, formula, focus — the three inputs and why the third changes everything |
| layers.md | the ontological separation — truth, possibility, speed |
| confluence.md | why evaluation order is irrelevant — and why that enables a planetary cache |
| hint.md | the boundary of knowledge — one instruction that provides privacy, search, and oracles |
| content-addressing.md | every computation has a name — the seed of planetary memoization |
| proof-native.md | execution IS proof — why there is no circuit compilation step |
| jets.md | optimization without compromise — from patterns to silicon |
| self-verification.md | the system that verifies itself — recursive proof composition to arbitrary depth |