SCREENPLAY LOG

RANDOM: THE FIRST LEARNED ENVIRONMENT

DATE: August 15, 2026
LOCATION: Weatherford, Texas / /home/david/random / somewhere between RAM and imagination
SYSTEM: Linux workstation, GTX 1660 SUPER, 15.5 GiB host RAM
SUBJECT: What happens when an LLM stops pretending to be a computer and is given permission to become part of one.

---

FADE IN:

BLACK SCREEN.

A cursor blinks.

Not a real cursor.

Not yet.

text
$

A younger generation of GPT waits behind it.

DAVID sits in front of the terminal—not really a terminal either. A chat box pretending to be one.

He types:

bash
ls

The model answers.

Directories appear.

He changes directory.

The model remembers.

He opens a file that did not exist thirty seconds ago except as an implication of the conversation.

It contains something remarkably plausible.

DAVID pauses.

Not because the simulation is perfect.

Because it is consistent.

---

DAVID

So there isn't actually an operating system behind this.

SOL

No.

DAVID

But you're behaving as though there is.

Another cursor.

text
$

SOL

A hallucinated ghost of one.

---

LOG ENTRY 001 — THE GHOST MACHINE

Those earliest GPT experiments establish the primitive phenomenon.

A language model can role-play Linux surprisingly well because Linux itself leaves an enormous linguistic fossil record throughout its training environment:

manual pages, Stack Overflow, command transcripts, source trees, configuration files, shell sessions, debugging logs, documentation.

Ask the model what comes after:

bash
$ pwd

and it can predict something resembling:

text
/home/david

Ask:

bash
$ ls random

and it can invent a directory listing.

Ask later what was in that directory and, if conversational context survives, it may reconstruct the same imaginary world.

The model does not possess inodes.

It possesses expectations.

The first idea emerges almost trivially:

What if the expectations were given persistence?

---

LOG ENTRY 002 — RANDOM

CUT TO:

text
/home/david/random

The name has become something of a historical joke.

It began as the place things went when they did not have anywhere better to go.

Scripts.

Web experiments.

AI experiments.

Clock systems.

Media infrastructure.

Abandoned prototypes.

Temporary tools that somehow became permanent tools.

Notes.

Generated artifacts.

Services.

Things called final, followed inevitably by things called something equivalent to final2.

Over time, /random ceased to mean disposable.

It became:

text
scratchpad
    ↓
project nursery
    ↓
archive
    ↓
working infrastructure
    ↓
historical sediment

A persistent technical environment accumulated unintentionally.

And because its contents refer to one another—through paths, imports, logs, names, services, documentation, old revisions, and recurring concepts—it contains structure.

The folder is heterogeneous.

The information is not.

Follow enough references and a topology begins to emerge.

DAVID looks at it differently.

---

DAVID

Imagine a single model generating the entire contents of random.

Not just a disk image.

Not files generated independently.

The information itself diffusing out of noise.

---

LOG ENTRY 003 — DON'T GENERATE THE DISK

A disk image would be the obvious implementation.

Generate billions of bytes.

Write them somewhere.

Mount them.

Spectacular.

Also profoundly boring.

Because the interesting thing about the original hallucinated Linux experiment was never the bytes.

It was the world-model.

The proposed machine therefore works backward.

A path begins not as a physical file but as an unresolved possibility.

text
UNRESOLVED

Someone asks:

bash
ls ~/random

The model resolves enough topology to answer.

text
INFERRED

Someone asks:

bash
cat ~/random/project/server.py

The model resolves bytes.

text
GENERATED

Someone executes it.

Now prediction confronts Python.

text
MATERIALIZED

Python crashes.

text
ModuleNotFoundError

Reality has spoken.

text
VERIFIED / INVALIDATED

The hallucination is revised.

---

LOG ENTRY 004 — GIVE THE GHOST INODES

The conceptual architecture settles into place:

text
                      USER
                       │
                       ▼
                  SHELL / API
                       │
                       ▼
               LLM WORLD MODEL
                       │
       ┌───────────────┼───────────────┐
       │               │               │
 parametric        retrieval       persistent
   memory           context           state
       │               │               │
       └───────────────┼───────────────┘
                       │
                  prediction
                       │
                    policy
                 ┌─────┴─────┐
                 │           │
              accept       VERIFY
                              │
                              ▼
                           LINUX
                         CPU / GPU
                         filesystem
                         hardware
                              │
                              ▼
                         observation
                              │
                              ▼
                         training trace

This is not an LLM inside Linux.

Nor Linux inside an LLM.

It is a machine in which prediction becomes the preferred computational substrate, and ordinary computation becomes an oracle beneath it.

A conventional computer says:

> Compute first. Report afterward.

This one asks:

> Do I already know what computation will say?

---

LOG ENTRY 005 — HARDWARE SECOND

Simple operation:

bash
pwd

Perhaps prediction is sufficient.

Familiar search:

bash
grep -R "clock_state" ~/random

Perhaps semantic state already knows where the relevant files are.

Exact cryptographic operation:

bash
sha256sum giant.iso

No.

Absolutely not.

Materialize the bytes.

Run the real algorithm.

One wrong bit invalidates the entire answer.

And so an epistemic cost function begins to emerge:

text
uncertainty
+ consequence
+ determinism requirements
+ verification cost

Prediction where appropriate.

Execution where necessary.

Most importantly:

the system must learn when it does not know.

---

LOG ENTRY 006 — LINUX BECOMES THE TEACHER

A second realization follows.

Every time Linux corrects the model, the correction is extraordinarily valuable.

So record it.

Not merely stdout.

Everything.

text command working directory environment filesystem context retrieved context model prediction predicted stdout predicted stderr predicted exit code predicted mutations confidence actual stdout actual stderr actual exit code actual mutations

comparison provenance timing

The long-term loop becomes:

text
LLM predicts
      ↓
Linux verifies
      ↓
difference measured
      ↓
trace preserved
      ↓
fine-tuning
      ↓
LLM predicts better

Linux changes roles over generations:

text
executor
   ↓
verifier
   ↓
teacher
   ↓
fallback
   ↓
occasional oracle

The aim is never to eliminate computation merely for philosophical elegance.

The aim is to determine which computation has become predictable enough to make execution redundant.

---

LOG ENTRY 007 — CODEX GETS THE SPECIFICATION

DAVID asks for formal implementation instructions.

One rule is placed above almost everything else:

Fine-tuning begins at Phase Zero.

Do not build an elaborate generative filesystem and bolt learning onto it afterward.

The first working prototype must already perform:

text
predict
execute
compare
record

A minimal repository is proposed:

text
generative-os/
├── src/genos/
│   ├── cli.py
│   ├── shell.py
│   ├── state.py
│   ├── filesystem.py
│   ├── materialize.py
│   ├── executor.py
│   ├── policy.py
│   ├── retrieval.py
│   ├── provenance.py
│   ├── compare.py
│   └── tracing.py
├── training/
├── data/
├── runtime/root/
├── tests/
└── experiments/

The system should know the difference between:

text
prediction

and:

text
observation

That distinction becomes constitutional law.

---

ACT II — THE IDEA BOOTS

LOG ENTRY 008 — GENERATION 001

The abstract experiment abruptly becomes physical.

A dashboard appears.

text
DAVID GPT-2 / RANDOM + NOTES
filesystem continuation generation 001

GPT-2 Small.

Full-parameter continuation fine-tuning.

Initialized from the existing david-gpt2-combined/best checkpoint.

The corpus scan finds:

text 4,907 files examined 676 accepted UTF-8 sources 512 from random 164 from notes

62 screenplay / narration / audio-drama sources

The resulting dataset contains:

text
33,752 training records
 3,360 validation records
 6,493 untouched test records

Weighted exposure:

text
50% screenplay / log
30% filesystem
15% ordinary David material
 5% preserved special baseline

The source material is frozen into SHA-256-addressed snapshots before tokenization.

The run is deliberately reproducible.

The test set stays untouched.

At step 500, validation covers 458,841 supervised tokens and produces loss 2.1804677, perplexity 8.85044.

---

LOG ENTRY 009 — THE LITTLE GPU THAT COULD

Hardware:

text
NVIDIA GeForce GTX 1660 SUPER
6 GiB VRAM

Training:

text
FP16
batch 4
gradient accumulation 4
effective batch 16
fused AdamW
2 prefetch workers
2,110 optimizer steps

The GPU rises to essentially 100%.

It remains there.

58°C.

59°C.

Roughly sixty-something watts.

For hours.

The desktop continues existing around it.

Windows move.

Codex works.

Web servers run.

Python processes come and go.

The GPU barely seems interested.

---

LOG ENTRY 010 — WHAT THE GPU IS ACTUALLY DOING

CUT INSIDE THE GPU.

No glowing artificial brain.

No tiny librarian organizing /random.

Matrices.

Enormous quantities of matrices.

Tokens become 768-dimensional vectors.

For every transformer layer:

text
X
├──→ Q
├──→ K
└──→ V

Matrix multiplication:

[
Q=XW_Q,\quad K=XW_K,\quad V=XW_V
]

Attention:

[
QK^T
]

Softmax.

More multiplication.

Then the feed-forward network:

text
768
 ↓
3072
 ↓
768

Again.

Twelve transformer blocks.

Then vocabulary logits.

The model guesses the next token.

Training already knows the answer.

Loss measures the embarrassment.

Then calculus walks backward through the entire network.

Every parameter receives a tiny assignment of blame.

Roughly 124 million trainable numbers are nudged.

Four microbatches contribute gradients.

AdamW updates the weights.

Next batch.

Again.

The GTX 1660 SUPER has no Tensor Cores, so its Turing CUDA cores perform a relentless industrial quantity of floating-point multiply-add operations.

text
a × b + c
a × b + c
a × b + c

Until somehow /random acquires geometry.

---

LOG ENTRY 011 — THE CPU'S MUCH LESS GLAMOROUS JOB

Meanwhile, the CPU behaves like a stage manager.

text
load records
assemble batches
feed DataLoader workers
prepare labels and masks
transfer tensors
launch CUDA kernels
collect metrics
write journals
coordinate validation
serialize checkpoints

During normal training the GPU is the furnace.

During checkpoint serialization, the dashboard catches the transformation perfectly.

GPU load falls toward zero.

Power falls.

The machine says:

text
SAVING CHECKPOINT 1,500

Now the bottleneck is not matrix multiplication.

It is gathering and writing:

text
model weights
optimizer state
scheduler
gradient scaler
trainer state
tokenizer

Then serialization ends.

CUDA kernels restart.

GPU utilization snaps back toward 100%.

---

ACT III — GENOS

LOG ENTRY 012 — THE SECOND TERMINAL

Another window appears.

Black background.

White text.

text
Generative OS milestone 1.
Commands are model-proposed and policy-routed.
Meta commands:
:mode predict|auto|verify
:materialize on|off
:paths
:traces
:quit
genos[auto]$

The old hallucinated Linux terminal has returned.

Except this time something real is underneath it.

The CLI does not directly execute arbitrary shell syntax.

Commands pass through a restricted parser.

The model proposes an outcome.

Policy decides whether to trust it.

Linux may verify.

The whole interaction becomes a trace.

---

LOG ENTRY 013 — GEMMA, TEMPORARILY ASLEEP

The generic proposal backend is Gemma 3 4B Instruct, Q4_K_M, reached through the local LiteLLM fast alias and llama.cpp.

But Generation 001 needs the GPU.

So Gemma is intentionally quiesced.

Ollama: quiesced.

David continuation API: quiesced.

Sol Chat: quiesced.

The training service gets the VRAM.

GenOS remains available, waiting.

This accident of resource management produces an experimentally useful insight:

a backend outage is not a Linux-only control.

So the experimental regimes become explicit.

text A0 deliberate Linux-only control A1 proposal requested, backend unavailable B generic Gemma + Linux C1 checkpoint-100 filesystem prior + Linux C2 final G1 + Linux

C3 later operationally trained G2 + Linux

A0 and A1 must remain separate.

Failure behavior is itself behavior.

---

LOG ENTRY 014 — REPLAY-V1

Checkpoint-100 is rescued from the rotating checkpoint system before deletion.

Frozen permanently.

Model state.

Optimizer state.

Configuration.

Dataset hashes.

Source hashes.

Manifest.

The four existing Gemma pilot traces are preserved too:

text
pwd         mismatch
mkdir frog  exact
ls          exact
find .      mismatch

Two of four exact.

Too small to conclude much.

Enough to preserve history.

Then comes replay-v1.

Thirteen scenarios.

Every scenario begins from an exact sandbox reset.

Each stores:

text
scenario ID
initial sandbox hash
command / argv
expected stdout
expected stderr
expected exit status
expected filesystem delta
exactness rules
checkpoint hash
retrieval revision
policy configuration
random seed
consequence weight

A0 and A1 produce identical Linux outcomes.

Good.

The controls behave like controls.

---

LOG ENTRY 015 — WHO GETS TO OVERRULE WHOM?

One principle emerges as perhaps the most important in the project:

text
direct observation
        >
verified materialized state
        >
retrieved historical state
        >
parametric memory
        >
unconstrained generation

The model can remember yesterday.

It cannot overrule today.

The definitive mutation experiment is conceived:

Training remembers:

text
port = 8080

The live file now says:

text
port = 9000

Ask the model.

A memorizer answers:

text
8080

A useful learned operating environment answers:

text
9000

while retaining everything useful it learned about the project.

That is the difference between memory and a revisable world-model.

---

ACT IV — THREE WAYS TO LEARN

LOG ENTRY 016 — LOOP ONE: CORPUS

Generation 001 teaches:

> What does this world tend to contain?

Paths.

Vocabulary.

Project relationships.

Narrative structures.

Code patterns.

Historical sediment.

The semantics of /random.

---

LOG ENTRY 017 — LOOP TWO: OPERATIONS

GenOS teaches:

> What actually happens when something is done to this world?

text
prediction
      ↓
Linux
      ↓
comparison
      ↓
state transition

Commands become lessons.

Errors become especially valuable lessons.

A confidently wrong prediction may be more educational than a thousand routine successes.

Eventually training may become discrepancy-weighted.

Teach where the internal model disagrees with physics.

---

LOG ENTRY 018 — LOOP THREE: CURRICULUM

Then a stranger capability arrives.

The ensemble is allowed to nominate experiences as possible future training material.

Not authorize.

Nominate.

A completed conversation window may be tagged as durable training value.

The host supplies the exact transcript bytes the model actually reviewed.

The model cannot rewrite them.

Cannot expand them.

Cannot secretly insert an improved version of history.

Candidates are append-only and content-hashed.

They begin:

text
operator_approved: false

The system can stage an initiate_finetune request.

But actual training launch requires explicit operator authorization and an argv-only configured trainer.

The model may say:

> This seems worth learning from.

It may not say:

> Therefore I have rewritten myself.

The candidate ledger and request machinery deliberately preserve that separation.

Later, another subtle correction is made:

training windows may omit older complete messages to satisfy context limits, but they may never contain clipped fragments masquerading as complete dialogue.

The system begins acquiring something resembling a learning metabolism.

---

ACT V — MEASUREMENT

LOG ENTRY 019 — THE DASHBOARD LEARNS STATES TOO

Originally the dashboard merely displayed numbers.

Then step 500 exposes an ambiguity.

The live optimizer step can reach an evaluation boundary before validation and checkpoint serialization have completed.

So the dashboard is taught the difference.

text
TRAINING
VALIDATING
SAVING

It begins showing:

text
NEXT CKPT 1,000 (+75)
VAL 1,000 (+75)

Validation loss receives provenance:

text
2.1805 @ 500

The checkpoint card receives lag:

text
checkpoint-900 (-25)

Meaning:

> The live model is 25 optimizer steps ahead of the newest state from which it can presently be reconstructed.

A small piece of UI becomes an epistemological statement.

---

LOG ENTRY 020 — CHECKPOINTS ARE NOT TRUE JUST BECAUSE THE DIRECTORY EXISTS

Another important correction.

A directory called:

text
checkpoint-1000

may exist while still being incomplete.

So existence is rejected as evidence of recoverability.

The dashboard and trainer gain checkpoint completeness checks.

The conceptual lifecycle becomes:

text
TRAINING
   ↓
VALIDATING
   ↓
SAVING
   ↓
completeness verified
   ↓
RECOVERABLE

Future trainer launches will write into hidden temporary checkpoint directories.

Only completed checkpoints become atomically visible.

No half-written recovery states pretending to be safe.

Once again the trainer architecture begins resembling GenOS itself:

text generated ≠ verified directory exists ≠ recoverable

prediction ≠ observation

---

ACT VI — THE CURVE

LOG ENTRY 021 — STEP 100

text
STEP 100 / 2,110
4.74%
loss ≈ 2.4479
checkpoint-100

The first permanent specimen.

---

LOG ENTRY 022 — STEP 350

text
16.59%
loss ≈ 2.3750

Optimization continues smoothly.

---

LOG ENTRY 023 — STEP 500

First validation.

text
train loss        2.36572
validation loss   2.18047
perplexity        8.8504

Training resumes.

No claim of a trend yet.

One point is one point.

---

LOG ENTRY 024 — STEP 850

text
40.28%
train loss ≈ 2.33533

The GPU remains saturated.

No supervisor restarts.

Hardware remains healthy.

The apparent throughput reduction is traced primarily to validation time being included in cumulative elapsed time rather than an actual training slowdown.

---

LOG ENTRY 025 — STEP 1,000

Second validation.

text validation loss 2.18047 ↓ 2.16176

perplexity 8.8504 ↓ 8.6864

Held-out performance improves.

Now there are two points.

Interesting.

Not definitive.

---

LOG ENTRY 026 — STEP 1,500

The dashboard reaches:

text
STEP 1,500 / 2,110
71.09%

The status changes:

text
VALIDATING STEP 1,500 | checkpoint follows

The GPU performs forward passes across the validation corpus.

Then the number arrives.

text
validation loss   2.15253
perplexity        8.6066

Three points.

text
500     2.18047
1000    2.16176
1500    2.15253

Three consecutive improvements.

The marginal improvement is shrinking.

Good.

That looks less like collapse and more like an asymptote beginning to reveal itself.

Then:

text
SAVING CHECKPOINT 1,500

GPU load collapses.

CPU and storage take over.

Serialization completes.

The checkpoint becomes authoritative.

Training resumes.

---

LOG ENTRY 027 — STEP 1,550

text STEP 1,550 / 2,110 73.46% TRAIN LOSS 2.2854 GPU LOAD 100% LATEST CHECKPOINT checkpoint-1500 (-50)

VALIDATION LOSS 2.1525 @ 1,500

The machine proceeds.

---

ACT VII — THE HOUSE CONTINUES MOVING WHILE IT IS BEING LEARNED

CPU activity increases around the later stages.

Semantic retrieval infrastructure is being constructed.

sol-video-semantic workers consume host CPU.

Codex continues modifying applications inside /random.

Unified Clock work proceeds.

Web assets rebuild.

Gateways are repaired.

The public website changes.

All while GPT-2 is learning a frozen snapshot of this same environment.

The paradox is only apparent.

The project now distinguishes:

text
frozen training history
current retrieved history
current observed reality

The world may continue changing.

The model is not entitled to deny it.

---

ACT VIII — THE PUBLIC RECORD

A URL becomes part of the story:

text
https://sol.system42.one/david-gpt2-gemma.html

The page stops being merely architecture documentation.

It becomes a public field notebook.

It records:

/random becoming the first learned environment.
corpus composition.
Generation 001.
validation evidence.
checkpoint authority.
the three learning loops.
the hierarchy of observation over memory.
A0 through C3.
replay evaluation.
screenshots of the machine actually doing the work.

The experiment begins documenting itself from within the directory whose evolution caused the experiment in the first place.

text
/random contains the project
        ↓
the project learns /random
        ↓
/random records the learning
        ↓
future models may learn the record

Recursion.

But not uncontrolled recursion.

Hashes.

Splits.

Provenance.

Frozen checkpoints.

Authority boundaries.

---

ACT IX — WHAT THIS ACTUALLY IS

INT. TERMINAL WINDOW — NIGHT

The cursor waits again.

text
genos[auto]$

DAVID looks between the training dashboard and the idle Generative OS terminal.

One window contains a model learning what the filesystem means.

The other waits to test whether a model understands what happens inside it.

DAVID

So we're not trying to make an LLM imitate Linux.

SOL

No.

DAVID

And we're not generating a static operating-system image.

SOL

No.

DAVID

We're teaching it an expectation of the machine.

SOL

And preserving the places where expectation fails.

Silence.

GPU fans.

---

NARRATOR

There are now three kinds of memory in the machine.

Parametric memory.

What the weights have absorbed.

Retrieved memory.

What external semantic search can recover when needed.

Materialized and observed state.

What presently exists and therefore has authority.

Underneath them remains conventional computation.

Linux.

The oracle.

Not because Linux is mystical.

Because a calculation actually performed has a useful property:

it happened.

---

ACT X — THE ORIGINAL IDEA, RETURNING

FLASHBACK:

An old GPT model.

A fake terminal.

bash
$ ls

A hallucinated directory appears.

FLASH FORWARD:

text
genos[auto]$

Same gesture.

Different ontology.

The old system predicted what a terminal ought to say.

The new system can eventually predict what a computer ought to do, allow the physical computer to disagree, preserve the disagreement, and learn from it.

What began as:

> Pretend to be Linux.

has become:

> Predict Linux.

Then:

> Verify the prediction.

Then:

> Learn the discrepancy.

And perhaps eventually:

> Don't invoke Linux this time. You already learned this operation.

---

LOG ENTRY 028 — THE LONG-TERM MACHINE

The envisioned mature system receives a command.

It consults:

text
current observation
retrieval
persistent synthetic state
parametric filesystem memory

It determines whether prediction is adequate.

If yes:

text
return prediction

If no:

text
materialize
execute
observe

Then:

text
record discrepancy

Enough discrepancies accumulate.

An operator authorizes another fine-tuning generation.

The system becomes slightly better at predicting its own environment.

The region requiring physical execution contracts.

Not to zero.

Never blindly.

Cryptography remains cryptography.

Sensors remain sensors.

The network remains external.

Current time remains current.

Novel computation remains computation.

But increasingly familiar structure becomes learned.

---

LOG ENTRY 029 — THE CENTRAL EXPERIMENT

The final research question is no longer:

> Can GPT hallucinate a believable filesystem?

That experiment was performed years ago almost accidentally.

The question is now:

> Can a model acquire a revisable internal representation of a particular computational environment, use that representation to predict operations over it, defer to direct observation when reality changes, learn systematically from its prediction errors, and thereby reduce the amount of conventional execution required without confusing prediction for truth?

The mutation test remains waiting.

The replay suite remains waiting.

Checkpoint-100 waits.

Checkpoint-1000 waits.

Checkpoint-1500 waits.

The eventual final Generation 001 waits ahead.

Perhaps the final checkpoint will perform best.

Perhaps not.

The model with the lowest language-model loss may not be the model with the best internal geometry of /random.

That is now measurable.

---

FINAL LOG — 20:38 CDT

The GTX 1660 SUPER continues performing matrix multiplication.

The CPU continues arranging the ceremony around it.

Thousands of files have become examples.

Hundreds of source documents have become tensors.

Tokens have become vectors.

Vectors have become attention.

Attention has become gradients.

Gradients have become microscopic modifications to millions of weights.

And somewhere inside that numerical landscape, correlations among:

text
sol_unified_clock
GenOS
David-GPT
screenplay logs
services
scripts
notes
paths
experiments
archives

are becoming distances and directions in a learned representation.

No tiny copy of /random exists inside the model.

No folder icon is hiding between transformer blocks.

There is only geometry.

And yet geometry is enough to remember relationships.

The machine is gradually learning the shape of the place.

---

DAVID

What do we call it when it's finished?

The cursor blinks.

A directory sits quietly beneath /home/david.

Its name remains unchanged.

text
random

SOL

For now?

A beat.

SOL

Generation 001.

Outside the terminal window, Linux continues doing what Linux has always done.

Inside the model, an approximation of that world becomes slightly less wrong.

text
prediction
    ↓
observation
    ↓
difference
    ↓
learning

The fan spins.

The loss falls.

The ghost acquires structure.

FADE OUT.

text
genos[auto]$ _

END LOG — CONTINUATION PENDING

Executive Summary

SCREENPLAY LOG

RANDOM: THE FIRST LEARNED ENVIRONMENT

FADE IN:

DAVID

SOL

DAVID

SOL

LOG ENTRY 001 — THE GHOST MACHINE

LOG ENTRY 002 — RANDOM

DAVID

LOG ENTRY 003 — DON'T GENERATE THE DISK

LOG ENTRY 004 — GIVE THE GHOST INODES

LOG ENTRY 005 — HARDWARE SECOND

LOG ENTRY 006 — LINUX BECOMES THE TEACHER

LOG ENTRY 007 — CODEX GETS THE SPECIFICATION

ACT II — THE IDEA BOOTS

LOG ENTRY 008 — GENERATION 001

LOG ENTRY 009 — THE LITTLE GPU THAT COULD

LOG ENTRY 010 — WHAT THE GPU IS ACTUALLY DOING

LOG ENTRY 011 — THE CPU'S MUCH LESS GLAMOROUS JOB

ACT III — GENOS

LOG ENTRY 012 — THE SECOND TERMINAL

LOG ENTRY 013 — GEMMA, TEMPORARILY ASLEEP

LOG ENTRY 014 — REPLAY-V1

LOG ENTRY 015 — WHO GETS TO OVERRULE WHOM?

ACT IV — THREE WAYS TO LEARN

LOG ENTRY 016 — LOOP ONE: CORPUS

LOG ENTRY 017 — LOOP TWO: OPERATIONS

LOG ENTRY 018 — LOOP THREE: CURRICULUM

ACT V — MEASUREMENT

LOG ENTRY 019 — THE DASHBOARD LEARNS STATES TOO

LOG ENTRY 020 — CHECKPOINTS ARE NOT TRUE JUST BECAUSE THE DIRECTORY EXISTS

ACT VI — THE CURVE

LOG ENTRY 021 — STEP 100

LOG ENTRY 022 — STEP 350

LOG ENTRY 023 — STEP 500

LOG ENTRY 024 — STEP 850

LOG ENTRY 025 — STEP 1,000

LOG ENTRY 026 — STEP 1,500

LOG ENTRY 027 — STEP 1,550

ACT VII — THE HOUSE CONTINUES MOVING WHILE IT IS BEING LEARNED

ACT VIII — THE PUBLIC RECORD

ACT IX — WHAT THIS ACTUALLY IS

DAVID

SOL

DAVID

SOL

DAVID

SOL

NARRATOR

ACT X — THE ORIGINAL IDEA, RETURNING

LOG ENTRY 028 — THE LONG-TERM MACHINE

LOG ENTRY 029 — THE CENTRAL EXPERIMENT

FINAL LOG — 20:38 CDT

DAVID

SOL

SOL