Matrix Lava
Pi-driven cellular-automaton rules and a scrolling field. The original visual bridge from static patterns to continuously evolving structure.
The operating-system experiment
8Z OS.
From the first pixel
to a feedback loop.
A small operating system, written from scratch. A screen filled by mathematical rules. Then a different question: could the system observe what it was generating—and change its own dynamics?
Two experiments. One starting point.Original archive image · I02
512 BBIOS boot sector
32-bitFreestanding C++ + assembly
320 × 200Direct VGA graphics
6 appsIn the later multi-app kernel
Contents / Vsebina
Follow the main story, or open the technical layers.
Po slovensko — od majhnega OS do zamisli, iz katere se je razvil DCC
8Z OS ni bil zamišljen kot zamenjava za Windows. Bil je poskus lastnega, čim bolj preglednega okolja za izvajanje matematičnih programov. Nastal je lasten zagonski nalagalnik, 32-bitno jedro v C++ in neposreden izris v grafični pomnilnik. Python je pomagal pri gradnji na gostiteljskem računalniku; ni tekel znotraj OS.
Najprej je bilo pomembno, da se na zaslonu sploh nekaj pojavi. Rule 90 je iz enega semena ustvaril trikotni vzorec. Nato so števke π preklapljale med pravili celičnega avtomata. Nove vrstice so nastajale na vrhu, stare so drsele navzdol: Matrix oziroma Digital Lava. Majhen opis je ustvarjal bogato sliko. Vendar program rezultata še ni opazoval in se nanj ni odzival.
Naslednji korak je povezal ta laboratorij s CCH, hipotezo o zavesti in vlogi claustruma. E4-Metal je uporabil tri Lorenzove oscilatorje, zgodovino njihovega signala, poenostavljen merilnik kompleksnosti in regulator sklopitve. Novost ni bil metulj na zaslonu, ampak ločitev generatorja, opazovalca in regulatorja ter povratna zveza med njimi.
Rekonstrukcija iz septembra 2026 ohrani tudi pomemben popravek: pri privzetem cilju 15 in začetni sklopitvi 0 je regulator v omejenem preizkusu zahteval zmanjšanje že ničelne sklopitve. Vklopljena in izklopljena različica sta zato ustvarili bajtno enaka zabeležena izhoda. To ni dokaz aktivnega uravnavanja na robu kaosa in še manj dokaz zavesti. Je natančno opisan zgodnji prototip, katerega arhitekturo in omejitve lahko pregledamo.
Iz te smeri je pozneje zrasla splošnejša zamisel DCC: ne nadzoruj samo posameznega koraka, temveč opazuj, v kakšen režim se razvija proces, in spreminjaj njegovo nadaljevanje. Digital Claustrum je njegov konceptualni in arhitekturni prednik, ne ista izvedba in ne dokaz vseh poznejših rezultatov.
Celotna angleška predstavitev spodaj ohranja razvojno zgodbo, izvirne slike in video, tehnične podrobnosti ter ločnico med izvedenim in načrtovanim. Prejšnja predstavitev z njenimi večjezičnimi povzetki je nespremenjena v arhivu index-O.html; njene močnejše zgodovinske trditve je treba brati skupaj z novimi preverjanji.
The premise
A room for mathematics.
The starting point was 8Z: searching for compact generative descriptions that can reconstruct larger structured results. The operating system was an instrument for that research, not the end goal.
Instead of beginning with a desktop, files, windows and applications, BD and the AI collaborators began with a smaller question: what is the least machinery needed to boot, execute our own mathematical rules, and see their output? The resulting environment would expose decisions normally hidden beneath a general-purpose operating system.
The original story called this the “silent room”: an ambition to control execution, reduce unnecessary interference and eventually support demanding compression experiments. That ambition explains why the project exists. It is not, by itself, a measurement of performance or timing. [A]
A small rule makes a pattern.
A feedback loop asks what that pattern is becoming.
The original 8Z plan — and why the visual experiments came first
The long-term plan was to finish a strong 8Z implementation with the intended 4C + 4M modules, port the proven engine to native C++ on Windows 11, and develop the OS in parallel toward supporting more complex C/C++ programs. The full engine was not already running inside these early kernels.
A graphics experiment was a smaller, visible bridge. It needed only a boot path, arithmetic, memory and a way to draw. That made it useful for testing whether the execution environment actually worked, while also expressing a central 8Z intuition: a short generative description can produce a much richer visible result.
The direction stayed practical: prove the engine in a mature development environment, then give it an increasingly capable dedicated host. The OS experiments were not a plan to install a Python interpreter and its ecosystem inside a tiny kernel. Python belonged to the host-side build tools.
What “bare metal” means here — without the zero-jitter claim
The guest executes its own assembly and freestanding C++ kernel. It does not ask a Windows or Linux guest OS to render frames, allocate its working arrays or schedule its application loop. That is the meaningful bare-metal-style property of the implementation.
The preserved demonstrations nevertheless run inside VirtualBox on a host computer. A guest without a general-purpose OS still depends on the virtual machine and host scheduling. The archive does not establish zero jitter, guaranteed real-time timing or an advantage over an equivalent, well-engineered native program.
Nor does ordinary scheduling interference automatically destroy mathematical correctness. The earlier story's stronger wording is part of the historical narrative, not a result demonstrated by these sources. Physical boot and a fair same-core comparison remain separate engineering steps.
The first boot
Before the butterfly,
there was one pixel.
The earliest preserved versions move through text output, static graphics and a cellular automaton. With Rule 90, each new cell is the XOR of its left and right neighbours. A tiny rule and a single seed build a branching triangular structure. There is no observer or controller yet—just our code, its state and the screen. [B]
The difficult boundary
To grow beyond the first experiment, the project needed a reliable transition from BIOS-era startup into a 32-bit C++ kernel. Stack initialization, segment registers, memory placement and interrupt handling all mattered.
The archives preserve failed attempts as well as the eventual V-014 “Direct Handoff” path. The useful outcome was an explicit, inspectable startup sequence—not an unexplained last version that happened to work.
Inside the boot chain — 512 bytes to kernel_main
The boot sector starts at 0x7C00. It initializes its execution environment, reads the kernel through BIOS services into 0x1000, and requests VGA Mode 13h. It then disables maskable interrupts, loads the Global Descriptor Table, switches into protected mode and performs a far jump.
BIOS boot sector at 0x7C00
→ initialize stack and segments
→ load kernel at 0x1000
→ select VGA Mode 13h
→ CLI · load GDT · set CR0.PE
→ jmp dword 0x08:0x1000
→ kernel_entry: data segments + 32-bit stack
→ kernel_mainThe linker places the entry code first. The assembly entry stub prepares the C++ environment rather than assuming that BIOS state is suitable. The framebuffer is the familiar 320 × 200 indexed-colour region at 0xA0000.
The host-side toolchain combines Python build automation, NASM and i686-elf compilation/linking. The executable guest is freestanding: standard desktop libraries and ordinary OS services are not supplied automatically. “No guest OS dependency” does not mean “no development tools” or “no virtual machine.” [B]
The crashes — what the source establishes, and what the old explanations do not
The development notes discuss uninitialized stack state, segment mistakes during disk loading and the infamous VirtualBox “Guru Meditation” failures. Several AI systems supplied diagnoses, including competing explanations. Their agreement or disagreement is part of the debugging record, not independent experimental replication.
The retained code shows concrete changes: explicit initialization, a clearer BIOS-to-kernel boundary, correct placement of the entry stub and the protected-mode handoff. Those changes can be inspected. The stronger story that a particular queued hypervisor interrupt definitively caused every earlier failure is not established by the retained record.
One diagnostic script also looked for a boot signature in the first 512 bytes of a VDI container, confusing the container header with the virtual disk's boot sector. Its negative result cannot establish that the disk was unbootable. Failed diagnostics are useful when they become better checks. [D]
The “six-hour operating system” — a sprint, not the whole chronology
The earlier presentation's title records the intense initial sprint. It should not be read as a stopwatch-verified claim that every later application and interface was completed in six hours.
The recovered development spans at least 12–15 December 2025, followed by additional v0.07 artifacts. Some ZIP timestamps have no timezone; copying changed some file dates; version numbers within application names do not always identify an OS release. The sequence below is better supported than an exact hour-by-hour reconstruction.
Text, pixels, Rule 90
The first boot and compact generative graphics.
A stable 32-bit handoff
Bootloader, entry stub and linker brought into alignment.
Digital Lava → E4-Metal
Pi-driven automata, then the CCH-inspired observer and controller; keyboard interaction follows.
A growing multi-app environment
Menus, six applications, help, palettes and HUDs—with regressions that had to be repaired.
The animation that opened the next question
Digital Lava.
Structure in motion.
Orange and red pixels pour down the screen. What looks like a moving texture comes from a compact recipe: a row of cells, three rules, and digits of π deciding which rule comes next.
Pi Art becomes the Matrix Waterfall: generate a new row at the top, shift older rows down, repeat. In the recovered early sources, digits select among Rules 90, 30 and 184. The visual richness is not stored as a movie. It is generated as the program runs. [B]
Original demonstrationArchive video · not a live kernel
But the animation is open-loop. The program follows its rule-selection sequence; it does not measure whether the resulting pattern is too regular or too disordered. The next rule is not a decision made from observed complexity.
That distinction is the bridge to the next experiment. Digital Lava made changing regimes visible. The question became whether a second layer could watch the system and act on what it observed.
The compact recipe — π is a driver, not an observer
The recovered early Pi Art and Matrix files contain a table of 320 π digits. Their parity seeds the initial cells. Digits 0–5 select Rule 90, 6–7 select Rule 30, and 8–9 select Rule 184; another digit determines how long a rule remains active. A later interactive Matrix uses a shorter 40-digit table.
The older “1 KB of π” description is therefore not an exact description of those retained sources. More importantly, the table is predetermined. Its digits do not change in response to the rendered output.
π digits → choose a rule and its duration
→ evolve a row of cells
→ draw it, scroll the old rows
→ repeat the programmed sequence
No measured-output → rule-selection feedback in this experiment.This is a visible example of compact generation, not proof that arbitrary data can be compressed to a tiny formula. A working lossless codec must still account for the complete description and reproduce the required bytes exactly.
The first Digital Claustrum
Not a new colour.
A new relationship.
The decisive change was to separate the system that evolves from the system that watches—and connect them with feedback.
The December documents connect two research directions: 8Z OS supplied the executable visual laboratory; CCH, the consciousness/claustrum hypothesis, supplied the motivation for a controller. The E4-Metal plan proposed bringing a toy experiment into the C++ kernel. The surviving implementation uses three coupled Lorenz oscillators, not the five initially mentioned in the plan. [A]
The earliest recovered kernel-claustrum.cpp is 207 lines. It evolves the oscillators, records a binary signal, estimates its complexity, compares that estimate with a target, and adjusts a shared coupling parameter. The code is small enough for the entire control idea to remain inspectable. [C]
01 / DynamicsGenerateThree Lorenz trajectories evolve in fixed-point arithmetic.
02 / HistoryObserveKeep 64 binary samples from the sign of the first oscillator's x.
03 / EstimateCompareA simplified LZC score is compared with a target and deadband.
04 / ControlAdjustChange coupling u, bounded between 0 and 5.
↳ coupling feeds back into the next dynamics step ↲
Live reconstruction · S060 mathematical core
SELF-CHECK · WAITING
Step0
LZC / target— / 15
Coupling u0.0
History0 / 64
ControllerWARMING SENSOR
This is not a look-alike Lorenz demo. The browser port uses the recovered 16.16 fixed-point constants, the same three starting states, the same mean-field coupling, the same 64-sample sign history, the same simplified LZC routine, the same ±0.5 deadband controller, the same 0…5 clamp, and the original 320×200 x–z projection/framebuffer logic. The default preset is the recovered kernel configuration. The two diagnostic presets alter only starting u or target so the same controller can be seen moving.
The canvas pixels are computed from source-equivalent state. “Enhanced” only applies a browser display filter above those pixels; switch it off to see the unamplified VGA-style palette. Palette controls likewise change only the browser-side RGB lookup table: framebuffer indices and the mathematical state remain untouched. “Auto colors” now flows continuously through rainbow hues, producing a gently changing rainbow butterfly without feeding anything back into the dynamics or controller. A built-in step-64 self-check compares the JavaScript state to the recorded C++ probe before animation is allowed to run. Source: S060, SHA-256 018d3512…2aa8.
Inside the mathematics — three oscillators, one shared control parameter
The source uses 16.16 fixed-point arithmetic and a wider intermediate multiplication. The Lorenz parameters are σ = 10, ρ = 28 and β = 2.666, with a quantized timestep of 0.01. The three initial x values are 1.0, 1.1 and 0.9; each starts with y = 1 and z = 20.
dxᵢ = σ(yᵢ − xᵢ) + u(mean(x) − xᵢ)
dyᵢ = xᵢ(ρ − zᵢ) − yᵢ
dzᵢ = xᵢyᵢ − βzᵢ
u = shared coupling strengthCoupling pulls each x coordinate toward the current mean. Changing u is the proposed intervention. The equations specify a toy dynamical system; calling its components “neurons” is an analogy in the historical story, not a biological identification.
The observer — what the 64-sample sensor actually sees
At each step, the observer stores whether the first oscillator's x coordinate is positive. These are 64 binary samples stored in a byte array, not a measurement of every coordinate of every oscillator. Once the buffer is full, the code calls its simplified Lempel–Ziv-like complexity estimator.
This is a deliberately narrow sensor. It does not directly measure all-system integration, pairwise synchronization, consciousness or the quality of a compression model. A richer picture on the screen need not imply a larger value from this particular observation channel.
The score is unnormalized, and the target of 15 is described in the original code as a calibrated guess. Sensor choice, window length, sampling and target selection are therefore experimental design choices—not incidental details.
The control law — thresholds, deadband and saturation
Every full history window produces an error relative to the target. A sufficiently negative error lowers coupling by 0.5; a sufficiently positive error raises it by 0.5. The middle band leaves coupling unchanged, and the result is clamped.
// Readable transcription of the recovered law; not a new algorithm.
e = measured_lzc − target_lzc
if e < −2: u = u − 0.5
if e > 2: u = u + 0.5
u = clamp(u, 0, 5)
Recovered defaults: target_lzc = 15; u = 0.This is a threshold controller with a deadband, not proportional control: crossing a threshold always requests the same 0.5 change, regardless of the magnitude of the error. Whether that request produces a useful intervention depends on the sensor, the dynamics and whether the actuator is already at a limit.
The first red bar displays coupling u. A later HUD label “CMPLX 15” displays the configured target, not necessarily a current measurement. Matrix's “S” denotes speed. Those labels should not be merged into a supposed consciousness meter.
The important distinction
The architecture exists in code. That is different from showing that its default configuration actively regulates the trajectories. The recovered experiment lets us test that distinction.
From interpretation to evidence
The butterfly was real.
What was the controller doing?
The original narrative interpreted the dense butterfly and its red bar as successful regulation between order and chaos. The new documentation does something more useful than repeating that interpretation: it isolates the recovered mathematical core and compares controller-on with controller-off.
In the recorded 100,000-step host-side test, the default target is 15 and coupling starts at 0. The measured simplified LZC is only 2 or 3. The law therefore requests lower coupling—but it is already at its lower bound. Coupling stays at zero. [E]
| Recorded condition | Steps | Observed result |
|---|---|---|
| Target 15 · u starts at 0 · ON | 100,000 | u remains 0; LZC is 2 or 3. |
| Same defaults · OFF | 100,000 | Recorded CSV is byte-identical to ON. |
| Target 15 · u starts at 2 · ON | 100,000 | Four decrements of 0.5 bring u to 0. |
| Diagnostic target 0 · u starts at 0 · ON | 100,000 | Ten increments of 0.5 bring u to 5. |
The observer and controller functions execute. Under the recovered defaults, however, their requested action cannot change the dynamics. The on/off equality supports a precise conclusion: no active control contribution to the recorded trajectory in this tested default case.
That does not erase the invention of the architecture. It also does not establish that other parameters cannot work, or that later DCC systems fail. It tells us exactly which claim the original image cannot carry on its own.
How the test was bounded — and how to read its result
The Origins package contains the extracted C++ mathematical/control core, a test driver, four CSV traces and a receipt. Its recorded build uses g++ 14.2.0 with undefined-behaviour checking; the four runs report no sanitizer errors. Boot code, device access and graphics are excluded.
The two default runs each contain 1,562 complete 64-step windows: 977 score 2 and 585 score 3. Their CSV files have the same SHA-256, reproduced in the source notes below. This is stronger evidence about that controller's activity than comparing two attractive screenshots.
The target-0 run deliberately exercises the opposite control branch. Zero is outside the interactive minimum of 5; it is branch-coverage evidence, not a proposed scientific fix. These are preserved probe results from the new documentation, not a fresh boot of the original virtual disks.
What we keep from the original story — and what becomes a hypothesis
We keep the historical achievement: a working visual kernel, the meeting of generative mathematics with the CCH idea, and an implemented observer/controller loop. We also keep the excitement of seeing the system evolve. The original presentation is preserved unchanged rather than rewritten out of the record.
We do not upgrade “the bar appeared to move” or “the butterfly became dense” into proof of homeostasis. A different historical revision or parameter setting remains possible, but the inspected default source has no matching, verified trace that rescues the stronger claim.
CCH remains a hypothesis. Neither the images nor this toy-model test demonstrate subjective experience, establish the biological role of the claustrum, or validate a general theory of consciousness. They define an experiment that can be improved and tested.
Keep the discovery.
Make the claim testable.
The growing OS
Six applications.
One small environment.
The project did not stop with one attractor. Standalone experiments were brought into a menu-driven environment, with keyboard interaction, pause/reset, help text, palettes and on-screen parameters. The revised v0.05 already contains six applications; v0.06 develops the interface and presentation further. [F]
Digital Claustrum
Lorenz trajectories, a history sensor and adjustable coupling in the controller-bearing branches. The precise branch matters.
Rainbow XOR
Moving colour patterns built from bitwise formulas. A distinct visual application, not another name for the Lorenz controller.
Sierpinski / Rule 90–30
Cellular-automaton structures with visible changes under different rules. A direct view of how local rules shape global patterns.
Game of Life
A two-dimensional cellular-automaton experiment in the same graphics environment. Complex evolution does not require a large interface.
Starfield
A depth-and-motion display through projected stars. Another test of small mathematical programs sharing the kernel's drawing tools.
An important regression — a feature can keep its name and lose its mechanism
Not every higher-looking version was a scientific improvement. One early multi-app branch retained Lorenz rendering but dropped the observer and coupling control. A “Rainbow Claustrum” branch even kept the Claustrum name while replacing its dynamics with an XOR/AND visual effect.
| Recovered source | What changed |
|---|---|
| S060 · first standalone Claustrum | Lorenz + history + LZC + coupling control present. |
| S066 · kernel-multi1 | Lorenz rendering retained; observer and controller absent. |
| S065 · v0.04 Final Interactive | The controller is restored. |
| S069 · kernel-multi_strange | “Rainbow Claustrum” label; XOR/AND visuals, not the original mechanism. |
| S068 · half_OK | Separate Lorenz/Rainbow, but controller still missing. |
| S063 · revised v0.05; S064/S070 · v0.06 | Six applications and restored control structure. |
The durable lesson is not to distrust visual polish. It is to test mechanism preservation explicitly. Compilation, a working menu and a familiar feature name do not establish that the research behaviour survived a refactor.
The recovered v0.07 — why a filename is not a resume point
The later source check also found 8Z OS v0.07_min.zip and a larger v0.07 archive in the evidence mirror. The inspected min package contains a six-app kernel identifying itself as v0.07. Another file still named kernel-multi_v0.06.cpp also carries v0.07 identity in its contents.
The source's existence is established; a new acceptance boot of that package is not. Before a future OS build, the exact sources and working binaries should be compared. Rebuilding “v0.07” from an older planning note would risk repeating work or dropping later changes.
The larger v0.07 archive was located by the reconstruction, not fully inspected there. Its later modification time is not enough to declare it the final implementation. [F]
From Claustrum to DCC
The inheritance
is the feedback loop.
Do not govern only the next algorithmic step. Observe the regime the whole process is entering—and influence what it does next.
That is the connection from the early Digital Claustrum to the later DCC research line. The OS archives directly document the bridge from 8Z and CCH into E4-Metal. The broader lineage to DCC combines BD's project continuity with an architectural comparison. It is not evidence that every subsequent controller copied the same function unchanged.
Terminology
On MDL×DCC.org, DCC currently means Dynamic Complexity Controller. The 2025 Digital Claustrum is presented here as an architectural ancestor of DCC—not as the same implementation, and not as evidence of a biological or conscious claustrum. “Digital Claustrum Controller” is therefore not used here as the current expansion of DCC.
| Early Digital Claustrum | The more general idea |
|---|---|
| Several oscillator trajectories | Several candidates, routes, workers or branches of a process. |
| History of a binary signal | Evidence about behaviour over time, not just the latest output. |
| A simplified LZC estimate | Chosen indicators of complexity, progress, stagnation or utility. |
| A target and deadband | Criteria for deciding when intervention is warranted. |
| Coupling u, with limits | Bounded control over cooperation, budget, focus, scale or search width. |
| Fast dynamics; slower observation | Separate the execution loop from the governance loop. |
The right-hand column is a conceptual mapping, not a list of features already present in a 207-line 2025 kernel. The current research programme connects description, search and control more broadly; this early experiment is one of its origins. [G]
What carries forward — and what must be designed again for each domain
A useful controller requires an observable signal, memory, an intervention and a way to determine whether the intervention helped. Those roles can transfer. Their implementation, thresholds and even the meaning of “more complexity” need not transfer unchanged.
In later search work, a controller may influence exploration, restart behaviour or the allocation of computation. That does not make oscillator coupling identical to a search budget, or make the original LZC function the correct sensor everywhere.
MDL and DCC also occupy different roles: description-length evaluation assesses a model together with what remains unexplained; governance decides where a process puts effort next. The historical Claustrum does not already implement a general MDL-selected governor, self-learning control law or recursive inter-worker hierarchy.
The inspected OS archives do not identify the first later commit that introduced the DCC name or the exact first cross-domain port. No date is invented to complete the diagram. “Digital Claustrum Controller” is not asserted here as an already demonstrated consciousness architecture.
What comes next
Build the engine.
Then give it a home.
The long-term 8Z OS direction remains a purpose-built mathematical and compression appliance: a small execution environment that can host increasingly capable native code. It is a direction, not a description of capabilities already delivered by the archived visual kernels.
The accepted sequence is to validate the intended 8Z 4C + 4M implementation, bring the proven engine to native C++ on Windows 11, and evolve the OS in parallel. That retains mature debugging and profiling tools while the smaller platform earns the services the engine actually needs. [A]
The engineering roadmap — requirements, not completed features
First: establish the correct starting point
Reconcile the recovered v0.07 source with other known working packages. Preserve the source, build inputs and exact hashes; identify which branches actually contain the intended mechanisms.
Then: make the environment useful to native code
Grow memory management and a minimal compatibility layer according to real library requirements. Add the needed I/O, result export and more capable framebuffer support rather than assuming those services exist because the compiler accepts C++.
Separately: physical boot and controlled evaluation
A UEFI/USB path and physical-machine acceptance are distinct from a VirtualBox screenshot. Compare equivalent mature native engines under stated conditions before claiming a bare-metal advantage. The archived project has not supplied that comparison.
Keep the scientific mechanism under test
For a renewed Claustrum experiment, calibrate the observation channel and target, record actual actuator changes, and compare the controlled trajectory against a matching uncontrolled baseline. Preserve failed and saturated cases as evidence, not as files to discard.
Present / planned
Present in the retained record: a boot path, 32-bit C++/ASM, direct graphics, generative mathematics, an implemented observer/controller, keyboard interaction and a six-app environment.
Not established by these archives: the full 8Z engine running inside the OS, physical USB boot, a general filesystem/library environment, proven timing superiority or consciousness.
Read the evidence, not only the narrative
The record stays open.
This presentation is based on the original public OS page and media, the original development archives, and 8Z_OS_ORIGINS_COMPLETE_20260917_R1. The new reconstruction separates historical interpretation, inspectable code, recorded tests and future plans.
The reconstruction reports 8 source archives, 210 distinct contents, 87 text/source/configuration contents and 23 unique screenshots. These are coverage figures for that reconstruction—not new performance results or independent replications. The same file appearing in several backups is still one content item. [D]
Source notes — documents, code identity and the recorded test
[A] The original motivation and the reconstruction
The 8Z OS Origin Story v1.2.txt (S034), The Consciousness Controller Story.txt (S035), The Digital Claustrum Gemini.txt (S036), and 8Z_App_V_8Z_OS_v1.2.txt (S025). Reassessed in 8Z_OS_ORIGINS_ANALYSIS_20260917_R1.md and the R2 continuity record.
The original accounts preserve the human–AI development narrative. The September reconstruction is used for its exact-content checks and explicit qualification of the earlier claims.
[B] Boot, graphics and the Lava recipe
Numbered source catalog: S037 (stable boot), S074 (kernel entry), S075 (linker), S073 (early Rule 90), S071/S072 (Pi Art/Matrix), S062 (interactive Matrix). These are source identifiers within the Origins evidence package, not version numbers of the OS.
[C] The first recovered Claustrum
S060, kernel-claustrum.cpp, in the nested Dev/bck/v0.02.zip backup. Archive timestamp: 13 December 2025; 207 source lines. The fixed-point dynamics, 64-sample sensor, target and control law are taken from this specific source.
Source SHA-256
018d3512d72b94d91126253d0024cbecd9bc0e78ce0db117b7311cd223e82aa8
[D] Archive coverage and limits
The eight inputs are 8Z OS v0.01.zip, 8Z OS Dev.zip, 8Z OS Docs.zip, 8Z OS key files.zip, 8Z OS v0.03.zip, 8Z OS v0.04.7z, 8Z OS v0.05.7z and 8Z OS v0.06.zip. The recorded inventory includes 1,093 file occurrences including nested backups, deduplicated by SHA-256.
The reconstruction does not claim a fresh run of the original VDI images, a rebuild using the original i686 toolchain, a complete historical-chat transcript or manual reading of every VM log line. S086/S087 retain the flawed VDI-header diagnostic discussed above.
[E] Bounded mathematical-core test
tests/claustrum_math_probe.cpp, tests/math_probe_receipt.json, and the four CSV traces in the evidence package. The default-on and default-off recorded CSVs share this exact SHA-256:
cf8c27c631cd69ddeb12307fd4b5e50d59bb57481117f7d3782efda705054a64
The result is limited to the recovered source, settings and 100,000-step host-side runs. It is not an OS runtime acceptance test or a test of later DCC arenas.
[F] Multi-app branches and v0.07 recovery
S063–S070 preserve the branch differences. The separately recovered 8Z OS v0.07_min.zip contains a six-app kernel-multi.cpp with this source hash:
fdb074f51f0a9e9e4632a8e05cf343c2aa292a6800507cc6e37a49fce0de23b7
Existence and source identity are distinct from a verified acceptance boot. The misleading older filename is retained in the provenance, not used as the sole version authority.
[G] The later DCC connection
The reconstruction's lineage section and the R2 project continuity provide the conceptual mapping. Current cross-domain descriptions are accessible through the 8z–MDL×DCC technical entrance. The first later DCC commit and an unchanged algorithmic identity across all arenas were not established by the OS archive review.
The earlier presentation and all original public material
Previous index — preserved byte for byte ↗
That page retains its original narrative, multilingual summaries, code excerpts and historical interpretations. It remains available for comparison. Claims about zero jitter, demonstrated edge-of-chaos regulation or consciousness should be read with the qualifications and recorded probe above.
Earlier story edition ↗ · Historical interpretation of the images ↗ · Original video ↗
Images and video on this page reuse the existing public files without altering their pixels or recording. Click a screenshot to inspect the full image. The source notes expose scientific provenance, not private workspace links or machine credentials.
Less describes more.
The first pixels showed that it ran.
The feedback loop changed
what we wanted to build.
8Z OS is both a small engineering artifact and a place where a larger research idea took executable form. Its limitations belong in the story—because they tell the next experiment where to begin.
The OS remains unfinished by design: the next goal is not a prettier demo, but a stronger native mathematical engine with an increasingly capable dedicated host.
Back to the beginning ↑