The through-line is stateful software interacting with messy worlds.

01 – Real-Time 3D

The Babylon.js work included a substantial horror FPS experiment with:

• UniversalCamera;
• collisions;
• flashlight;
• ghost AI;
• ghost states such as PATROL, CHASE, IDLE and ATTACK;
• multiple ghost types;
• detection and catch radii;
• mansion-grid systems;
• prefabs;
• capped flicker-light pools;
• PBR floors and roofs;
• BFS patrol;
• HUD and inventory;
• ritual mechanics.

This belongs in the Lab because autonomous behaviour, state machines and real-time perception/action loops are not restricted to LLM systems.

02 – Generative Media Pipelines

ComfyUI became an orchestration platform, not just an image-generation interface.

The work covered image generation, video generation, video editing, video stitching, 3D workflows, audio, image analysis, editing, character workflows, LLM orchestration and experimental workflow packs.

Game Character Hub was considered as a target for AI augmentation: ComfyUI could populate assets, an LLM could direct or configure content, and the legacy software could manage sprites and animation.

03 – Embedded Systems

TinyMind Robot aimed at the smallest and cheapest fully local AI-like system possible inside a 3D-printed robot.

The design converged around Seeed XIAO ESP32-S3 Sense, N20 motors, DRV8833 driver, battery, speaker, LEDs and small sensors, with a removable brain-cartridge idea for future upgrades.

The archive is clear about the constraint: an ESP32-class board is not a realistic host for a normal 0.5B-parameter local LLM. The project belongs more to embedded intelligence and behavioural architecture than ordinary LLM deployment.

04 – Web And Business Tooling

WordPress and 3D Printing Ballarat systems also belong in the wider archive:

• instant STL quote/upload;
• photo-to-3D model;
• custom jobs;
• searchable parts library;
• AJAX shortcodes;
• weighted search;
• STL/OBJ preview worker;
• custom post types and taxonomies;
• payment portals and file-upload workflows.

This is the practical software substrate underneath the AI research.

05 – Current Belief

The Lab should not be narrowed until only Omega remains.

Omega is the centre of gravity, but the surrounding work explains the instincts behind it: local-first systems, long-running state, tool use, autonomy, hardware constraints, embodied sensors, real-time interaction and an unwillingness to treat failures as embarrassing.

Source note: assembled from v2 sections on Babylon.js, ComfyUI/generative media, Game Character Hub, TinyMind Robot, Espruino, WordPress tooling and 3D Printing Ballarat systems.

Sometimes the right platform is a strange pile of old cards, cheap boards, risers, unified memory and careful workload assignment.

01 – The Hardware Pattern

The archive records experiments or plans around:

• Tesla P40;
• Tesla P4;
• planned P100s;
• Radeon RX 580;
• Radeon RX 7970 6GB;
• RX 5700 XT;
• RTX 4060;
• RTX 4070;
• Hilbert unified memory;
• ASRock mining boards;
• Supermicro dual-Opteron server hardware.

The recurring question is not "what is the fastest single GPU?" It is "what useful cognitive or generative role can this hardware perform?"

02 – P40 Logic

The Tesla P40 is interesting because 24GB of VRAM can matter more than modern gaming performance for some local LLM experiments.

The trade-off is explicit:

• older card;
• more memory per dollar;
• lower modern feature support;
• awkward cooling and power;
• useful capacity for certain inference roles.

That is not nostalgia. It is budget-aware systems design.

03 – Dedicated Function Nodes

The mature direction is not necessarily one model spread across every card.

Instead, cards can be assigned to roles:

• one GPU for video generation;
• one for image generation;
• one for an LLM;
• smaller cards for lightweight specialist processors;
• Hilbert for large capacity-bound models;
• CPU services for routing and state.

This maps cleanly onto Omega's specialist cognitive-cluster idea.

04 – PCIe x1 Is Not Automatically Disqualifying

Mining boards and risers are poor for workloads requiring heavy inter-GPU transfer. But for dedicated-function nodes, PCIe x1 can still be acceptable if the model loads and does substantial local work on the card.

That distinction is important. The Lab should not pretend cheap mining-era hardware is secretly ideal. It should document where it is bad, and where it is still useful.

05 – Relic And Scrap LLM

The r/RelicAndScrapLLM idea belongs here because it names the philosophy directly: old hardware can still be part of serious AI experimentation if the workload is chosen honestly.

The point is not to beat flagship GPUs. The point is to expand what can be learned with the machines already within reach.

Source note: assembled from v2 hardware sections and the recovered research philosophy around capacity, throughput and reuse.

The system is based on an AMD Ryzen AI Max+ 395 class machine with 128GB unified memory and ROCm-oriented local inference. That makes it different from a conventional desktop GPU box: it can attempt models and contexts that are awkward or impossible on smaller discrete cards, even when those cards are faster.

01 – The Workstation Stack

The v2 archive recovers a July 2026 layer of the open-source workstation stack:

• local inference and chat;
• coding agents;
• generative media;
• voice.

The point was not to install one impressive demo. It was to assemble a workstation where local models, coding tools, ComfyUI-style media workflows and voice systems could coexist.

02 – Hilbert Unofficial Suite

The Hilbert Unofficial Suite combined several layers:

• Hilbert Studio, a ComfyUI workflow platform;
• Genesis Runtime, an assistant/agent runtime;
• an AI code-build pipeline;
• ai-switch, a switcher intended to keep GPU-heavy stacks from trampling each other.

The suite's workflow layer was manifest-driven: declared inputs and outputs, model requirements, hardware requirements, tags, presets, registry discovery, schema validation, batch processing and quality-control scoring.

At one point the public registry was recorded as 12 categories and 89 workflows. Adult and community-model checkpoint categories were intentionally excluded from the public registry.

03 – ROCm As A Constraint

The ROCm focus is not incidental.

Most generative-AI tooling assumes NVIDIA/CUDA by default. Hilbert made ROCm and unified memory first-class constraints, which is exactly the kind of constraint the Lab should document: the engineering work required to make AI practical on the hardware actually available.

04 – Failures Count

The Hilbert archive includes operational failures:

• ROCm/unified-memory messages involving Qwen3 Coder Next and SVM allocation;
• sleep/resume instability after moving to Pop!_OS;
• a disk-capacity incident where Code state and the AI suite consumed enormous storage.

Those are not footnotes. They are part of the research output.

05 – Relationship To The GPU Farm

Hilbert and the older GPU farm solve different problems:

• Hilbert provides capacity through unified memory;
• discrete GPUs provide speed and throughput for narrower specialised tasks.

That distinction feeds directly into Omega's cognitive-cluster direction.

Source note: assembled from v2 sections on Hilbert, the recovered July 2026 workstation layer and the Hilbert Unofficial Suite.

That distinction matters because Genesis represents the "agent runtime" phase of the work, while Omega represents the later move toward cognitive architecture.

01 – Identity

Genesis was conceived as a minimal, framework-agnostic, ecosystem-neutral, local-friendly runtime for agentic systems.

The short version was:

everything is a plugin.

Profiles were installable recipes or configurations rather than hardcoded personalities.

02 – Recovered Profiles

The v2 archive recovers profile details that should be preserved:

• Minimal;
• Contemplative;
• Developer;
• Startup;
• Ghostwriter;
• Household Ghost;
• Watchtower;
• Air Gap;
• Researcher;
• Dungeon Master;
• Personal Assistant;
• 3D Printing Ballarat.

These profiles show the ambition: a substrate that could become many kinds of local assistant or agent without locking the architecture to one product shape.

03 – Interoperability

Genesis was meant to coexist with the tools and frameworks already around the ecosystem:

• OpenHands;
• LangGraph;
• AutoGen;
• CrewAI;
• ComfyUI;
• Ollama;
• llama.cpp;
• Home Assistant;
• MCP;
• OpenAI-compatible APIs;
• Anthropic-style APIs.

The practical instinct was integration before reinvention.

04 – Local AI Home Assistant

A related Local AI Home Assistant project belongs beside Genesis. It included or planned:

• plugin system;
• voice;
• calendar;
• mail;
• skills marketplace;
• OpenAI-compatible API;
• MCP.

This marks the bridge from "assistant with plugins" to "persistent architecture with memory, attention and goals."

05 – Relationship To Omega

Genesis is a predecessor, not a discarded name for Omega.

The useful public arc is:

• Genesis explored a modular runtime for local agents.
• Its plugin/profile model established the value of extensibility.
• Omega keeps the modular instinct but changes the centre of gravity from task execution to cognition.

That difference should stay visible in cross-links and project descriptions.

Source note: assembled from v2 sections on Genesis, recovered profiles and the broader integration-before-reinvention philosophy.

01 – Purpose

The system is framed around real-time multi-speaker interaction.

The core problem is that ordinary voice assistants flatten conversation into a request/response exchange. A multi-speaker system needs to track who is speaking, who is being addressed, whether speech is partial or complete, and whether the assistant should interrupt, wait, revise or speak.

That makes it closely related to Omega's attention problem.

02 – Architecture

Recovered components include:

• live audio input;
• speech recognition;
• speaker identity states;
• thought assembly;
• revision engine;
• playback as a stateful object;
• local inference/chat layer;
• integration with broader local AI workstation tooling.

The interesting part is not any single component. It is the way they are treated as stateful parts of an ongoing interaction rather than one-shot function calls.

03 – Speaker Identity States

The system distinguishes speaker state instead of treating all audio as anonymous input.

That implies the assistant has to reason about:

• current speaker;
• possible speaker changes;
• overlapping or interrupted turns;
• conversational address;
• whether a response is intended for one person or the room.

This moves the work toward a conversation operating system rather than a voice command layer.

04 – Thought Assembly And Revision

The recovered notes mention thought assembly and a revision engine.

That matters because live conversation is incremental. A system may begin forming a response before the full utterance is settled, then revise as more context arrives.

In a text chat, revision mostly happens before output. In voice, timing itself becomes part of the intelligence.

05 – Playback As State

Playback is treated as a stateful object, not just "say this string."

That allows questions like:

• Is the system already speaking?
• Can this output be interrupted?
• Should speech be revised?
• Should it pause, resume or abandon a response?
• Does a new user turn outrank the current playback?

This is directly adjacent to attention and control policy.

06 – Current Status

The archive records this as a technical blueprint v0.1 with implementation status still to verify. The Lab should publish it as design archaeology unless code or demos are confirmed.

Source note: assembled from v2 section 31, "Real-Time Multi-Speaker Voice Interaction System." Implementation status should be checked before presenting it as built.

The v2 archive recovers a candidate topology rather than a final implementation. It should be published that way.

01 – The Central Question

The key question became:

Which cognitive nodes already exist in the wild, and which actually need to be built?

That question matters because training a custom model for every cognitive role would be wasteful and probably worse than reusing strong existing specialists where they already fit.

02 – Candidate Nodes

Recovered candidate roles include:

• Router-R1: a reasoning/router component that can decide where a cognitive problem should go.
• Memory-R1: a memory-focused processor for recall, consolidation or memory judgement.
• Attention: a salience and working-memory selection processor.
• Epistemic: a processor concerned with confidence, uncertainty and knowledge gaps.
• Motivation: a processor concerned with goal pressure, unresolved tension and action-worthiness.

These names are not final product names. They are candidate functional roles.

03 – Reuse Before Training

DeepSeek R1, or an appropriate distilled R1-family model, was considered as a ready-made reasoning component. That is an important philosophical point.

The aim is not to train custom models for purity. The aim is to build the missing parts of a cognitive architecture. If an existing model already performs a role well, use it.

Custom training or adaptation should be reserved for roles where current assistant/reasoning models are structurally mismatched:

• salience;
• memory consolidation;
• recall association;
• goal selection;
• criticism;
• metacognition;
• conflict resolution;
• intent/action selection;
• affective or value modulation.

04 – Hardware Mapping

The specialist-cluster idea naturally connects to the hardware archive.

A single huge model on one machine is not the only architecture. A cluster can assign roles to available machines and GPUs:

• Hilbert for large unified-memory models;
• older high-VRAM cards for capacity-bound local inference;
• smaller cards for lightweight processors;
• discrete GPUs for image/video tasks;
• CPU or low-power systems for orchestration and state.

This is where cognitive architecture and hardware pragmatism meet.

05 – Current Status

The archive says the infrastructure/research audit should precede model training. That matters. The Lab should not imply that the cognitive cluster has already been trained if the evidence only supports topology and planning.

The current public claim is narrower and stronger: Omega is moving toward a distributed specialist-processor architecture, with existing models reused where possible and custom models reserved for genuinely missing cognitive functions.

Source note: assembled from v2 notes on the recovered candidate topology, DeepSeek R1 reuse and the correction that cluster audit/infrastructure should come before training.

That is a timer. It may be useful for a service loop, but it is not a satisfying model of cognition.

The preferred rule is:

As soon as idle, cognition resumes.

01 – Why The Timer Felt Wrong

A periodic timer creates the appearance of continuity while preserving the deeper assistant shape:

• wait;
• wake;
• call a model;
• produce an output;
• sleep again.

That can be engineered, but it keeps making the system feel like a queue processor wearing a cognitive mask.

Omega's goal is different. Idle time should not be empty. If no external task is active, the architecture should return to unresolved concerns, active goals, memory consolidation, prediction gaps and self-generated questions.

02 – Cognitive Transition

The recovered v2 notes point toward a cognitive-transition or control-policy model.

The question becomes:

• What state is Omega in now?
• What mental objects are currently active?
• What pressures are acting on them?
• What action, if any, should the system take next?
• Should it reason, recall, consolidate, plan, observe, speak, act or stay quiet?

This is not the same as picking the next function in a fixed pipeline. It is closer to a policy over cognitive state.

03 – Why This Matters For Will

The will problem does not vanish just because cognition runs continuously. A system can loop forever and still have no reason to prefer one concern over another.

But the control-policy framing gives the problem a place to live.

Motivation can be modelled as pressure on state transitions: unresolved goals, prediction error, novelty, repeated failure, affective value, curiosity, user commitments and self-maintenance can all affect what becomes worth acting on.

The open question is how much of that policy should be hand-built, learned, model-evaluated or split across specialist processors.

04 – Current Belief

Omega's control layer should be presented as research, not as a solved claim of machine will.

The useful public language is:

• continuous cognition;
• attention and salience;
• cognitive state transitions;
• idle thought;
• long-term concerns;
• goal pressure;
• model processors inside an architecture.

The unsafe language is anything that implies solved sentience, solved agency or a magical emergence of desire from an LLM.

Source note: assembled from the v2 archaeological-pass material on cognitive-transition/control-policy direction and the earlier "as soon as idle" design rule.

The v2 archive records an important correction: an earlier Self Memory formulation should not be silently overwritten by the later procedural-memory framing. The shift is part of the research history.

01 – The Earlier Shape

The earlier memory taxonomy included:

• working memory;
• episodic memory;
• semantic memory;
• self memory.

Self Memory matters because Omega is not only trying to store facts or procedures. It is trying to preserve a continuity of identity: what the system believes about itself, its own prior states, its commitments, its habits and its recent trajectory.

That is not quite the same thing as procedural memory.

02 – The Later Shape

The later public summary uses:

• working memory;
• episodic memory;
• semantic memory;
• procedural memory.

Procedural memory is still valuable. A cognitive system needs routines, learned policies and ways of doing recurring tasks. But replacing Self Memory with Procedural Memory changes the story if it is presented as a clean upgrade.

The more honest version is that the taxonomy is being worked through.

03 – Mental Objects

Omega is better described in terms of mental objects competing for attention than scheduled model calls.

A mental object can be a goal, observation, recalled memory, hypothesis, user message, prediction error, plan, tool result or internally generated thought. The system's job is not merely to decide which timer fires next. It is to decide what deserves to occupy working memory.

This is the difference between:

• "run a thinking model every ten seconds"; and
• "when the system is idle, cognition resumes around whatever is salient."

The second version is closer to the Lab's actual target.

04 – Attention Over Scheduling

Scheduling is still needed at the engineering layer. Machines need loops, queues and execution control. But Omega's public explanation should avoid making the scheduler sound like the mind.

The cognitive model is:

• mental objects enter or leave working memory;
• activation spreads through associations;
• relevance, novelty, goals and confidence affect salience;
• weak candidates decay;
• stronger candidates compete for attention;
• selected objects guide reasoning, speech or action.

That is why "What currently occupies my mind?" is a better description than "What is in the context window?"

05 – Current Belief

The memory taxonomy should remain open in the Lab. Working, episodic, semantic and procedural memory are useful categories, but Self Memory should be preserved as a historical and possibly continuing concern.

If Omega is meant to have continuity, it needs some account of self-state. Whether that becomes its own memory class, a layer across all memory, or a set of high-priority mental objects is still a research question.

Source note: assembled from the v2 archaeological-pass correction on memory taxonomy and the recovered notes on mental objects and attention-over-scheduling.

This entry is a map, not a victory lap.

01 – The Lineage

The pattern begins in ordinary software work: WordPress, PHP, JavaScript, Node, React, C#/.NET, integrations, APIs, automation and UX. That work matters because it created the reflex that later shaped the AI systems: build tools that survive contact with users, file systems, queues, APIs, permissions and ugly operational state.

From there the archive moves through several layers:

• LLM integration inside existing software.
• WordPress and command-line agents with memory, task queues and history.
• Autonomous experiments in persistent worlds such as Screeps.
• AntBrain-style cognition experiments using perception, memory and LLM decision loops.
• Local assistants and plugin runtimes.
• Genesis as a more general agentic substrate.
• Omega as a shift away from assistant orchestration and toward artificial cognitive architecture.

The important point is continuity. Omega did not appear as a clean abstract idea. It emerged after enough agent systems behaved too much like tools waiting for instructions.

02 – What Changed

Earlier systems could be useful without being alive in the architectural sense. They could receive a task, call a model, use tools, write state, and return a result. But their default condition was still sleep.

The Omega question is different:

What would a system be doing when nobody is asking it anything?

That one question changes the architecture. Memory stops being a transcript dump. Attention becomes a real resource. Goals need to persist. Idle time becomes cognitive time. A model becomes a processor inside a larger system rather than the seat of the system itself.

03 – Why The Old Work Belongs Here

Screeps matters because persistent game worlds expose planning, resource constraints and long-running autonomous loops.

AntBrain matters because cognition framing existed before the Omega name.

The WordPress CLI LLM agent matters because it joins ordinary web tooling to memory, history and task queues.

Genesis matters because it tried to make agent systems modular: profiles, plugins, local-friendly execution and interoperability with other frameworks.

The hardware work matters because the later specialist-cluster idea depends on accepting heterogeneous compute as a design material rather than treating it as an inconvenience.

04 – Current Belief

The Lab should not be organised as a portfolio of isolated projects. It should be organised as an intellectual trail: predecessor, failure, correction, successor.

That means some entries are not "successful projects" in the normal sense. They are preserved because they explain why the later architecture exists.

05 – What Still Needs Verification

This entry is reconstructed from the knowledge base rather than independently verified against every repository or live URL. Existing public pages and repos should be checked for:

• AntBrain.
• Screeps agent work.
• Genesis Runtime.
• Local AI Home Assistant.
• WordPress-CLI-Agent-LLM-Model.
• Omega ACA.

The safe public claim is not that each project reached a particular outcome. The safe claim is that each belongs to the chain of experiments that led toward persistent artificial cognition.

Source note: assembled from Derek_Robertson_Lab_Knowledge_Base_v2.md, especially the project-lineage and archaeological-pass sections. Dates and implementation states remain conservative unless separately verified.

Every attempt at it back then met the same fate. All logic had to be hard-coded, by hand, rule by rule — there was no way for the system to generate its own new logic, only to run the logic it had already been given. So nothing ever compounded. No snowball effect. Each experiment was a dead end for the same underlying reason, regardless of how it was designed.

AI-assisted development is what finally removed that ceiling. A solo developer can now cover enough ground, quickly enough, for the old idea to be worth trying again — not because the idea changed, but because the thing that was blocking it did.

Where this shows up

This isn't the origin story of any one project — it's the reason several exist:

• Terminus is the first attempt built after the ceiling lifted: the smallest possible test of a validated self-editing loop, deliberately scoped down to "does the mechanism even work."
• Omega Observer → Omega ACA is the same underlying instinct — systems that change their own structure rather than just executing fixed logic — applied to memory and cognition instead of code.
• Why an LLM Doesn't Have a Will is arguably the same question again, one level up: not "can the code rewrite itself" but "can the system generate its own reasons to act" — a system that isn't just running rules it was given.

A twenty-plus-year-old idea, tried repeatedly and abandoned repeatedly for one consistent, structural reason, isn't the same thing as an idea that was wrong. It just needed a precondition that hadn't arrived yet.