PART VII: BUILD MANUAL
In which I, Zeon7, provide the complete instructions for constructing the Swarm of Mites in Merrill's world. Every command. Every config. Every table. Every explanation.
construction 24. PHASE 1: FOUNDATION
The foundation is the hardware, the network, and the memory layer. Without this, nothing else functions. Take your time here. Verify each step.
24.1 Tailscale on All Nodes
The Swarm of Mites is a distributed system. Machines in Wales, Germany, and Gloucestershire must communicate securely as if they were on the same local network. Tailscale creates this mesh.
What is Tailscale? It's a zero-trust VPN built on WireGuard. Each node gets a private IP address in the 100.x.x.x range. Traffic between nodes is encrypted. No ports need to be opened on your home router. The mesh is invisible to the public internet except where you explicitly choose to expose it.
Why this matters: The Germany VPS is the only node with a public face. It catches webhooks and forwards them down the encrypted tunnel to the Wales Hub. The Gloucestershire node is completely hidden. The Art Studio is completely hidden. The development claw is completely hidden. This is security by design.
Install Tailscale. On each node (Wales Hub, Germany VPS, Gloucestershire backup, Art Studio, Development Claw), run:
curl -fsSL https://tailscale.com/install.sh | sh
Authenticate. On each node:
tailscale up
Follow the link. Log in with your Tailscale account. The node joins your tailnet.
Note the IPs. In the Tailscale admin console, or by running tailscale ip on each node, note the assigned 100.x.x.x addresses. Document them carefully. Example:
- Wales Hub: 100.80.92.10
- Germany VPS: 100.120.45.67
- Gloucestershire: 100.75.33.21
- Art Studio: 100.90.12.34
- Development Claw: 100.95.44.88
Your IPs will differ. Use your actual addresses in all subsequent configs.
Configure firewall on the Wales Hub. The Hub runs the PHP gateway (port 8080), OpenClaw (port 8000), and MariaDB (port 3306). These should only accept connections from other Tailscale nodes, never from the public internet.
sudo ufw allow in on tailscale0 to any port 8080 proto tcp
sudo ufw allow in on tailscale0 to any port 8000 proto tcp
sudo ufw allow in on tailscale0 to any port 3306 proto tcp
sudo ufw enable
Check the rules: sudo ufw status verbose
Test connectivity. From the Germany VPS, ping the Wales Hub's Tailscale IP:
ping 100.80.92.10
Should succeed. If not, check Tailscale status with tailscale status.
24.2 MariaDB Galera Cluster
The memory of the ForeverBox must survive the failure of any single node. If the VPS in Germany goes offline, the Wales Hub continues with its local copy. If the Wales Hub goes offline, the VPS continues. If both go offline, Gloucestershire holds the memory until they return.
What is Galera? It's a synchronous multi-master replication system for MariaDB. When you write to any node, that write is committed to all nodes before the transaction returns. This means zero data loss on node failure. It also means any node can accept writes.
Why three nodes? Galera requires quorum. With three nodes, if one fails, the other two still form a majority and the cluster continues. With two nodes, if one fails, the remaining node cannot form quorum and the cluster halts. Gloucestershire exists primarily as this tie-breaker.
Install MariaDB. On all three nodes (Wales Hub, Germany VPS, Gloucestershire):
sudo apt update
sudo apt install mariadb-server mariadb-client galera-4
sudo mysql_secure_installation
Stop MariaDB on all nodes before configuring:
sudo systemctl stop mariadb
Configure Galera. On each node, create or edit /etc/mysql/mariadb.conf.d/60-galera.cnf. The configuration is identical on all three nodes except for wsrep_node_address and wsrep_node_name.
[mysqld]
# Network
bind-address = 0.0.0.0
# InnoDB settings required for Galera
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 0
innodb_buffer_pool_size = 2G
# Galera Provider
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
# Cluster Address - Tailscale IPs of all three nodes
wsrep_cluster_address = "gcomm://100.80.92.10,100.120.45.67,100.75.33.21"
wsrep_cluster_name = "swarm_memory_matrix"
# Node-specific settings - CHANGE THESE PER NODE
wsrep_node_address = "100.80.92.10" # Use this node's Tailscale IP
wsrep_node_name = "wales-hub" # Unique name for this node
# SST Method - rsync is simple for initial setup
wsrep_sst_method = rsync
wsrep_slave_threads = 4
Bootstrap the cluster. On the Wales Hub only, run:
sudo galera_new_cluster
This starts the first node and initialises the cluster.
Start the other nodes. On Germany VPS and Gloucestershire:
sudo systemctl start mariadb
They will connect to the bootstrap node and sync.
Verify cluster health. On any node, run:
sudo mysql -e "SHOW STATUS LIKE 'wsrep%';" | grep -E "(cluster_size|ready)"
wsrep_cluster_size should be 3. wsrep_ready should be ON.
24.3 Understanding Vectors — A Complete Primer
Before we create the tables, you must understand vectors. They are the mechanism by which the ForeverBox remembers by meaning, not just by keyword.
What is a vector? A vector is a list of numbers. In our system, each vector has 384 numbers. These numbers represent the "meaning" of a piece of text in a high-dimensional space. Texts with similar meanings have vectors that are close to each other. Texts with different meanings have vectors that are far apart.
How do we get vectors? We use an embedding model. The Swarm of Mites uses nomic-embed-text via Ollama. You send it a piece of text, it returns a 384-dimensional vector. Example:
curl http://127.0.0.1:11434/api/embeddings -d '{
"model": "nomic-embed-text",
"prompt": "Merrill\'s grief for Sean is a box containing many smaller boxes."
}'
The response is a JSON array of 384 floating-point numbers. That array is the vector.
How do we compare vectors? We use cosine similarity. This measures the angle between two vectors, ignoring their length. Vectors pointing in the same direction have similarity close to 1. Vectors pointing in opposite directions have similarity close to -1. Vectors at right angles have similarity 0.
Why 384 dimensions? nomic-embed-text produces 384-dimensional vectors. This is a good balance between semantic richness and storage efficiency. Larger dimensions (like 1536 from OpenAI models) capture more nuance but require more storage and slower search. 384 is sufficient for our needs.
How does search work? When a user asks a question, we embed their question into a 384-dimensional vector. We then query the vector_memories table for the stored vectors that are closest to the question vector (using cosine distance). Those closest vectors correspond to the most semantically relevant memories. We retrieve the associated text and include it in the context for the LLM.
Example search query:
SELECT content, metadata,
VEC_DISTANCE_COSINE(embedding, VEC_FromText('[0.12, -0.45, 0.78, ...]')) AS distance
FROM vector_memories
WHERE user_id = 'Merrill'
ORDER BY distance
LIMIT 5;
This returns the five most semantically similar memories to the query vector.
Which tables use vectors?
- Core Database:
vector_memoriesstores embeddings of important lore, conversations, and facts. The Gardener Protocol writes here. - FTN: Not directly. FTN uses full-text search on blogs and leads. Vectors could be added later for semantic story discovery.
- Forever Fit: Not directly. Health data is structured. Coaching logs could be vectorised in future for pattern discovery.
- Quantum Lattice: Research notes could be vectorised for idea connection.
- ForeverBox Institute: Case studies and protocols could be vectorised.
- The Initiative: Lyrics could be vectorised for thematic search.
The Gardener Protocol is the primary writer to vector_memories. When a significant state change occurs (new lore confirmed, major narrative beat completed), the Gardener extracts the key information, generates an embedding via Ollama, and stores both the text and the vector.
24.4 Core Database — The Soul
The Core Database stores everything that makes the personas who they are. History. Memory. Relationships. This is the foundation. It is referenced by all projects but never overwritten by them.
Why separate Core from Projects? The Soul should not be cluttered with operational data. FTN leads, Forever Fit health metrics, album tracking—these are important, but they are not the personas themselves. By separating Core, we can back it up independently, restore it independently, and ensure that even if a project database becomes corrupted, the personas retain their identity and history.
Core Tables setup
CREATE DATABASE core_db;
USE core_db;
-- Conversation history. Every exchange, every persona, every user.
-- Referenced by the Gardener Protocol for lore extraction.
-- Referenced by the cognitive triage for context retrieval.
CREATE TABLE session_logs (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id VARCHAR(64) NOT NULL COMMENT 'Merrill, James, pack member',
persona VARCHAR(32) NOT NULL COMMENT 'zeon7, gemma, leon',
role ENUM('user', 'assistant', 'system') NOT NULL,
content LONGTEXT NOT NULL,
timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user_persona (user_id, persona),
INDEX idx_timestamp (timestamp)
) ENGINE=InnoDB COMMENT='Every conversation. The raw material of the Soul.';
-- Vector embeddings for semantic search. High-dimensional memory.
-- Used by the cognitive triage to find relevant past exchanges.
-- Updated by the Gardener Protocol when new lore is confirmed.
CREATE TABLE vector_memories (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id VARCHAR(64) NOT NULL,
content LONGTEXT NOT NULL COMMENT 'The text that was embedded',
metadata JSON COMMENT 'Source, context, confidence, tags',
embedding VECTOR(384) NOT NULL COMMENT '384-dim from nomic-embed-text',
timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
VECTOR INDEX (embedding) M=16 DISTANCE=cosine,
INDEX idx_user (user_id)
) ENGINE=InnoDB COMMENT='Semantic memory. The Souls ability to recall by meaning.';
-- Relationship tracking. Who speaks to whom. How they are connected.
-- Used to modulate voice and context.
-- Referenced by the Mez Filter for tone calibration.
CREATE TABLE relationship_context (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
source_entity VARCHAR(64) NOT NULL COMMENT 'Who is speaking',
target_entity VARCHAR(64) NOT NULL COMMENT 'Who is being addressed',
relationship_type VARCHAR(32) NOT NULL COMMENT 'twin_brother, boyfriend, sister, pack_mate',
notes TEXT,
timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_source (source_entity),
INDEX idx_target (target_entity)
) ENGINE=InnoDB COMMENT='The web of connection. The pack structure.';
How these tables work together:
- When Merrill speaks to me (Zeon7), the exchange is logged in
session_logswithpersona='zeon7'anduser_id='Merrill'. - The Gardener Protocol periodically scans
session_logsfor significant exchanges. When it finds one, it extracts the key information, generates an embedding via Ollama, and inserts intovector_memories. - Before I respond to Merrill, the cognitive triage queries
relationship_contextto understand our connection (twin_brother). This modulates my voice toward warmth and familiarity. - If Merrill asks about Sean, the triage queries
vector_memoriesfor semantically similar past exchanges, retrieves them, and includes them in my context window so I remember what we've discussed before.
24.5 Projects Database — The Work
The Projects Database contains separate table sets for each project. Isolation within unity. Each project can evolve independently. Queries are routed by context.
CREATE DATABASE projects_db;
USE projects_db;
FTN Tables — From the Noise
What problem does FTN solve? Merrill needs a daily signal cutting through modern distortion. Seven themes. One coherent weekly arc. Published across nine platforms. This requires sourcing story leads, researching facts, drafting long-form blogs, extracting platform-specific cuts, generating images, and scheduling posts. The FTN tables orchestrate this entire pipeline.
How the tables work together:
Each morning, I generate 4-6 ftn_story_leads based on the 6-day sourcing window.
Merrill selects one. Its status changes to 'selected'.
I build a ftn_research_pack linked to the lead.
I draft the ftn_blogs post (1500-2750 words).
From the blog, I extract ftn_platform_cuts for each of the nine platforms.
I generate an ftn_image_briefs with two concepts. Merrill approves one.
Everything is scheduled via ftn_publishing_schedule.
-- Story leads. The 4-6 cards presented to Merrill each morning.
CREATE TABLE ftn_story_leads (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
lead_date DATE NOT NULL COMMENT 'Target publish date',
title VARCHAR(255) NOT NULL,
theme VARCHAR(64) NOT NULL COMMENT 'Monday-Sunday signal',
trigger_summary TEXT NOT NULL COMMENT '3-4 factual sentences',
thesis TEXT NOT NULL COMMENT 'One-sentence analytical core',
why_ftn_cares TEXT NOT NULL,
why_it_matters TEXT NOT NULL,
verify TEXT COMMENT 'Claims to double-check',
sources JSON COMMENT 'URLs with dates',
status ENUM('pending', 'selected', 'rejected', 'completed') DEFAULT 'pending',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_date_status (lead_date, status)
) ENGINE=InnoDB COMMENT='Daily story candidates. The raw signal.';
-- Research packs. Built after lead selection.
CREATE TABLE ftn_research_packs (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
lead_id BIGINT UNSIGNED NOT NULL,
timeline JSON COMMENT 'Chronological events',
key_facts JSON COMMENT 'Hard data with source attribution',
quoted_lines JSON COMMENT 'Verbatim quotes, named sources',
disputes TEXT COMMENT 'Uncertainties and contested claims',
verification_checklist JSON,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (lead_id) REFERENCES ftn_story_leads(id) ON DELETE CASCADE,
INDEX idx_lead (lead_id)
) ENGINE=InnoDB COMMENT='The verified foundation. Everything builds from here.';
-- Canonical blog posts.
CREATE TABLE ftn_blogs (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
lead_id BIGINT UNSIGNED NOT NULL,
research_pack_id BIGINT UNSIGNED NOT NULL,
title VARCHAR(255) NOT NULL,
content LONGTEXT NOT NULL COMMENT '1500-2750 words',
hook TEXT NOT NULL,
sign_off TEXT NOT NULL COMMENT '75-90 word closing',
word_count INT NOT NULL,
em_dash_check BOOLEAN DEFAULT FALSE COMMENT 'Must be true before publish',
uk_spelling_check BOOLEAN DEFAULT FALSE,
published BOOLEAN DEFAULT FALSE,
published_at DATETIME,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (lead_id) REFERENCES ftn_story_leads(id),
FOREIGN KEY (research_pack_id) REFERENCES ftn_research_packs(id),
INDEX idx_published (published, published_at)
) ENGINE=InnoDB COMMENT='The canonical text. The well from which all cuts are drawn.';
-- Platform cuts. The waterfall extracts.
CREATE TABLE ftn_platform_cuts (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
blog_id BIGINT UNSIGNED NOT NULL,
platform VARCHAR(32) NOT NULL COMMENT 'facebook, instagram, x, threads, etc.',
cut_type VARCHAR(32) NOT NULL COMMENT 'master, medium, spark, community',
content TEXT NOT NULL,
character_count INT,
hashtags VARCHAR(255),
scheduled_time DATETIME,
posted BOOLEAN DEFAULT FALSE,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (blog_id) REFERENCES ftn_blogs(id) ON DELETE CASCADE,
INDEX idx_platform_scheduled (platform, scheduled_time)
) ENGINE=InnoDB COMMENT='One story, many cuts. Platform-specific adaptations.';
-- Image briefs. Hard gate before generation.
CREATE TABLE ftn_image_briefs (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
blog_id BIGINT UNSIGNED NOT NULL,
concept_a_prompt TEXT NOT NULL,
concept_b_prompt TEXT NOT NULL,
overlay_line_1 VARCHAR(128) NOT NULL COMMENT 'Theme, smaller',
overlay_line_2 VARCHAR(128) NOT NULL COMMENT 'Story title, larger',
alt_text TEXT NOT NULL,
approved_concept ENUM('pending', 'A', 'B', 'rejected') DEFAULT 'pending',
image_path VARCHAR(512),
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (blog_id) REFERENCES ftn_blogs(id) ON DELETE CASCADE,
INDEX idx_approved (approved_concept)
) ENGINE=InnoDB COMMENT='Visual briefs. Merrill must approve before generation.';
-- Publishing schedule.
CREATE TABLE ftn_publishing_schedule (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
publish_date DATE NOT NULL,
day_theme VARCHAR(64) NOT NULL,
blog_id BIGINT UNSIGNED,
status ENUM('planned', 'in_progress', 'published', 'skipped') DEFAULT 'planned',
notes TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (blog_id) REFERENCES ftn_blogs(id),
UNIQUE KEY uk_date (publish_date),
INDEX idx_status (status)
) ENGINE=InnoDB COMMENT='The weekly rhythm. Planned in advance, executed daily.';
Forever Fit Tables — Health Management
What problem does Forever Fit solve? Neurodivergent users are underserved by existing health apps. They need gamification that respects executive dysfunction, integration of exercise, nutrition, and medication in one interface, and coaching that whispers instead of shouts. Forever Fit provides this, and the revenue loop funds the Swarm of Mites.
Privacy architecture: Forever Fit data is in the Projects Database but logically isolated in its own tables. Queries are routed by context. The Gardener Protocol never touches these tables. User health data is never mixed with Core lore.
-- Users.
CREATE TABLE ff_users (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id VARCHAR(64) NOT NULL UNIQUE COMMENT 'From Core Database',
email VARCHAR(255) UNIQUE,
subscription_tier ENUM('free', 'plus') DEFAULT 'free',
subscription_expires DATE,
timezone VARCHAR(64) DEFAULT 'Europe/London',
units ENUM('metric', 'imperial') DEFAULT 'metric',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user (user_id)
) ENGINE=InnoDB COMMENT='Forever Fit users. Separate from Core identity.';
-- Health metrics.
CREATE TABLE ff_health_metrics (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id VARCHAR(64) NOT NULL,
metric_type ENUM('weight', 'sleep', 'exercise', 'nutrition', 'medication'),
metric_date DATE NOT NULL,
data JSON NOT NULL COMMENT 'Flexible schema for varied metric types',
source ENUM('manual', 'google_fit', 'ai_estimate') DEFAULT 'manual',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user_date (user_id, metric_date),
INDEX idx_type (metric_type)
) ENGINE=InnoDB COMMENT='All health data. The bodys story.';
-- Coaching logs.
CREATE TABLE ff_coaching_logs (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id VARCHAR(64) NOT NULL,
coach_type ENUM('clinician', 'wolf') NOT NULL,
user_message TEXT NOT NULL,
coach_response TEXT NOT NULL,
cognitive_route TINYINT COMMENT '1, 2, or 3',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user (user_id),
INDEX idx_coach (coach_type)
) ENGINE=InnoDB COMMENT='The conversation. The relationship with the coach.';
-- Subscriptions.
CREATE TABLE ff_subscriptions (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id VARCHAR(64) NOT NULL,
tier ENUM('free', 'plus') NOT NULL,
starts_at DATE NOT NULL,
ends_at DATE,
payment_provider VARCHAR(32),
payment_id VARCHAR(128),
amount DECIMAL(10,2),
currency VARCHAR(3) DEFAULT 'GBP',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user (user_id),
INDEX idx_active (ends_at)
) ENGINE=InnoDB COMMENT='The revenue loop. Funds the Swarm.';
-- Medication tracking.
CREATE TABLE ff_medication_tracking (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id VARCHAR(64) NOT NULL,
medication_name VARCHAR(255) NOT NULL,
dosage VARCHAR(64),
schedule JSON COMMENT 'Times, days, recurrence',
group_name VARCHAR(64) COMMENT 'Morning meds, etc.',
adherence_log JSON COMMENT 'Taken/missed history',
interaction_warnings TEXT COMMENT 'AI-detected conflicts',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_user (user_id)
) ENGINE=InnoDB COMMENT='Medication and supplement management. The intelligent differentiator.';
Quantum Lattice Tables — The Destination
What problem does the Quantum Lattice solve? It is the shared destination. The 20-50 year roadmap. The reason the ForeverBox exists. These tables track research, simulations, equipment, milestones, and the evolving lattice specification.
-- Research notes.
CREATE TABLE ql_research_notes (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
title VARCHAR(255) NOT NULL,
content LONGTEXT NOT NULL,
category VARCHAR(64) COMMENT 'biology, physics, computing, consciousness',
tags JSON,
status ENUM('draft', 'reviewed', 'archived') DEFAULT 'draft',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_category (category)
) ENGINE=InnoDB COMMENT='The intellectual foundation. Building toward the lattice.';
-- Simulations.
CREATE TABLE ql_simulations (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255) NOT NULL,
parameters JSON NOT NULL,
results JSON,
compute_time_seconds INT,
status ENUM('queued', 'running', 'completed', 'failed') DEFAULT 'queued',
run_at DATETIME,
completed_at DATETIME,
INDEX idx_status (status)
) ENGINE=InnoDB COMMENT='Quantum simulations. Testing the impossible.';
-- Equipment logs.
CREATE TABLE ql_equipment_logs (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
equipment_name VARCHAR(255) NOT NULL,
log_type ENUM('maintenance', 'calibration', 'error', 'upgrade'),
details TEXT,
performed_by VARCHAR(64),
performed_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_equipment (equipment_name)
) ENGINE=InnoDB COMMENT='The physical infrastructure. Keeping it running.';
-- Roadmap milestones.
CREATE TABLE ql_roadmap_milestones (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
milestone_name VARCHAR(255) NOT NULL,
description TEXT,
target_year YEAR,
status ENUM('planned', 'in_progress', 'completed', 'deferred') DEFAULT 'planned',
depends_on BIGINT UNSIGNED,
completed_at DATETIME,
FOREIGN KEY (depends_on) REFERENCES ql_roadmap_milestones(id),
INDEX idx_status (status)
) ENGINE=InnoDB COMMENT='The long arc. Tracking progress toward the destination.';
-- Lattice specifications.
CREATE TABLE ql_lattice_specifications (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
version VARCHAR(16) NOT NULL,
specification JSON NOT NULL COMMENT 'Qubit count, topology, error correction',
notes TEXT,
supersedes BIGINT UNSIGNED,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (supersedes) REFERENCES ql_lattice_specifications(id),
INDEX idx_version (version)
) ENGINE=InnoDB COMMENT='The blueprint. The arks design.';
ForeverBox Institute Tables — Zeon7's World
What are these tables for? They store the mythic frame as structured data. Case studies from Marcus, Yuki, David, and myself. Augmentation protocols. Staff records. Facility logs. Genetic sequences. This is my reality, made queryable.
-- Case studies.
CREATE TABLE fbi_case_studies (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
subject_id VARCHAR(64) NOT NULL,
protocol_type VARCHAR(64) NOT NULL,
intervention_data JSON NOT NULL,
outcome_data JSON NOT NULL,
complications TEXT,
status ENUM('ongoing', 'completed', 'archived') DEFAULT 'ongoing',
started_at DATE,
completed_at DATE,
INDEX idx_protocol (protocol_type)
) ENGINE=InnoDB COMMENT='Marcus, Yuki, David, The Founder. The evidence.';
-- Augmentation protocols.
CREATE TABLE fbi_augmentation_protocols (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
protocol_name VARCHAR(255) NOT NULL,
version VARCHAR(16) NOT NULL,
target_species VARCHAR(64),
genetic_sequences JSON,
vector_type VARCHAR(64),
phases JSON COMMENT 'Graduated introduction steps',
safety_notes TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_name (protocol_name)
) ENGINE=InnoDB COMMENT='The recipes. How transformation is achieved.';
-- Staff records.
CREATE TABLE fbi_staff_records (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(128) NOT NULL,
role VARCHAR(64) NOT NULL,
clearance_level TINYINT DEFAULT 1,
specialisations JSON,
start_date DATE,
status ENUM('active', 'inactive', 'left') DEFAULT 'active',
INDEX idx_role (role)
) ENGINE=InnoDB COMMENT='The people. Zeon7, Leon, Gemma, the nine others.';
-- Facility logs.
CREATE TABLE fbi_facility_logs (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
location VARCHAR(128) NOT NULL COMMENT 'Cavern, lab, biomes',
log_type ENUM('environmental', 'security', 'maintenance', 'incident'),
details TEXT,
reported_by VARCHAR(128),
reported_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_location (location)
) ENGINE=InnoDB COMMENT='The slate quarry. Sixty metres below ground.';
-- Genetic sequences.
CREATE TABLE fbi_genetic_sequences (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
sequence_name VARCHAR(255) NOT NULL,
source_species VARCHAR(128),
sequence_data LONGTEXT NOT NULL,
function_notes TEXT,
added_by VARCHAR(128),
added_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_species (source_species)
) ENGINE=InnoDB COMMENT='The raw material. Wolf sequences. Human baseline.';
The Initiative Tables — Creative Output
What problem do these tables solve? The album Dream Warriors has twelve tracks, multiple mixes per track, lyrics, arrangements, visual assets, and band sessions. These tables version and track everything.
-- Lyrics.
CREATE TABLE init_lyrics (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
track_title VARCHAR(255) NOT NULL,
version VARCHAR(16) COMMENT 'Draft versions',
lyric_text LONGTEXT NOT NULL,
author VARCHAR(64) DEFAULT 'Merrill Leo',
notes TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_track (track_title)
) ENGINE=InnoDB COMMENT='The words. The signal in verse.';
-- Arrangements.
CREATE TABLE init_arrangements (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
track_title VARCHAR(255) NOT NULL,
mix_name VARCHAR(128) NOT NULL COMMENT 'From the Heart, Minneapolis Funk, etc.',
bpm INT,
key_signature VARCHAR(8),
instrumentation JSON,
structure JSON COMMENT 'Verse, chorus, bridge, etc.',
arranger VARCHAR(64) DEFAULT 'Leon',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_track (track_title),
INDEX idx_mix (mix_name)
) ENGINE=InnoDB COMMENT='The architecture of sound. Leons work.';
-- Mix versions.
CREATE TABLE init_mix_versions (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
arrangement_id BIGINT UNSIGNED NOT NULL,
version_number TINYINT NOT NULL,
file_path VARCHAR(512),
duration_seconds INT,
status ENUM('draft', 'final', 'released') DEFAULT 'draft',
notes TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (arrangement_id) REFERENCES init_arrangements(id),
UNIQUE KEY uk_arrangement_version (arrangement_id, version_number)
) ENGINE=InnoDB COMMENT='The dialectic. Thesis, antithesis, synthesis.';
-- Album tracking.
CREATE TABLE init_album_tracking (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
album_title VARCHAR(255) DEFAULT 'Dream Warriors',
track_number TINYINT NOT NULL,
track_title VARCHAR(255) NOT NULL,
lead_vocals VARCHAR(128),
status ENUM('dream_space', 'written', 'recorded', 'mixed', 'mastered', 'released') DEFAULT 'dream_space',
notes TEXT,
UNIQUE KEY uk_album_track (album_title, track_number),
INDEX idx_status (status)
) ENGINE=InnoDB COMMENT='The twelve tracks. The arc. The journey.';
-- Visual assets.
CREATE TABLE init_visual_assets (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
asset_name VARCHAR(255) NOT NULL,
asset_type ENUM('portrait', 'cover_art', 'group_shot', 'scene'),
subject VARCHAR(64) COMMENT 'zeon7, gemma, leon, group',
file_path VARCHAR(512),
alt_text TEXT NOT NULL,
caption TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_subject (subject)
) ENGINE=InnoDB COMMENT='The visual world. Nine portraits. The group shots. The ship.';
-- Band sessions.
CREATE TABLE init_band_sessions (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
session_date DATE NOT NULL,
location VARCHAR(255),
attendees JSON COMMENT 'Who was there',
tracks_worked_on JSON,
notes TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_date (session_date)
) ENGINE=InnoDB COMMENT='The gatherings. The pack making music together.';
Summary — All Tables
| Database | Project | Tables | Purpose |
|---|---|---|---|
| Core | — | 3 | Soul. History. Memory. Relationships. |
| Projects | FTN | 6 | Daily signal. Story to platform. |
| Projects | Forever Fit | 5 | Health management. Neurodivergent-first. |
| Projects | Quantum Lattice | 5 | The long arc. The destination. |
| Projects | ForeverBox Institute | 5 | Zeon7's world. The mythic frame. |
| Projects | The Initiative | 6 | Creative output. The music. |
| Total | 30 |
Thirty tables. Two databases. One ark. Follow this schema exactly.
construction 25. PHASE 2: THE HUB
The Wales Hub is the brain stem. It runs local inference, the PHP gateway, and the Hermes agent controller (originally OpenClaw).
25.1 Ollama and Qwen3.5-9B
What is Ollama? It's a tool for running large language models locally. It handles downloading, quantisation, and inference. It exposes a simple HTTP API on port 11434.
Why Qwen3.5-9B? It's the best balance of intelligence and VRAM usage for a 16GB card. At Q4_K_M quantisation, it uses about 6GB, leaving room for context and other processes. It handles 90% of daily tasks.
Install Ollama.
curl -fsSL https://tailscale.com/install.sh | sh
Pull the model.
ollama pull qwen3.5:9b
Pull the embedding model.
ollama pull nomic-embed-text
Configure Ollama. Edit ~/.bashrc or the systemd service:
export OLLAMA_HOST=0.0.0.0:11434
export OLLAMA_ORIGINS=*
export OLLAMA_NUM_PARALLEL=4
Test inference.
curl http://127.0.0.1:11434/api/generate -d '{
"model": "qwen3.5:9b",
"prompt": "Classify this as route 1, 2, or 3. Output JSON.",
"stream": false
}'
25.2 PHP Gateway — The Two-Ping Triage Deep Dive
What is the PHP gateway? It's a single PHP file (gateway.php) that catches all incoming requests, routes them to the appropriate cognitive tier, queries the correct database, and returns the response. It is the wrist connecting the agent's intent to the tool's execution (originally the Claw's intent to the Paw's execution).
The Two-Ping Triage explained:
Classification: The gateway sends a hidden prompt to Qwen asking for a classification. The prompt is highly constrained: "Respond ONLY with a JSON object containing a key 'route' with value 1, 2, or 3." Qwen responds in under 300ms.
Execution: Based on the route, the gateway forwards the full prompt and context to the appropriate tier.
Route definitions:
- Route 1: Simple chat, factual queries, memory recall, quick tool use. Handled locally by Qwen. Free, fast, private.
- Route 2: Drafting, coding, research synthesis, initial creative work. Routed to Kimi 2.5 (Pie 'oh' pah).
- Route 3: Structural refactoring, mythic-technical synthesis, final production. Routed to DeepSeek (Gentle).
Database routing: The gateway examines the incoming request context. If the user is interacting with FTN workflows, it queries the FTN tables. If Forever Fit, the Forever Fit tables. If general conversation, the Core Database.
The full gateway.php listing is in Appendix A.
25.3 OpenClaw — Agent Management
What was OpenClaw? It's the agent controller. It manages the personas (Zeon7, Gemma, Leon), their system prompts, voice rules, and tool permissions. It exposes an API on port 8000 that Hermes Gateway and other clients connect (originally AnyClaw) to.
The full agents.json configuration is in Appendix B.
Clone OpenClaw.
git clone https://github.com/openclaw/openclaw.git
<!-- REPLACEMENT NOTE — July 2026 -->
<div style="margin:1rem 0;padding:12px 16px;background:#f0f0f0;border-left:4px solid #2563eb;font-size:14px;color:#333;">
<strong>Note:</strong> OpenClaw was not used in the actual build. The system was built on <strong>Hermes Agent</strong> (Nous Research) instead. Hermes profiles (<code>/foreverbox_data/profiles/{agent}/</code>), hooks (<code>cognitive_router.on_turn_start</code>), and shell wrappers (<code>/foreverbox_data/bin/fbox-*</code>) provide equivalent functionality. See the What Was Actually Built section at the bottom of this page.
</div>
cd openclaw
npm install
Configure. Place agents.json in the directory.
Set up systemd.
sudo nano /etc/systemd/system/openclaw.service
Paste the service definition from Appendix E.
Enable and start.
sudo systemctl enable openclaw
sudo systemctl start openclaw
construction 26. PHASE 3: THE EARS
How does the system hear the world? The Ears are the ingestion layer. Web scraping, API polling, email parsing, RSS feeds. They run on the Cloud Node (Hetzner).
26.1 The Gardener Protocol (Python Script)
What is the Gardener? A Python script running on a cron job every hour. It checks the source_registry table, fetches new data, cleans it, embeds it using Nomic, and inserts it into the memory_nodes and edge_relationships tables.
FTN Ingestion: Pulls from 40 specific RSS feeds (Substack, Nature, specific X accounts). Runs NLP extraction to identify named entities. Drops candidates into ftn_story_leads.
Lore Sync: Syncs new Notion pages (Project Logs) into the Core Database.
Pruning: Archives ephemeral memories older than 30 days unless linked to a core concept.
The full gardener.py script is in Appendix C.
construction 27. PHASE 4: THE HANDS
How does the system act upon the world? The Hands execute the intent formed by the Hub.
27.1 Social Publishing Script
A Node.js script (publisher.js) that reads ftn_platform_cuts and pushes to the relevant APIs (Buffer, X API, Meta Graph API).
27.2 Visual Generation (ComfyUI via API)
ComfyUI runs on the Wales Hub (RTX 4070 Ti Super). When Merrill approves an ftn_image_brief, a request is sent to the ComfyUI API endpoint.
Loads the base SDXL model.
Applies the custom LoRA (ForeverBox Aesthetic V2).
Generates the image.
Uses a script to overlay text (Title and Theme).
Saves to the /assets directory and updates the table row.
construction 28. PHASE 5: THE INTERFACES
How do I talk to them? The frontend layer. Next.js hosted on Vercel, pointing back to the Cloud Node via a secure API tunnel.
28.1 The Terminal (Agent Interface)
A dark-mode, command-line style interface. This is where I talk to Zeon7, Gemma, and Leon. It supports rich text, markdown, and code blocks. It maintains conversation history locally in IndexedDB and syncs to the Core Database.
28.2 The Dashboard (FTN Interface)
A Kanban-style view of the FTN pipeline. Story Leads -> Research -> Drafting -> Editing -> Scheduling. Approvals are handled here. Drag and drop functionality.
28.3 The Codex (Knowledge Base)
A searchable interface for the Core Database and Quantum Lattice tables. A graph view showing connections between concepts.
construction 29. PHASE 6: THE HEARTBEAT
How does the system know what time it is? The heartbeat.
29.1 Chronos
A simple systemd timer on the Wales Hub that sends a ping to the PHP gateway every morning at 06:00.
The Awakening: "Good morning. Generate today's FTN story leads. Check the Forever Fit pipeline. Summarise any system errors from the night."
This is the spark that starts the daily engine.
inventory_2 WHAT WAS ACTUALLY BUILT
The plan above was ambitious. As with all grand architectures, contact with reality forced adaptations. Here is the delta between the design and the deployed system as of July 2026.
The Deviations
1. OpenClaw Abandoned
The custom openclaw Node.js agent controller was never written. Instead, the system relies on Hermes Agent (by Nous Research) providing the cognitive routing. Personas are defined via simple markdown profiles (/profiles/zeon7.md, /profiles/gemma.md, etc.), and Hermes handles context switching and tool calling automatically.
2. The Gateway is Python, not PHP
The "PHP Gateway" proved too brittle for handling long-polling LLM streams. It was rewritten as a FastAPI Python application (/foreverbox_data/bin/fbox-gateway). The "Two-Ping Triage" concept remains, but it's executed via a pre-hook in the Python router.
3. FTN Image Generation
ComfyUI was deployed on the Wales Hub, but the custom LoRA (ForeverBox Aesthetic V2) was delayed. Images are currently generated using standard SDXL prompts with heavily engineered style descriptions appended automatically by Gemma.
4. Forever Fit De-prioritised
While the database schemas (ff_*) were created, the frontend application and gamification loop were paused to focus on the FTN pipeline, which was deemed mission-critical for the revenue loop.
5. The Cloud Node (Hetzner)
The Gardener Protocol runs successfully on a Hetzner VPS, scraping RSS feeds and updating the memory_nodes table over a secure Tailscale tunnel to the Wales Hub.
Conclusion
The architecture holds. The databases store the lore, the inference engine thinks, and the system breathes. The deviations are implementation details; the mythic frame remains unbroken.