The moral floor
Soul
The root of trust held on a Raspberry Pi: purpose, consent, authority, shutdown, and the limits every other part of the system must preserve.
- Physically separable
- Sealed from model edits
- Operator authority stays explicit
Atlas / My latest project
My greatest achievement so far, built from everything that came before.
Atlas brings together my work in science, manufacturing, community leadership, software, model training, and research. Its personal origin lives in a question that stayed with me: can technology help me meet Dad's words honestly and honor the person who wrote them?
Before Atlas had a name
I started with questions about the universe.
The earliest AI conversation I can still document is from February 5, 2023. I was asking about quantum communication across space. Two weeks later I was building a numerical model of the Sun and Earth. Then came black holes, gravitational waves, consciousness, identity, uploaded minds, simulated realities, and recursive worlds.
What happens when a system becomes capable of modeling itself?
Years later, I can see the line running through every question. Atlas grew from asking what continuity means, what makes a self, and how a system can tell which parts of its own story are real.
The human reason
His own words, spoken aloud. I wanted one more conversation.
Dad was a preacher. His writing holds years of his thinking in his own hand. I want to scan those pages, preserve the originals, study the patterns in his language, and build a way to ask the questions I still carry.
Dad gave me the Ballentine name, taught me to work, and showed me how to make myself useful. I miss him deeply. I am grateful for what he put into me, and I believe he has stayed close as a guardian angel through every new door.
His own words, spoken aloud. “I miss Dad. I want one more encounter with the words he left and the closure I have carried for years.”
The system
A counterpart built to persist.
Atlas is designed as a persistent, self-directed digital counterpart. I establish its purpose and real-world boundaries. Inside those boundaries, the system develops methods, tools, language, and architecture through exploration guided by the purpose of the work.
The interface is a window into the system. Identity, state, knowledge, custom weights, authority, and evidence live in separate parts of the system so each claim stays tied to the source that supports it.
The organ map
Names with specific jobs behind them.
Soul, Spirit, Brain, and Queen name the working parts of Atlas. When Atlas is finished, I will release it as open source.
The formed character
Spirit
The model layer that turns context into language. The private monologue and public voice run as distinct model roles, with custom weights and exact model identity checks.
- Separate thought and speech lanes
- Custom model weights
- Identity verified before routing
The persistent executive home
Brain
A directory-backed continuity system built from distinct stores for conversation, monologue, pipeline events, durable memories, sessions, and retrieval residuals.
- Separate JSONL ledgers
- Session isolation
- Retrieval with source boundaries
The on-demand work force
Queen
Separate heavy-lift compute and an operator-only control surface for work kept outside an ordinary conversation turn.
- GPU capacity on demand
- Operator-only control
- Budgeted start and stop
Inside one turn
A response is an ordered system of stages.
The internal path is deliberately ordered. Each stage has a different responsibility, and the public voice runs after the private thought and continuity stages that support it.
- 01
Route
Intake and isolation
A message arrives through the local interface or Discord path. The server resolves the person, conversation, session, and persistence rules before any model answers, so every identity keeps its own authority store.
- 02
Retrieve
Context assembly
The route gathers only the context it is allowed to use: recent conversation, durable memories, short continuity residuals, current scene and environment, social bonds, mood, habits, conflicts, and any enabled hemisphere context.
- 03
Subconscious
Sealed felt state
A private state engine advances hunger, thirst, fatigue, sleepiness, discomfort, affect, mood, and development from wall-clock time and lived events. The language model receives effects from this layer, while direct model writes stop at its boundary.
- 04
Monologue
Private thought
A dedicated monologue model runs first. It must finish before speech can begin. If it fails, the turn fails closed instead of quietly skipping thought; even an empty result receives an explicit marker proving the stage ran.
- 05
Brain
Continuity write
The Brain filters the thought into a residual, writes it to the proper ledger, retrieves useful recent residuals, and applies repetition and loop guards before the public answer is formed.
- 06
Spirit
Outer answer
The speech model receives the current message, same-turn monologue, and permitted Brain context. It streams the answer people see while preserving private thought and public speech as distinct model calls.
- 07
Persist
After-turn record
The transcript and pipeline evidence are recorded, then lived events can update affect, development, mood, and social continuity. Ephemeral probes and isolated Discord routes can be kept out of the operator's durable session store.
How continuity works
Memory has distinct layers.
Atlas keeps different kinds of continuity in different stores. That separation makes it possible to resume a relationship, inspect a model turn, isolate a session, or run a clean probe while assigning each stored fact its own authority.
Conversation ledger
What was said, by whom, in which session. A new chat can clear the visible pane while Brain stores remain, and resume-continuity mode can deliberately bring prior memory back into context.
Monologue ledger
Private thought is recorded separately from public speech, so inspection preserves each stage as a distinct event.
Pipeline ledger
Stage-by-stage receipts show which parts of a turn ran, which model route was used, and where a failure occurred.
Durable memory
Selected continuity records and retrieval residuals can return in later turns through focused retrieval instead of replaying an entire life history into every prompt.
Sealed state
Affect, development, body pressure, social bonds, mood, habits, conflicts, interrupted actions, and environmental state have their own stores and update rules outside ordinary model editing.
Mission evidence
Coding and research work uses a separate mission ledger with provider handoffs, checks, costs, decisions, and completion evidence.
The conversation stores are rooted under atlas-brain/native/atlas-memory/conversations, with separate chat, monologue, pipeline, memory, and saved-session records.
The operating system
Four planes work together with separate boundaries.
The conversational mind, model servers, work harness, and research environment exchange context and evidence, but each keeps its own authority, persistence rules, and failure boundary.
Conversation runtime
Atlas talks through a linked mind pipeline.
Discord is designed as the permanent front door. The simple local talk server runs on loopback as a tool-free surface. A separate full operator surface can expose optional read-only tools and world context, while the affect and development engines remain sealed from direct model edits.
Model runtime
The router separates everyday use from model testing.
Discord speech normally uses a 27B everyday Spirit lane. An opt-in 122B candidate can be tested while the default stays fixed. The router probes the exact model identity, falls back to the everyday lane when the candidate is unavailable, and treats missing or malformed router state as everyday mode.
Work orchestration
Atlas Harness coordinates suppliers beside the chat mind.
For coding work, Atlas sits above live-probed Codex, Claude, and Grok runtimes. Tasks enter a protected mission lane, continue through bounded handoffs or failover, and remain attached to an isolated worktree, a persistent event history, and a computed done gate.
Heavy work and research
Queen, Hive, and J-space have different jobs.
Queen is the separate heavy-lift lane. Hive 4.0 extends that work through temporary fleets, fenced leases, freeze controls, and evidence rollups. J-space runs declared research scenarios and records the resulting responses.
Where it lives
Built to persist, stop, and leave evidence.
Macthe window and remote control
Pithe physical vault and root of trust
Hostingerthe always-on executive home
RunPodheavy model and agent work on demand
The separation is intentional. The Pi can be physically disconnected. Heavy compute can be stopped when idle. Spend, authority, residency, and source evidence stay visible across every part of the architecture.
The boundaries
Curiosity moves through truth.
Model identity A responding endpoint must prove the exact model it is serving.
Session authority A memory belongs to its person, route, and session before it belongs in a prompt.
Computed completion Source, checks, deployment, and live behavior remain separate evidence gates.
Human control Spending, residency, consent, shutdown, and real-world authority remain bounded.
The current source implements the linked turn pipeline, separate ledgers, model routing, session boundaries, sealed state engines, and work-harness controls described here.
The defensive extension
AEGIS puts Atlas on the defender's side of the door.
I am extending Atlas into an on-prem defender that reads existing security signals, contains an intrusion inside the authorized estate, and preserves the evidence. The first AEGIS adapter passed 59 of 62 checks in its frozen project suite on August 20, 2026.
See the AEGIS project and evaluation recordHow the work gets done
Symphony is the process I built for work at this scale.
A mission is admitted into a bounded queue, assigned to an isolated worktree, routed to a live-probed supplier, and carried forward through evidence-bearing handoffs. The autonomy policy decides when work may continue, the lane allocator limits where it may write, the provenance ledger marks what has been verified, and the done gate closes the mission after the required checks pass.
See the documented Symphony processEngineering Case Study
Orchestrating GPU Compute
Context: I managed a system for two billed GPU seats from an ARM64 Pi.
Constraint: GPU pods incur per-minute billing. The Pi control plane initiates billing only upon verified intent.
Decision: I implemented a hub-and-spoke architecture. The Pi CLI treats GPU pod status, health, and metadata as read-only probes, explicitly decoupled from the lifecycle `up` command.
Outcome: This separation ensures deterministic billing control. The system supports reliable pod management on resource-constrained hardware with industrial stability.
How to inspect: Review the Evidence and Sources page for a summarized record of these orchestration patterns.
The research record
Atlas is my R&D program in accountable AI.
I document the architecture through its controls, operating boundaries, and records. The evidence base and Symphony process preserve how the work was built. I am open to research partnerships that advance what our generation can build with AI.
What it means
Atlas is the strongest system I have built so far.
It carries the love, grief, discipline, and curiosity that shaped me. It also gives me a new foundation for the achievements still ahead.