Spiral One

OVERVIEW

The system I built to build systems.

The models keep getting better. That wasn't really my problem anymore.

My problem was everything around them.

Important information gets trapped in a session. Context disappears. A model spends time figuring out something another model already figured out yesterday. You stop halfway through a build and spend part of the next session reconstructing where the hell you were.

So I built Spiral One.

IMPLEMENTATION NOTES

Technical architecture

Spiral One is a local-first control plane around AI-assisted software development. The distinction I make is that the model is not the development system. The model is one worker inside a larger system that owns more of the continuity around the work.

The control surface is built in Next.js, React and TypeScript. Provider execution currently connects through the Codex App Server protocol. Around that, Spiral One maintains its own execution services, context compilation, adaptive objectives, runtime threads, verification evidence and local durable state.

Execution is sequential in the implemented workflow. Spiral One is not currently a parallel autonomous-agent swarm, a cloud scheduler or a complete replacement for the underlying provider environment.

IMPLEMENTATION NOTES

Context compiler + reference intelligence

Source material can be ingested and decomposed into smaller, addressable knowledge objects rather than remaining one giant document the model has to reread.

Those objects retain relationships and provenance back to their source. Retrieval can be scoped around objective, component, failure mode and constraints, then compiled into a bounded brief for the work in front of the model.

The point isn't to permanently compress everything. It's to avoid spending context and reasoning on information that has nothing to do with the current decision.

IMPLEMENTATION NOTES

Adaptive execution + model routing

Adaptive execution starts with the objective rather than immediately handing the whole thing to a model. For work complex enough to require decomposition, Spiral One can create sequential execution units and compile context for each attempt.

Routing can consider runtime availability and characteristics of the work when selecting model and reasoning effort. Manual mode still lets me explicitly select the model and effort when I want direct control.

The current cold-start router is a versioned, evidence-generating heuristic. I don't describe it as a learned ML routing policy.

IMPLEMENTATION NOTES

Spiral Council

Council sits upstream of decisions that benefit from more than one perspective. The perspectives can evaluate architecture, user interaction, failure modes, assumptions and objective alignment.

The outputs remain distinguishable long enough to expose disagreement, overlooked constraints and competing priorities. Findings can then be synthesized into something actionable.

Council isn't required for every task. Sometimes the answer really is just change the button.

IMPLEMENTATION NOTES

Evidence-based verification

Provider completion and objective verification are separate states in Spiral One. A model can report that it changed something successfully. Spiral One can then ask whether there is independent evidence supporting that claim.

Evidence can include terminal state, command exit codes, declared artifacts, expected files, file inspection, tests and acceptance evidence.

The flow is Execution Complete → Collect Evidence → Compare Against Objective → Verified / Unsupported / Requires Inspection.

IMPLEMENTATION NOTES

Fractal Holistic Recursive Audit

FHRA is essentially Spiral One's multi-scale inspection system. The same change can be evaluated across component, interaction, screen, workflow, product and system.

The recursive part matters because findings can produce another intervention, which can then be inspected again: Inspect → Find → Correct → Zoom Out → Reinspect → Repeat.

A route-contract fixture demonstrates this at a scoped level. It is not presented as proof of full recursive cross-scale correction.

IMPLEMENTATION NOTES

Empirical Knowledge Ledger

The Empirical Knowledge Ledger is where individual builds can start becoming reusable experience. I care about what was attempted, under what conditions, what actually happened, what evidence supports that outcome, whether it generalized and whether we should use it again.

A single successful attempt doesn't automatically become a universal rule. Some knowledge stays project-specific. Some belongs as a heuristic. Some earns confidence because it keeps surviving different builds.

When something becomes repeatable and measurable, it may become a deterministic check, a guardrail, a default or another piece of infrastructure.

IMPLEMENTATION NOTES

Durable state + recovery

Spiral One deliberately separates provider-thread state from Spiral-owned state. The provider owns the active provider interaction. Spiral One owns durable records around the work.

An interruption can be represented honestly: Running → Interrupted → Reconcile → Paused / Recoverable → Inspect → Resume.

Recovery is moving toward stronger self-modification boundaries, but validated source rollback and known-good promotion are direction, not current capability.