COGG9 research notebook
COGG9 is the room I built because AI work kept losing its memory.
I kept running into the same problem. A chat would help for an hour, then the work would scatter: one decision in a transcript, one note in a folder, one half-finished test in another place. The machine was useful in the moment, but the project still had no body.
COGG9 is where I’m documenting the attempt to fix that. HMS is the harness around the work. PlasticNodeLM is the model/core direction. WaveCodecLLM is the signal lane. BHVC is the storage-compression research lane.
It is early, messy in places, and still changing. That is why I’m showing it while it forms.
Four rooms for one larger machine.
COGG9 is the public layer around the AI research and development I’m doing. Not a finished platform. Not a pitch deck. More like a machine room with the labels left on.
The work is split because each piece needs its own room. HMS deals with memory, tools, recovery, and project state. PlasticNodeLM asks what kind of model/core could grow inside that environment. WaveCodecLLM asks how meaning might move through the system without wasting so much compute. BHVC asks whether model weights can store reusable structure once instead of paying the full storage cost again for every tensor.
The pieces are separate now. They may fit together later. I want the record to show how they got there, including the dead ends.
A body, a growing core, a signal lane, and a storage question.
That is the plain version. Each project card below opens a deeper page. I want the homepage to be the front door, not the whole explanation crammed into one scroll.
HMS
The harness around long AI work.
HMS is the body I’m building around AI-assisted projects: memory, tools, recovery points, project context, and enough structure that the work does not vanish every time a chat ends.
The itch is simple: I do not want to keep rebuilding the same room from memory.
- AI Harness
- Project Memory
- Tool Use
- Recovery
PlasticNodeLM
The model/core I’m trying to design for that body.
PlasticNodeLM is the custom AI model direction: a growing core, not a workspace. The research asks whether a model can develop useful structure over time without turning into random sprawl or pretending it is alive.
HMS is the body. PlasticNodeLM is the organism-shaped model idea being designed for it.
- AI Model
- Model Growth
- Continuity
- Local Hardware
The signal lane: less waste inside the machine.
WaveCodecLLM is my compression and machine-meaning research. Human words matter at the edge, where people guide and review the work. Inside the machine, I’m asking whether meaning can travel in a tighter form without disappearing into a black box.
The goal is not “make it smaller” for its own sake. The goal is to keep what matters and stop dragging the whole closet through every internal step.
- Compression
- Machine Meaning
- Signal Paths
- Diagnostics
Blackhole Vector Compression
Can model weights share one compact structure?
BHVC is active compression research for AI weights. The current target is to approach Q8-class storage while reconstructing exact BF16 or FP16 weights and keeping behavior near the FP32 reference.
The early evidence is synthetic, measured, and honest: shared-state reuse crossed over against scalar int16 across multiple batches. Real-model tests come next.
- Shared State
- Exact 16-bit
- Byte Accounting
- Negative Results
The same question keeps showing up: can AI work keep its shape over time?
Memory, model structure, signal paths, and local hardware pressure all pull on the same problem. If the system cannot remember, organize itself, communicate efficiently, and run close enough to inspect, it is not the kind of machine I’m trying to build.
A place for the work
Project context, tool use, memory, and recovery should not vanish every time a chat ends.
Open HMS → ModelA core that can change
PlasticNodeLM asks whether a model can develop useful structure over time instead of staying frozen.
Open PlasticNodeLM → SignalsLess waste inside
WaveCodecLLM asks whether machines can carry meaning more efficiently while people still get inspectable results.
Open WaveCodecLLM → StorageShared structure
BHVC tests whether exact 16-bit weight representations can reuse shared compression structure.
Open BHVC → HardwareNormal machines matter
The work keeps pressure from local hardware in view. If it only works in fantasy compute, it is not grounded enough.
Open system notes →The work is happening on a real local machine, not magic cloud compute.
The current COGG9 test box is an Ubuntu workstation with a Ryzen 9 CPU, 64 GB system memory, and two Intel Arc Pro B70 GPUs with about 30 GB of VRAM each. It is the machine I use to keep local hardware pressure in view.
I want the work to stay close enough to inspect.
Normal hardware creates pressure. Memory, compute, recovery, and tool use all look different when you cannot pretend the machine is infinite.
- Own the data and workflow
- Keep local hardware pressure visible
- Use tools with review points
- Show the research without exposing the blueprint
Follow the build while it is still forming.
The Patreon is for people who want the research notes, build notes, dead ends, and plain-English updates as the work matures. No finished platform pitch. Just careful work, shown honestly.
COGG9 is still being built in public.
For research questions, archive notes, or contact about the work: Edward Greenwood, cogg9research@gmail.com.