Decision 0001: v0 Kernel Architecture

Date: 2026-05-23 Status: Accepted

Context

Reverie is a research project building an AI that learns from observation alone — no external goals, no rewards, no success criteria imposed from outside. Goals must emerge from the system’s own dynamics, not be designed in.

Before writing any code for the v0 kernel, four architectural choices needed to be made. They are load-bearing — each constrains the rest of the design — so they’re recorded here with their alternatives and the reasoning behind each pick. Future decisions may supersede these; if so, a new ADR will reference and override this one.

Decision 1: Cell allocation — Hybrid

Chosen: The system starts with a small pre-allocated pool of cells (initial value: 32–64) and grows the pool when novelty exceeds capacity.

Alternatives considered

• Pre-allocated only. Fix N cells at startup; the system never grows beyond that. Rejected because committing to a fixed capacity upfront is philosophically pre-baked for a system that’s supposed to emerge from observation, and risks either over-provisioning (wasted cells, slower dynamics) or under-provisioning (saturation under novelty).

• Grown from zero. Start with no cells. The first observation creates the first cell, and so on. Rejected because it creates a chicken-and-egg problem: the first observation has nowhere to land if no cells exist, and distributed representation (multiple cells per concept) is impossible until the system has been running long enough to have spawned many cells. The system would behave very differently in its first few observations than later — an instability we’d rather avoid.

Why hybrid

Preserves the spirit of emergence (the system isn’t pre-committed to a final size) while making the engineering tractable. Even if v0 never triggers growth, the data structures will accommodate it, so we don’t have to retrofit a structural change later. Capacity-driven growth is also a clean rule: no arbitrary thresholds, just “grow when needed.”

Decision 2: Initial cell state — Blank, with operational noise

Chosen: Cells start with no preferences and no memory. Symmetry-breaking comes from small noise terms applied during each operational tick.

Alternatives considered

• Random initial preferences. Each cell starts with random weights across the (eventually-known) token space. Rejected because cells would have biases before observing anything — contradicting the principle that meaning emerges from observation. Random init is the ML default for a reason (it avoids the symmetry problem cleanly), but it imports an assumption Reverie is specifically built to reject.

• Seeded by a structural rule. Initialize cells with a deliberate scheme (positional, sparse-random patterns, etc.). Rejected because no obvious structural rule has more justification than another, and any choice would inject more design than Reverie’s philosophy permits.

Why blank + operational noise

Preserves the tabula rasa premise without the engineering pathology. The pathology, in detail: identical cells respond identically to identical input, learn identically, and can never specialize — every cell remains a clone of every other cell. Operational noise is small and content-free; it just breaks ties during processing. But because tiny early differences compound through later learning, it lets cells diverge from experience rather than from designed-in priors.

Decision 3: Output generation — Stochastic sample

Chosen: Output tokens are sampled from a probability distribution proportional to the aggregate cell activation across the token space.

Alternatives considered

• Weighted vote (deterministic aggregate). Every cell contributes to a vote weighted by activation; the highest-voted token always wins. Rejected because it’s fully deterministic given state, removing the system’s capacity to “wander” through possibility space — a property that aligns with the artist framing of Reverie.

• Winner-take-all (single cell decides). The most-activated cell selects the output (its top-preferred token). Rejected because it’s deterministic and brittle: one outlier cell can dominate output entirely, working directly against the distributed-representation goal stated elsewhere in the architecture.

Why stochastic sample

• Aligns with the artist framing — same state, varied output, generativity
• Enables exploration during internal excitation cycles: the system “wanders” through possibility space rather than locking onto a single trajectory
• Naturally handles low-vocabulary edge cases: when the system has seen only “1,” the distribution is peaked at “1,” so samples return “1” with overwhelming probability anyway
• Matches biological decision-making, which appears to be noise-driven rather than deterministic

Decision 4: Excitation timing — Discrete ticks under event-driven semantics

Chosen: Internally, the system advances in discrete ticks. Externally, the API is event-driven: observations interrupt; internal cycles run until stagnation.

Alternatives considered

• Pure continuous-time dynamics. State evolves continuously between events; observations and outputs are events on top of an ODE-like substrate. Rejected for v0 because it requires numerical integration just to take a single step, and the implementation cost outweighs the benefits this early in the project.

• Pure event-driven, no clock. The system runs internal cycles freely with no global tick rate. Rejected because, without a clock, stagnation, decay, and other time-dependent dynamics become hard to define cleanly.

Why discrete ticks + event-driven API

Discrete ticks are tractable to implement and reason about. Event-driven semantics at the API level capture what the architecture actually wants: the system runs internal cycles until stagnation, an observation interrupts and refreshes the cycle. The right combination of pragmatism and faithfulness to the architecture’s intent.

Implementation logistics (not architecture; recorded for completeness)

• Language: Python, NumPy
• Code location: ~/reverie/model/, co-located with the website source in the same git repository
• Source backup: pushed to bare repo on boomarche-prod (/opt/boomarche/reverie.git)

Open questions deferred to later decisions

These were not decided in this session and will be recorded in future ADRs:

• Cell types — when do mimicking, Hebbian, predictive, and abstraction cells get introduced as distinct populations? Are they architecturally separate or behavioral variants of one cell type?
• Learning rules — precise update equations for cell preferences and (later) inter-cell connections.
• Competition mechanism — the “asking” protocol (cells requesting strengthening, broadcasting inhibition to others).
• Stagnation — threshold for detecting stagnation, decay timescale, what state the system is in at the stagnation point.
• Feedback loops — how outputs of internal excitation cycles feed back into the system (or don’t), and how this changes the dynamics.