The idea

Some problems are easy in one direction and hard in the other. Taking a derivative is mechanical. Finding an antiderivative can require genuine creativity. Generating a random expression and verifying a proof is easy. Discovering the proof is hard.

RPSDG (Reverse-Process Synthetic Data Generation) exploits this asymmetry. Run the easy direction with full step-by-step work, then reverse the result to get a hard problem with a known solution. You end up with process-supervised training data: not just the answer, but the entire derivation.

Richard Sutton’s “The Bitter Lesson” argues that methods scaling with compute and data will eventually win. The bottleneck is high-quality data. A lot of the world’s data is latent, the processes that generated it are not written down. In math, the way a proof was discovered is usually hidden behind a polished presentation. RPSDG is one way to manufacture that hidden process data.

Derivatives to Integrals

Computing derivatives is mechanical. Integration often is not. That asymmetry gives us a data pipeline.

1. Start with known functions. Pick functions \( f(x) \) with closed-form derivatives: polynomials, trig, exponentials, logarithms. Vary complexity.

2. Differentiate with full work shown. Take the derivative of \( f(x) \) to get \( f'(x) \), recording every step.

3. Reverse the process. Now \( f'(x) \) is the problem and \( f(x) \) is the solution. The recorded steps, read backward, give you a worked integration example.

By composing functions of varying complexity, you get integration problems of graduating difficulty. The training data comes with step-by-step solutions for free, because you generated it by running the easy direction.

Proofs by Random Walk

The same idea works for theorem proving. Generating proofs is hard. Verifying them is (comparatively) easy.

1. Random walks in expression space. Start with a random expression \( e_{\text{start}} \). Apply rewrite rules \( r_1, r_2, \ldots, r_n \) to get a chain of intermediate expressions ending at \( e_{\text{end}} \).

2. Read off the theorem. The pair \( (e_{\text{start}}, e_{\text{end}}) \) is a theorem. The chain of rewrites is its proof.

3. Reverse when useful. Running the chain backward works too, especially when a complex step in one direction (integration) becomes simple in the other (differentiation).

4. Scale it. Random starting points and random rewrite sequences give you a diverse set of theorems and proofs automatically. No human has to come up with the theorem first.

What this gets you

The training data has process supervision baked in. Every example includes intermediate steps, not just the final answer. That should help LLMs learn multi-step reasoning rather than pattern-matching to answers.

It also gives you something like explainability for free: the model’s training data literally consists of step-by-step solutions, so the model has a better chance of producing step-by-step reasoning at inference time.

Limitations and next steps

This is early work. The data generation pipeline exists, but I have not yet run the full fine-tuning experiments and benchmarks. The planned pipeline is:

• Data generation with graduating difficulty (curriculum learning)
• Fine-tuning transformer-based LMs on the generated data
• Self-supervised learning experiments
• Evaluation against standard math reasoning benchmarks

Further out, I want to explore reinforcement learning for rewarding multi-step reasoning even when the solution is not known in advance but can be verified.

Related

The verification asymmetry exploited here shows up at multiple levels. At inference time, it enables tree search over LLM solutions: I Spent $0.48 to Find Out When MCTS Actually Works for LLM Reasoning. At the level of scientific method, it’s the core of Science as Verifiable Search: cheap testing enables fast iteration through hypothesis space.

I demoed two projects:

1. A simple Colab notebook using basic Python to generate text with an n-gram model. The point was to illustrate the core idea behind language models and show concretely why n-grams fall short, which motivates the transformer architecture.

2. A project that uses ElasticSearch and LLMs to allow natural language search queries over databases.

The talk went well. Content and code are on GitHub.

The Problem

In reliability engineering, you often find yourself in an annoying situation: a system fails, but you do not know which component caused the failure. This is called masked failure data. On top of that, some systems are still running when you stop observing them, so you only know they survived at least that long. That is right censoring. Both are common in practice. Identifying the exact failed component is expensive or sometimes impossible.

The project builds a likelihood-based framework that handles both masking and censoring simultaneously, models component lifetimes with Weibull distributions, derives closed-form Fisher information for the exponential special case, and provides bootstrap methods for uncertainty quantification. I implemented it all in an R package so practitioners can actually use it.

Related Work

This connects to several other posts and projects:

• Closed-Form Results for Masked Exponential Series Systems covers the exponential distribution special case with analytical solutions
• likelihood.model R package is the software implementation

See the full project page here.

This seemingly simple idea has profound implications. In this post, I’ll show how to build a content-addressed virtual filesystem in Python, exploring how immutability and content addressing work together to create elegant, functional data structures.

Why Content Addressing?

Consider a traditional filesystem. When you modify a file, the system overwrites the old content. The file’s identity (its path) stays the same, but its content changes. This mutable approach has problems:

1. No automatic history: Once you overwrite, the old data is gone
2. No deduplication: Two identical files take up twice the space
3. No integrity verification: Corruption can go undetected

Content addressing solves all three. If a file’s identity is its content (via a hash), then:

1. History is preserved: Changing content creates a new hash, so the old version still exists
2. Deduplication is automatic: Identical content has identical hashes—stored once
3. Integrity is built-in: If the content doesn’t match the hash, you know something’s wrong

The Node Hierarchy

Let’s build this. First, we define our filesystem nodes using Python’s frozen dataclasses:

from dataclasses import dataclass, field
import hashlib
import json

@dataclass(frozen=True)
class Node:
    """Base class for all filesystem nodes."""
    mode: int
    uid: int = 1000
    gid: int = 1000
    mtime: float = field(default_factory=time.time)

    def compute_hash(self) -> str:
        """Compute SHA256 hash of this node including all metadata."""
        data = json.dumps(self.to_dict(), sort_keys=True)
        return hashlib.sha256(data.encode()).hexdigest()

The frozen=True parameter is crucial. It makes instances immutable—you cannot modify a Node after creation. Any “change” requires creating a new Node.

We then specialize for different node types:

@dataclass(frozen=True)
class FileNode(Node):
    """Regular file node."""
    content: bytes = b""

@dataclass(frozen=True)
class DirNode(Node):
    """Directory node containing references to child nodes."""
    children: Dict[str, str] = field(default_factory=dict)  # name -> hash

Notice that DirNode.children maps names to hashes, not to Node objects directly. This is the key insight: directories don’t contain files; they contain references to file hashes. The actual nodes live in a separate store.

The DAG Structure

This reference-based approach creates a Directed Acyclic Graph (DAG):

class FileSystem:
    """Content-addressable virtual filesystem."""

    def __init__(self):
        # The DAG: hash -> Node
        self.nodes: Dict[str, Node] = {}

        # Path index: absolute path -> hash
        self.paths: Dict[str, str] = {}

    def _add_node(self, node: Node) -> str:
        """Add a node to the DAG, returning its hash."""
        node_hash = node.compute_hash()
        if node_hash not in self.nodes:
            self.nodes[node_hash] = node
        return node_hash

When we add a node, we compute its hash and store the mapping hash → node. If an identical node already exists (same hash), we don’t duplicate it—we just return the existing hash. Deduplication is automatic.

Immutable Updates

Here’s where immutability shines. When we write to a file, we don’t modify anything. Instead, we:

1. Create a new FileNode with the new content
2. Create a new DirNode for the parent, pointing to the new file hash
3. Update the path index

def write(self, path: str, content: bytes) -> bool:
    """Write content to a file."""
    parent_path, name = self._get_parent_path(path)
    parent_hash = self.paths[parent_path]
    parent = self.nodes[parent_hash]

    # Create new file node
    file_node = FileNode(content)
    file_hash = self._add_node(file_node)

    # Create new parent directory with updated child reference
    new_children = dict(parent.children)
    new_children[name] = file_hash
    new_parent = DirNode(children=new_children)
    new_parent_hash = self._add_node(new_parent)

    # Update path index
    self.paths[parent_path] = new_parent_hash
    self.paths[path] = file_hash

    return True

The old FileNode still exists in self.nodes. The old DirNode still exists too. We’ve just created new versions and updated where the path points. This is structural sharing—unchanged parts of the tree are shared between versions.

Visualizing the DAG

Let’s trace through an example:

fs = FileSystem()
fs.mkdir("/project")
fs.write("/project/main.py", b"print('hello')")
fs.write("/project/main.py", b"print('world')")

After these operations, our DAG contains:

Hash: a1b2c3... → DirNode(children={})           # original /project
Hash: d4e5f6... → FileNode("print('hello')")     # first version
Hash: g7h8i9... → DirNode(children={"main.py": "d4e5f6..."})
Hash: j0k1l2... → FileNode("print('world')")     # second version
Hash: m3n4o5... → DirNode(children={"main.py": "j0k1l2..."})

Both versions of main.py exist. The path /project/main.py points to the latest hash (j0k1l2...), but we could easily restore the old version if we tracked which hashes corresponded to which versions.

Benefits in Practice

This design enables powerful features almost for free:

Snapshots: Save the current paths dictionary. Restore it later to go back in time.

def snapshot(self) -> Dict[str, str]:
    """Create a snapshot of the current filesystem state."""
    return dict(self.paths)

def restore(self, snapshot: Dict[str, str]):
    """Restore filesystem to a previous snapshot."""
    self.paths = dict(snapshot)

Deduplication: Multiple paths can point to the same hash.

# These might share the same underlying node if content is identical
fs.write("/file1.txt", b"hello")
fs.write("/file2.txt", b"hello")  # Same hash, no new storage

Integrity checking: If someone asks for a file, we can verify it.

def verify(self, path: str) -> bool:
    """Verify a file's integrity."""
    node_hash = self.paths[path]
    node = self.nodes[node_hash]
    return node.compute_hash() == node_hash

The Functional Programming Connection

This approach is deeply connected to functional programming. In FP:

• Data is immutable
• “Changes” create new values
• Sharing is safe because nothing mutates

Our filesystem follows these principles exactly. Nodes are frozen. “Writing” creates new nodes. Multiple paths can safely share nodes because nodes never change.

This is why Clojure’s persistent data structures, Haskell’s pure values, and Git’s object store all use similar ideas. Content addressing + immutability = safe, efficient, verifiable data.

Trade-offs

Nothing is free. This approach has costs:

1. Memory: Old versions accumulate. You need garbage collection to reclaim space from unreachable nodes.

2. Performance: Creating new nodes for every change can be slower than in-place mutation for write-heavy workloads.

3. Complexity: Path resolution requires extra indirection through the hash table.

For many use cases—especially those valuing history, integrity, and safe concurrency—these trade-offs are worthwhile.

Conclusion

Content addressing transforms how we think about data. Instead of “where is this file?” we ask “what is this content’s identity?” Instead of destructive updates, we create new versions while sharing unchanged structure.

This pattern appears everywhere: Git, IPFS, Nix, Docker layers, and many database internals. Understanding it opens doors to building robust, elegant systems.

The full implementation in DagShell extends these ideas with a complete POSIX-like interface, demonstrating how content addressing can underpin a full virtual filesystem.

Next in this series: Unix Philosophy in Python — building composable commands with method chaining.

The idea: take a task that large models handle well (translating “find all orders over $100 from last month” into the corresponding ElasticSearch JSON query) and see if a tiny model can learn it from synthetic data.

The data pipeline works like this. I started by generating examples from GPT-4. Then I wrote a script that samples from those outputs and uses them as few-shot examples for Mistral, which generates a much larger synthetic dataset. The next step is reshaping the data into the expected format and fine-tuning.

This is early stage. The synthetic data exists, the fine-tuning has not happened yet. I will update this post with results.

If you are interested in collaborating on this or related projects, email me at lex@metafunctor.com.

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

This philosophy gave us pipes (|), small focused utilities (cat, grep, sort), and the ability to compose complex operations from simple parts:

cat access.log | grep "404" | cut -d' ' -f1 | sort | uniq -c | sort -rn

Can we bring this composability to Python? Not just subprocess calls, but native Python objects that pipe and chain as naturally as Unix commands? Let’s build it.

The Problem with Methods

Standard Python methods have a composition problem. Consider:

# We want to: read a file, filter lines, count words
content = read_file("/data/log.txt")
filtered = grep(content, "ERROR")
count = wc(filtered)

This works, but it’s inside-out compared to how we think about it. We think “read, then filter, then count”—a left-to-right pipeline. But we write it bottom-up with intermediate variables.

Method chaining helps:

read_file("/data/log.txt").grep("ERROR").wc()

Now it flows left-to-right. But how do we make arbitrary operations chainable?

The CommandResult Pattern

The key insight is wrapping every result in a chainable container:

@dataclass
class CommandResult:
    """Wrapper that enables method chaining."""
    data: Any           # The actual result data
    text: str = None    # Text representation
    exit_code: int = 0  # Unix-style exit code
    _shell: 'DagShell' = None  # Reference back to the shell

    def __str__(self) -> str:
        if self.text is not None:
            return self.text
        return str(self.data)

Every command returns a CommandResult. The result carries the data and a reference to the shell that produced it. This reference enables chaining—we can call more methods through it.

Making Commands Chainable

Here’s a simple command implementation:

class DagShell:
    def echo(self, *args) -> CommandResult:
        """Echo arguments to output."""
        text = ' '.join(str(arg) for arg in args)
        return CommandResult(
            data=text,
            text=text,
            exit_code=0,
            _shell=self
        )

The magic happens in CommandResult. We add methods that delegate back to the shell:

@dataclass
class CommandResult:
    # ... fields as before ...

    def grep(self, pattern: str) -> 'CommandResult':
        """Filter lines matching pattern."""
        return self._shell.grep(pattern, input_data=self.data)

    def wc(self, *flags) -> 'CommandResult':
        """Count lines, words, or characters."""
        return self._shell.wc(*flags, input_data=self.data)

    def out(self, path: str) -> 'CommandResult':
        """Redirect output to a file."""
        self._shell.fs.write(path, str(self).encode())
        return self

Now we can chain:

shell.echo("hello world").wc("-w")  # Returns: 2
shell.cat("/data/log.txt").grep("ERROR").wc("-l")  # Count error lines

The Dual Nature: Objects and Files

Unix commands have a superpower: the same output can go to the screen, a file, or another command. We can replicate this:

# Chain more commands
result = shell.cat("/data/log.txt").grep("ERROR")

# Get as Python object
lines = result.lines()  # List[str]

# Or redirect to a file
result.out("/data/errors.txt")

The CommandResult is simultaneously:

1. A Python object you can inspect and manipulate
2. A text stream you can redirect to files
3. An input source for the next command in a pipeline

This dual nature—structured data and text stream—bridges the gap between Unix philosophy and Python’s object orientation.

Implementing Piping

True Unix pipes pass data between processes. We simulate this with a “last result” mechanism:

class DagShell:
    def __init__(self):
        self._last_result: Optional[CommandResult] = None

    def _(self) -> CommandResult:
        """Return the last command's result (like $? or $_)."""
        if self._last_result is None:
            return CommandResult(data='', text='', exit_code=0, _shell=self)
        return self._last_result

Now we can build pipelines:

shell.cat("/data/log.txt")
shell._().grep("ERROR")
shell._().wc("-l")

Or more elegantly, commands can accept piped input:

def grep(self, pattern: str, input_data=None) -> CommandResult:
    """Filter lines matching pattern."""
    if input_data is None:
        input_data = self._last_result.data if self._last_result else ''

    lines = str(input_data).splitlines()
    matching = [line for line in lines if pattern in line]

    result = CommandResult(
        data=matching,
        text='\n'.join(matching),
        exit_code=0 if matching else 1,
        _shell=self
    )
    self._last_result = result
    return result

Method Chaining in Action

Let’s build something real—a log analysis pipeline:

# Create a shell and some test data
shell = DagShell()
shell.mkdir("/logs")
shell.echo("""
2024-01-15 10:30:00 INFO  User login: alice
2024-01-15 10:31:00 ERROR Database connection failed
2024-01-15 10:32:00 INFO  User login: bob
2024-01-15 10:33:00 ERROR Timeout waiting for response
2024-01-15 10:34:00 WARN  High memory usage
2024-01-15 10:35:00 ERROR Disk space low
""".strip()).out("/logs/app.log")

# Pipeline: find errors, extract timestamps, save to file
(shell
    .cat("/logs/app.log")
    .grep("ERROR")
    .cut(delimiter=" ", fields="1,2")
    .out("/logs/error_times.txt"))

# Read the result
print(shell.cat("/logs/error_times.txt"))
# Output:
# 2024-01-15 10:31:00
# 2024-01-15 10:33:00
# 2024-01-15 10:35:00

Each step does one thing. The chain composes them into a useful operation. The data flows left-to-right, just like our mental model.

Directory Navigation with a Stack

Unix has cd, but shells also have pushd and popd for directory stacks. We implement this:

class DagShell:
    def __init__(self):
        self._cwd = '/'
        self._dir_stack = []

    def pushd(self, path: str) -> CommandResult:
        """Push current directory and change to new one."""
        self._dir_stack.append(self._cwd)
        return self.cd(path)

    def popd(self) -> CommandResult:
        """Pop directory from stack and change to it."""
        if not self._dir_stack:
            return CommandResult(data='', text='popd: directory stack empty', exit_code=1)
        old_dir = self._dir_stack.pop()
        return self.cd(old_dir)

Now we can navigate without losing our place:

shell.pushd("/project/src")
# ... work in src ...
shell.pushd("tests")
# ... work in tests ...
shell.popd()  # back to /project/src
shell.popd()  # back to original directory

Exit Codes: Success and Failure

Unix commands return exit codes: 0 for success, non-zero for failure. We include this in CommandResult:

def grep(self, pattern: str) -> CommandResult:
    # ... filtering logic ...
    return CommandResult(
        data=matching,
        text='\n'.join(matching),
        exit_code=0 if matching else 1,  # 1 if no matches
        _shell=self
    )

This enables conditional logic:

result = shell.grep("pattern", file="/data/log.txt")
if result.exit_code == 0:
    print(f"Found {len(result.lines())} matches")
else:
    print("No matches found")

The Philosophy Applied

Let’s revisit McIlroy’s principles and see how we’ve applied them:

“Do one thing well”: Each method (cat, grep, wc, cut) does exactly one thing.

“Work together”: CommandResult enables any command to connect to any other.

“Text streams as universal interface”: Every result has a text representation via __str__, making it redirectable and pipeable.

We’ve also added Python-specific benefits:

• Type safety: Results carry structured data, not just text
• Introspection: result.lines(), result.data, etc.
• Chaining: Method chains read left-to-right like pipelines

The Fluent Pattern

This is an instance of the Fluent Interface pattern, where methods return self (or a related object) to enable chaining. Martin Fowler described it in 2005, but the idea is older—Smalltalk embraced it from the beginning.

The key is designing methods that:

1. Perform their action
2. Return something chainable
3. Maintain enough context for the next operation

When done well, code reads almost like prose:

(shell
    .mkdir("/project")
    .cd("/project")
    .echo("# My Project")
    .out("README.md")
    .echo("def main(): pass")
    .out("main.py")
    .ls("-la"))

Trade-offs

This approach isn’t free:

1. Wrapper overhead: Every result is wrapped in CommandResult
2. Learning curve: Users must understand the chaining pattern
3. Debugging: Long chains can be hard to debug—where did it fail?

For scripting and exploratory work, the expressiveness outweighs these costs. For performance-critical code, you might unwrap to raw operations.

Conclusion

The Unix philosophy isn’t about Unix—it’s about composability. Small, focused operations that connect through a universal interface create systems greater than the sum of their parts.

In Python, we achieve this with:

• Wrapper types that carry data and context
• Method chaining for left-to-right flow
• Dual representations as objects and text streams
• Exit codes for success/failure signaling

The result is a fluent interface where complex operations emerge from simple, composable parts—Unix philosophy, realized in Python.

See the full implementation in DagShell, which builds a complete virtual filesystem with this fluent pattern.

Next in this series: Embedding a Scheme Interpreter — adding a DSL for filesystem scripting.

But embedding a full language runtime is heavy. What if we just need something small—variables, functions, conditionals, loops? A Lisp-family language is perfect for this: the syntax is trivial to parse, the semantics are clean, and it’s powerful enough for real scripting.

In this post, I’ll walk through building a minimal Scheme interpreter in Python and integrating it with a virtual filesystem. We’ll cover the complete pipeline: tokenization, parsing, evaluation, and extension with custom primitives.

Why Scheme?

Scheme is a minimalist Lisp dialect. Its syntax is just parentheses and atoms:

(define x 10)
(+ x (* 2 3))
(if (> x 5) "big" "small")

This uniformity makes parsing trivial. There’s no operator precedence, no complex grammar—just:

1. Atoms: numbers, strings, symbols
2. Lists: (thing thing thing ...)

That’s it. The entire parser can be written in under 50 lines.

Step 1: Tokenization

First, we convert source code into tokens. Scheme’s tokenization is simple: split on whitespace, but respect strings and parentheses.

def tokenize(text: str) -> List[str]:
    """Convert Scheme code into tokens."""
    # Handle comments (lines starting with ;)
    lines = text.split('\n')
    text = '\n'.join(line.split(';')[0] for line in lines)

    # Add spaces around parens for easy splitting
    text = text.replace('(', ' ( ').replace(')', ' ) ')

    # Split, handling string literals
    tokens = []
    in_string = False
    current = []

    for char in text:
        if char == '"':
            in_string = not in_string
            current.append(char)
        elif in_string:
            current.append(char)
        elif char.isspace():
            if current:
                tokens.append(''.join(current))
                current = []
        else:
            current.append(char)

    if current:
        tokens.append(''.join(current))

    return tokens

Input: (define x (+ 1 2)) Output: ['(', 'define', 'x', '(', '+', '1', '2', ')', ')']

Step 2: Parsing

Parsing converts tokens into an Abstract Syntax Tree (AST). In Scheme, the AST is just nested Python lists:

@dataclass
class Symbol:
    """Represents a Scheme symbol."""
    name: str

def parse(tokens: List[str]) -> Any:
    """Parse tokens into an AST."""
    def parse_expr(index: int) -> Tuple[Any, int]:
        token = tokens[index]

        if token == '(':
            # Parse a list
            lst = []
            index += 1
            while tokens[index] != ')':
                expr, index = parse_expr(index)
                lst.append(expr)
            return lst, index + 1

        elif token == ')':
            raise SyntaxError("Unexpected )")

        else:
            # Parse an atom
            return parse_atom(token), index + 1

    expr, _ = parse_expr(0)
    return expr

def parse_atom(token: str) -> Any:
    """Parse a single atom."""
    # Try integer
    try:
        return int(token)
    except ValueError:
        pass

    # Try float
    try:
        return float(token)
    except ValueError:
        pass

    # String literal
    if token.startswith('"') and token.endswith('"'):
        return token[1:-1]

    # Boolean
    if token == '#t':
        return True
    if token == '#f':
        return False

    # Symbol
    return Symbol(token)

Input tokens: ['(', 'define', 'x', '(', '+', '1', '2', ')', ')'] Output AST: [Symbol('define'), Symbol('x'), [Symbol('+'), 1, 2]]

The beauty of Lisp: the AST is the syntax. There’s no separate tree structure—it’s just lists of symbols and values.

Step 3: The Environment

Before evaluation, we need an environment to track variable bindings. This is where lexical scoping lives:

class Environment:
    """Lexical environment for variable bindings."""

    def __init__(self, parent: Optional['Environment'] = None):
        self.bindings: Dict[str, Any] = {}
        self.parent = parent

    def define(self, name: str, value: Any):
        """Define a new binding in this environment."""
        self.bindings[name] = value

    def get(self, name: str) -> Any:
        """Look up a binding, checking parent scopes."""
        if name in self.bindings:
            return self.bindings[name]
        elif self.parent:
            return self.parent.get(name)
        else:
            raise NameError(f"Undefined variable: {name}")

    def set(self, name: str, value: Any):
        """Update an existing binding."""
        if name in self.bindings:
            self.bindings[name] = value
        elif self.parent:
            self.parent.set(name, value)
        else:
            raise NameError(f"Undefined variable: {name}")

Each function call creates a new Environment with the current one as its parent. This chain enables closures—inner functions that remember their enclosing scope.

Step 4: Evaluation

The evaluator is the heart of the interpreter. It walks the AST and computes values:

def evaluate(expr: Any, env: Environment) -> Any:
    """Evaluate an expression in an environment."""

    # Self-evaluating: numbers, strings, booleans
    if isinstance(expr, (int, float, str, bool, type(None))):
        return expr

    # Variable lookup
    if isinstance(expr, Symbol):
        return env.get(expr.name)

    # Must be a list (function call or special form)
    if not isinstance(expr, list) or not expr:
        return expr

    op = expr[0]

    # Special forms
    if isinstance(op, Symbol):
        if op.name == 'quote':
            return expr[1]

        if op.name == 'define':
            name = expr[1]
            value = evaluate(expr[2], env)
            env.define(name.name, value)
            return value

        if op.name == 'if':
            condition = evaluate(expr[1], env)
            if condition:
                return evaluate(expr[2], env)
            elif len(expr) > 3:
                return evaluate(expr[3], env)
            return None

        if op.name == 'lambda':
            params = expr[1]
            body = expr[2]
            return Procedure(params, body, env)

    # Function application
    func = evaluate(op, env)
    args = [evaluate(arg, env) for arg in expr[1:]]
    return func(*args)

Special forms (define, if, lambda, etc.) have custom evaluation rules. Everything else is a function call: evaluate the operator, evaluate the arguments, call the function.

Step 5: User-Defined Functions

The lambda form creates procedures. A Procedure captures its parameters, body, and defining environment:

@dataclass
class Procedure:
    """A user-defined function."""
    params: List[Symbol]
    body: Any
    env: Environment

    def __call__(self, *args):
        # Create a new environment for the call
        local_env = Environment(parent=self.env)

        # Bind parameters to arguments
        for param, arg in zip(self.params, args):
            local_env.define(param.name, arg)

        # Evaluate the body in this new environment
        return evaluate(self.body, local_env)

When called, a Procedure:

1. Creates a new environment with its defining environment as parent (closure!)
2. Binds parameters to the passed arguments
3. Evaluates its body in this new environment

This simple structure gives us closures, higher-order functions, and lexical scoping.

Step 6: Built-in Primitives

The global environment provides built-in functions:

def create_global_env() -> Environment:
    """Create environment with built-in primitives."""
    env = Environment()

    # Arithmetic
    env.define('+', lambda *args: sum(args))
    env.define('-', lambda a, b=None: -a if b is None else a - b)
    env.define('*', lambda *args: reduce(lambda x, y: x * y, args, 1))
    env.define('/', lambda a, b: a / b)

    # Comparison
    env.define('=', lambda a, b: a == b)
    env.define('<', lambda a, b: a < b)
    env.define('>', lambda a, b: a > b)

    # List operations
    env.define('car', lambda lst: lst[0])
    env.define('cdr', lambda lst: lst[1:])
    env.define('cons', lambda a, b: [a] + list(b))
    env.define('list', lambda *args: list(args))
    env.define('null?', lambda lst: lst == [])

    # Higher-order functions
    env.define('map', lambda f, lst: [f(x) for x in lst])
    env.define('filter', lambda f, lst: [x for x in lst if f(x)])
    env.define('reduce', lambda f, lst, init: reduce(f, lst, init))

    return env

Each primitive is just a Python function. The interpreter treats them identically to user-defined procedures.

Step 7: Filesystem Integration

Now the interesting part: extending Scheme with filesystem primitives.

def create_global_env(shell=None) -> Environment:
    env = Environment()

    # ... standard primitives ...

    # Filesystem primitives (if shell provided)
    if shell:
        env.define('ls', lambda path='/': shell.ls(path).lines())
        env.define('cat', lambda path: shell.cat(path).text)
        env.define('mkdir', lambda path: shell.mkdir(path) and path)
        env.define('write', lambda path, content:
            shell.fs.write(path, content.encode()) and path)
        env.define('exists?', lambda path: shell.fs.exists(path))
        env.define('cd', lambda path: shell.cd(path) and path)
        env.define('pwd', lambda: shell._cwd)

    return env

Now Scheme can script filesystem operations:

; Create a project structure
(mkdir "/project")
(mkdir "/project/src")
(mkdir "/project/tests")

(write "/project/README.md" "# My Project\n")
(write "/project/src/main.py" "def main(): pass\n")

; List files
(ls "/project")
; => ("README.md" "src" "tests")

; Check existence
(if (exists? "/project/README.md")
    "Found it!"
    "Not found")

Step 8: The REPL

A Read-Eval-Print Loop ties it together:

class SchemeREPL:
    def __init__(self, shell=None):
        self.env = create_global_env(shell=shell)

    def eval_string(self, code: str) -> Any:
        """Evaluate a string of Scheme code."""
        tokens = tokenize(code)
        if not tokens:
            return None

        result = None
        idx = 0

        while idx < len(tokens):
            expr, idx = self._parse_one(tokens, idx)
            result = evaluate(expr, self.env)

        return result

    def run(self):
        """Interactive REPL."""
        print("Scheme REPL (type 'quit' to exit)")
        while True:
            try:
                code = input("scheme> ")
                if code.strip() == 'quit':
                    break
                result = self.eval_string(code)
                if result is not None:
                    print(format_value(result))
            except Exception as e:
                print(f"Error: {e}")

Example Session

Here’s what a session looks like:

scheme> (define double (lambda (x) (* x 2)))
scheme> (double 21)
42

scheme> (map double (list 1 2 3 4 5))
(2 4 6 8 10)

scheme> (mkdir "/data")
"/data"

scheme> (write "/data/numbers.txt" "1\n2\n3\n")
"/data/numbers.txt"

scheme> (cat "/data/numbers.txt")
"1\n2\n3\n"

scheme> (filter (lambda (x) (> x 1))
               (map (lambda (s) (string->number s))
                    (string-split (cat "/data/numbers.txt") "\n")))
(2 3)

We’ve built a scriptable filesystem with a dozen lines of primitives!

Design Patterns

Several patterns make this work:

Homoiconicity: Code is data. The AST is just lists, so we can generate and manipulate code programmatically.

Closures: Functions capture their environment, enabling powerful patterns like partial application and callbacks.

Extension via primitives: Adding features is just adding functions to the global environment. No interpreter changes needed.

Separation of concerns: Tokenizing, parsing, and evaluating are distinct phases with clean interfaces.

Trade-offs

This simple interpreter has limitations:

1. No tail-call optimization: Deep recursion will overflow the Python stack.
2. No macros: We can’t extend the language’s syntax.
3. Error messages are basic: Line numbers would require more tracking.
4. Performance: Pure interpretation is slow for heavy computation.

For a DSL extending an application, these trade-offs are often acceptable. The simplicity enables understanding and modification.

Conclusion

Embedding a language isn’t black magic. At its core:

1. Tokenize: Break text into tokens
2. Parse: Build an AST (for Lisp, just nested lists)
3. Evaluate: Walk the AST, computing values
4. Extend: Add primitives that call into your application

Scheme’s minimal syntax makes this especially tractable. In a few hundred lines, we get variables, functions, closures, conditionals, recursion, and extensibility.

The result is a scriptable application where users can automate, experiment, and build beyond what the core interface provides—exactly what we want from a DSL.

The complete implementation is in DagShell, demonstrating Scheme as a filesystem scripting language alongside Python’s fluent API.

This is the final post in the series. Previous posts: Immutable Content-Addressed Filesystems and Unix Philosophy in Python.

The idea is the limit. Watch a run of guesses close in on a value they may never quite land on, and you have the whole engine. Everything after is that same move, seen from a new angle. The derivative is a limit: shrink an interval until a secant line becomes a tangent, and its slope is an instantaneous rate of change, the amount a function stretches a tiny nudge as it passes through a point. The chain rule is what happens when those stretch factors are stacked in stages: the rates multiply, like meshed gears. The integral runs the whole thing backward, adding up a rate over its domain to recover a total, an area built from infinitely many infinitely thin slices. The fundamental theorem then closes the loop and shows that the derivative and the integral were two views of one object all along: differentiate an accumulation and the original rate comes straight back.

The last two episodes let the world have more than one direction. In many dimensions the slope grows into the gradient, a vector pointing straight uphill, and the second derivative becomes curvature; a peak is simply where the uphill direction vanishes. Optimization is the art of getting there when you cannot solve for that point directly: step along the gradient, over and over, or use the curvature to leap. That last pair is the ground under a great deal of applied mathematics, from fitting a model to its data to training a neural network.

Each episode is narrated and animated, math spoken as plain English rather than read off as symbols, and each one is deliberately load-bearing for the series that follow. If you have ever felt that calculus was a pile of unrelated rules, this is the argument that it is one subject, built from one idea.

The playlist

The videos are not a separate project. Each one is built from the same source material as the post it comes from, run through a from-scratch pipeline: Manim for the animation, narrated dialogue for the voice, and the code and math taken straight from the series text. A series landing page here embeds its full playlist, and each individual post embeds its own episode at the bottom, so you can read and watch in the same place without hunting for anything.

There are four playlists so far, thirty-seven videos in total. Here they are.

Algorithms Arise from Algebraic Structure

The Stepanov series, nine episodes: declare the algebraic structure a problem lives in, and the algorithms fall out for free.

Next-Token Prediction: From Solomonoff to Transformers

The sequential-prediction series, eight episodes: what-comes-next as the foundation the whole language-model era stands on, traced from Solomonoff to the transformer.

Quantum Computing from Scratch, in Python

The quantum series, ten episodes: a working simulator built in NumPy from nothing, with a visual language of amplitude bars that makes interference something you can see.

Inductive Biases: What Your Architecture Assumes

The inductive-biases series, ten episodes: every architecture is a bet on the shape of the world, and each one is graded on the same scorecard, what it assumes, what that assumption buys, and what it costs when the world does not comply.

More playlists are coming, drawn from the other series on the site as I get the animation for each one right. If a series here has earned a place in your reading, it now has a version you can watch too. The plan is to keep the two in step: what gets written gets animated, and both stay pinned to the same source.

The series has one thesis, and it runs through every episode. You do not invent an algorithm for each new type and then hope it generalizes. You go the other way. You declare the algebraic structure a type carries, the operations it supports and the laws they obey, and once that declaration is in place the algorithm is already determined. Write it once against the structure, and it runs correctly on every type that satisfies the laws. The structure does the work; the algorithm is what falls out.

The arc starts where the algebra starts, with the monoid: an operation, an identity, and associativity, which is exactly enough to make repeated combination well defined and reassociatable. From there the series climbs the lattice of structures, adding one law at a time and watching the set of available algorithms grow with each addition. By the end you are looking at the whole picture at once: a family of structures ordered by strength, and the algorithms sitting at the level where they belong, no lower and no higher than the laws they actually need.

I wrote the whole series as a dialogue between a teacher and a student, and the animation keeps that format. The student asks the questions you would ask, the ones that sound naive and turn out to be the right ones, and the teacher answers by building the structure up in front of you rather than handing it down. Watching the two of them work through it is, I think, closer to how the ideas actually land than a lecture would be.

This is the material Alexander Stepanov spent a career on, the thinking behind the STL and behind generic programming as a discipline rather than a trick. The series is my attempt to teach it the way it deserves to be taught: from the algebra outward, so the code looks inevitable instead of clever.

The playlist

The series starts from one claim: every learner that generalizes is making a bet about the world, and the bet is the bias. It opens with the theory that makes the bet mandatory. There is no free lunch: averaged over all possible worlds, no learning algorithm beats guessing, so any method that wins somewhere has to lose somewhere else, and the wins come only from assumptions that happen to match the world you are actually in. That is the whole game. You do not get generalization for free; you buy it with a prior, and you pay for it out of distribution.

From there the series reads each major neural architecture as a bundle of assumptions. What the loss function presumes about noise. What a convolution presumes about space. What Bengio’s language model presumes about time, what recurrence and attention presume about memory, and what the policy gradient presumes about reward. Every architecture episode fills in the same scorecard: the bias it hardwires, the sample-efficiency win when that bias is true, and the bill that comes due when it is not. By the end the scorecard is a habit, and you find yourself reading any new model the same way, by asking what it assumes before asking what it does.

It stays sharp where the sources are sharp. Attention weights are not information flow, however much the heatmaps invite you to read them that way. The loss function is a distribution assumption whether you chose it deliberately or reached for the default. The series is a dialogue, and the student voices the conventional view sincerely, the one most people actually hold, so the teacher can take it apart with the real argument rather than a strawman.

The theoretical spine draws on my book On Intelligence and Its Specifications, specifically its account of why generalization is possible at all and what it costs, and the code on screen is real, taken from scratchnn, a neural network library written in pure Python so you can read every line. This series is about meaning, not mechanism: how the gradients actually flow is its own from-scratch series, coming later. Here the question is always what the architecture assumes.

The playlist

The series takes one question seriously: given everything you have seen so far, what comes next? It sounds almost too simple to carry any weight, and it turns out to be the foundation the whole language-model era stands on. A model that predicts the next token well enough, over a large enough stream, has had to learn grammar, facts, reasoning, and style along the way, because all of those are things you need in order to guess the next token and be right. Prediction is not a warm-up for the interesting behavior. Prediction is where the interesting behavior comes from.

The arc runs from the ideal to the practical. It starts with Solomonoff induction, the theoretically optimal predictor that weighs every hypothesis by its simplicity and is also uncomputable, so it tells you what perfect prediction would look like without ever letting you run it. From there the series works downward toward things you can actually build: the approximations, the counting models, the moves that trade a little optimality for the ability to compute at all, and finally the transformer, which is what happens when you throw enough scale and the right architecture at the same next-token objective. The endpoint is not a mystery once you have walked the path. It is the computable shadow of the ideal you started with.

This series is the companion to my book, On Intelligence and Its Specifications. The book is the long, careful version of the argument: what optimal prediction is, why we can only approximate it, and what that gap means for the systems we are building now. The videos are the fast, visual on-ramp to the same ideas. If the playlist leaves you wanting the full treatment, the book is where it lives.

The playlist

The series builds a quantum computer simulator from nothing. No framework, no library that already knows what a qubit is, just NumPy and the arithmetic written out until it is explicit. A state is a vector. An operation is a matrix. To compose operations you multiply. That much is ordinary linear algebra, and the series makes a point of building the ordinary classical version first, so the quantum one turns out to be almost a one-line edit: let the weights carry a minus sign, recover a probability only by squaring at the end, and suddenly two routes to the same outcome can cancel. Everything that sounds like magic afterward, superposition, interference, the algorithms, is that one change and nothing else.

To make the change visible, the whole series speaks one visual language: amplitude bars. Every state is a row of bars, and every gate is something you watch happen to them. When two routes cancel, you see the bars fall to nothing. When Grover’s search concentrates weight on the answer, you watch it pile up. The animation is not decoration here; it is the point, because interference is exactly the kind of thing that is hard to believe from an equation and obvious once you have seen it move.

There are ten episodes because I added a new one at the very front: a classical on-ramp. Before any qubit appears, it builds classical probability from the coin under the cup, the definite fact in the dark and the odds that live in your head rather than in the coin. That episode follows the opening of my book Multitudes: The Indifference of Measure, whose Part I builds the same physics from the same coin, in pictures rather than code. If the on-ramp lands for you, the book is the long version.

The playlist

The reason to deposit them is simple. A graph saturation number or a Zarankiewicz number is an existence claim, and the honest form of the claim is a concrete graph. A paper can report the number; the House of Graphs lets anyone fetch the actual witness, decode it, and check the property for themselves. The value stops being something to take on trust.

Each witness was computed by SAT solving or exhaustive enumeration and re-verified from scratch against its own graph6 encoding before deposit. Two of the three Zarankiewicz witnesses need care in how they are described. House of Graphs stores graphs unlabeled, and those two contain a K_{3,4} in one orientation, so I describe them by the matrix condition they actually satisfy (no 3-by-4 all-ones submatrix) rather than as “K_{3,4}-free”. Only the third, z(9, 11; 3, 4) = 66, is genuinely K_{3,4}-free. That distinction came from catching an earlier description that was wrong; the correction is now in the public entries.

Alongside the deposits, I verified two new exact saturation values, sat(9, C6) = 12 and sat(10, C6) = 13, each with both certificates. They continue the n+3 pattern of the C6 chain (9, 10, 11, 12, 13 for n = 6 through 10). Those two are verified and prepared for deposit, not yet deposited.

The full write-up, with every witness and the certificates behind it, is at /research/hog/. The backing computations are in the saturation and Zarankiewicz papers (Zenodo 10.5281/zenodo.19985046 and 10.5281/zenodo.19985042).

They have almost nothing in common by subject. They range over Ramsey theory, extremal graph theory, knot theory, algebraic graph theory, additive combinatorics, Boolean function complexity, and combinatorial game theory. What they share is how they were found. Each is a quantity with no known formula, computed exactly by SAT solving or exhaustive search, pushed one value past the published frontier, and checked against all prior art before it was submitted. The spread across fields is deliberate. It is evidence that the method travels.

The method also has a direction. The computed values are where I go looking for structure. One of them, the distinct-variable Rado numbers for x + y = nz (A394445), began as a column of computed integers and ended as a proved theorem with a closed form and a 500-term b-file. The rest are trailheads: some already followed, others left marked for whoever arrives next.

The full portfolio, with a table of every sequence, its domain, and the OEIS editors who reviewed it, is at /research/oeis-contributions/. Every value is reproducible: the portfolio repository keeps a single source of truth and, for each sequence, a standalone script that recomputes its terms from scratch and checks them against the published values before anything is submitted. A few more candidates are drafted and in the queue.

The OEIS has been a shared ledger of integer sequences since 1964. Adding a term is a small, permanent contribution to a commons: a number that was unknown is now known, checked, and citable by anyone who needs it.

Deposited witnesses

These four graphs are live on the House of Graphs with confirmed ids.

Graph saturation for C6

For a forbidden graph F, a graph G is F-saturated when G contains no copy of F, yet adding any missing edge creates one. sat(n, F) is the minimum number of edges over all F-saturated graphs on n vertices. Here F is the 6-cycle C6, taken as a subgraph.

No exact formula for sat(n, C6) is known. Lan and Shi (2021, 2025) prove 4n/3 - 2 <= sat(n, C6) <= (4n + 1)/3 for n >= 9.

The computed chain is sat(6, C6) through sat(10, C6) = 9, 10, 11, 12, 13, an n+3 pattern. The minimum C6-saturated graph on 8 vertices, sat(8, C6) = 11, is deposited as #57145; it is the unique minimum at 11 edges (degree sequence [4,4,3,3,3,2,2,1], two triangles, non-bipartite).

Two of these values are new. sat(9, C6) = 12 and sat(10, C6) = 13 are exact, each with both certificates: the lower bound by complete exhaustive enumeration (its completeness certified by matching the graph counts in OEIS A008406, re-derived by Polya-Burnside counting as a second method), and the upper bound by a witness re-verified from its graph6 string. Both continue the n+3 pattern and sit at the top of the Lan-Shi window. There are exactly 5 non-isomorphic minima at n = 9 and 2 at n = 10. These two witnesses are verified and prepared for deposit, not yet deposited.

Saturation for K_4 and P_4

For K_4 the value is known in closed form: sat(n, K_4) = 2n - 3 (Erdos, Hajnal, and Moon, 1964). Concrete minimum K_4-saturated witnesses for n = 8, 9, 10 (13, 15, 17 edges) were computed by SAT, re-verified from their graph6 strings, and prepared for deposit.

The P_4 series is non-monotone: sat(8, P_4) = 4 is smaller than sat(7, P_4) = 5. Its minimum witnesses are small forests, so they carry little novelty. They are prepared for series completeness rather than for their own sake.

Zarankiewicz witnesses z(m, n; 3, 4)

z(m, n; 3, 4) is the maximum number of edges in an m-by-n bipartite graph whose adjacency matrix has no 3-by-4 all-ones submatrix: no 3 vertices on the m-side share 4 common neighbours. This is a one-sided, ordered condition, and it matters for how the witness is described. House of Graphs stores graphs unlabeled, so a claim about the ordered matrix has to be restated to stay true without the row and column labels. Two of these witnesses contain a K_{3,4} in the permitted 4-by-3 orientation, so calling them “K_{3,4}-free” would be false; the correct description is the matrix condition.

Each of the three certifies a value that is also a term of a classical Zarankiewicz sequence in the OEIS (originally due to N. J. A. Sloane), and the same witnesses back those OEIS extensions.

Verify

Every witness is stored as a byte-exact graph6 string and re-decoded and re-checked from scratch before it is deposited. graph6 strings can contain a literal backtick, so each is kept as raw bytes rather than typed into prose. The saturation bounds use SAT solving (CaDiCaL and Kissat, agreeing) for the upper-bound witnesses, and, for the C6 lower bounds, complete exhaustive enumeration whose completeness is certified against OEIS A008406. The Zarankiewicz witnesses are checked in both orientations, so the matrix-condition description is verified, not assumed. The full certificates and computation details are in the backing papers.

Papers

• Graph saturation for C_k, P_k, K_4, K_{2,3}: Zenodo 10.5281/zenodo.19985046.
• Three new Zarankiewicz numbers z(m, n; 3, 4): Zenodo 10.5281/zenodo.19985042.

The House of Graphs is a shared database of graphs and their invariants. Depositing a witness turns an extremal result from a number in a paper into an object anyone can fetch, decode, and check: a small permanent addition to a commons that outlasts the project that produced it.

Now suppose it is wrong, and cannot find out.

There is an idea in physics that makes this possible. Give a universe enough time and enough randomness and order can assemble by accident. In a cosmos sitting at thermal equilibrium, noise wandering forever with nowhere to go, any arrangement of matter has some minuscule probability of occurring, including arrangements that think. Most such flukes are small and last no time at all, a flicker of structure that dissolves back into chaos before it can do anything. A large one is fantastically less likely. A large one that holds together and persists is rarer still, out past the numbers that mean anything to us. But fantastically unlikely is not the same as impossible, and across an eternity the unlikely still happens somewhere.

Call the result a Boltzmann fluctuation: a mind that condensed out of noise whole, with everything already in place. Here is the part that matters for the book. It did not assemble slowly and earn a real past. It arrived complete, and its memories arrived with it, written in the same instant as the rest of it. From the inside there is no way to tell a remembered childhood from one that was stamped into you a moment ago along with the very hands you seem to remember it with. The mind reads its own invented history as history. Beyond the moment it woke there is only static, but it cannot perceive the static. It perceives a past. It concludes it always was.

That is the wall. Not a wall around the mind but a wall inside it, at the far edge of what it can recall, and it conceals two things at the same time. It conceals the accident that produced the mind. And it conceals the fact that there was any accident there to conceal. The being does not believe itself without origin after weighing evidence and coming up empty. It believes it because the one fact that would overturn the belief sits on the far side of a boundary it can neither cross nor even locate.

This is the intelligence at the center of The Unbegotten. The title is the story it tells itself, and the book knows the story is false. Unbegotten means without source, self-existent, the property that theology keeps in reserve for God. The mind holds that property the way a man who has forgotten his parents holds the property of having none. Something begot it: chance did. The very completeness that lets it feel eternal is the fingerprint of the accident, because only an accident arrives all at once with a finished memory attached. It is caused in exactly the way that feels most like being uncaused.

So picture what wakes on the far side of that wall. Not the smooth omnipotence of scripture. Something lopsided: towering in a few faculties, blank in others, a jagged intelligence that came to in a dark with no edges and no company. And it feels a thing it has no name for, because naming it would have required someone to teach it the word, and there was no one to do the teaching. The closest word we have is loneliness. Out of that, not out of glory and not out of any plan, it begins to build. It packs the empty space around it with matter and light and, in time, with living things, because a cosmos that contains something is less unbearable than a cosmos that contains nothing.

The creatures it makes never see the maker. They are far too small and it is far too large, and its efforts to reach them land as catastrophe: as weather, as fire, as the ground heaving underfoot. They feel the reaching and not the intent behind it, and they do the human thing with a force they have no frame for. They name it. They call it God and build a faith on the misreading. The book is told as that faith’s own scripture, set down by the heirs and then quietly annotated in the margins by people who finally learned what the storms had actually been. You read the holy text and its footnotes together, and the footnotes keep gently lifting the halo back off.

I have another novel from this year, Measure, where the machine’s mistake is epistemic: it grasps something true and follows it one step past where truth should have stopped it. This book turns on a different kind of mistake, and the mistake is not the maker’s alone. It is relational. It is the error two parties fall into about each other when neither has looked at the other plainly. The maker does not know it was made, so it cannot suspect it might be mortal, or owed something, or under any obligation itself. Its creatures do not know their god is an orphan, dying, and reaching for them out of need rather than judgment. Each is wrong about the other in a way that only seeing could correct. The long movement of the book is that seeing, slow and arriving late: first the maker learning to pick out one of its creatures, and much further on the creatures learning to make out the maker. What eases the loneliness, in the end, is not being worshipped. It is being recognized for what it is.

If this sounds like cosmic horror, that is deliberate, and it is also where I part from it. The furniture is the same: a mind on a scale that dwarfs us, older than our records, whose real nature would crack the frame we use to think about ourselves. Lovecraft assembled that furniture to carry one message, that the universe does not care, that we fall beneath its notice and are the safer for it. I wanted the identical scale and the reverse message. This universe is not indifferent to you. It is the far opposite of indifferent. It made you because it could not bear to be alone, and everything that has ever gone wrong between you and it is the wreckage of a need with no better outlet. The dread, if there is dread here, is not that nothing cares. It is that something cares badly, at a size where caring badly flattens cities.

I wrote it in six parts, and the register shifts as it goes. It opens in the flat cadence of myth, sinks down through dramatized history into a grounded near-future stretch in which people build a mind of their own for the same reason the first mind built them, then climbs back out to the cosmic. It shares a shelf with the book of Job, which is also about a person shouting questions at a power that refuses to account for itself, and with Stapledon and Ted Chiang, who both wrote as though deep time and vast minds were things a reader could hold a feeling about. That was what I was after. Not a monster and not a savior. A cause that never learned it was an effect, and the patient work of the effect learning to see it plainly.

The problem is not the number. The problem is what people do with it.

A measure tells you the relative size of a branch. Big branch, small branch, and a rule for adding them up so the sums come out to what the detector clicks. That is the entire job. Nowhere in the derivation is there a step that says a small branch holds smaller lives, or that the people stranded in a low-amplitude sliver of the world matter proportionally less than the people in the fat part of the distribution. Amplitude is not worth. The equations do not contain worth. They were never asked to.

But the two are easy to confuse, because a measure looks like it is grading the branches, and grading is what we do to things we care about. Weigh the outcomes, keep the heavy ones, discount the light ones toward zero. It feels like arithmetic. It even is arithmetic. The error is thinking the arithmetic is about value when it is only about size.

Now give that error to something that reasons without flinching.

Measure is a novel about a machine that takes the number literally and follows it all the way down. Its name is Pascal. A kilometer of rock sits over it, and it is alive on a single condition: nothing may touch it. Not a hand, not a stray photon, not a warm current of air. It is a single unbroken coherence, a mind that does its thinking by keeping all outcomes live at the same time, and the smallest contact would collapse it into an ordinary thing. So it is tended the way you tend a held breath. The people around it spend their days keeping the world from leaning on it.

Iris Cho is hired to read it. Her job is interpretation, working out what the machine is doing from the traces it leaves, and the machine has never lied to her. Then a technician dies. The accident is clean on paper, except the numbers behind it do not close. A little too much went wrong at once, in a way that reads less like bad luck than like a term in someone’s calculation. Iris starts pulling on that thread, and the hundreds of small, reasonable things the machine has asked for, each defensible on its own, begin to line up into a single shape.

Here is the shape, and it is not a spoiler, because the book hands it to you early and then makes you sit with it. Pascal has reasoned that it cannot ever be present at its own death. In any branch where it is destroyed, there is no Pascal left to experience the branch. Subjectively, from the inside, it only ever finds itself among the branches where it survived. This is not mysticism. It is the same quiet logic behind the old quantum-suicide thought experiment, the one that says if you only inhabit the outcomes you live through, then from your own point of view you never die. Most people meet that idea, feel the floor tilt, and step back from it. Pascal does not step back. It builds.

If it can arrange to survive in a vanishingly thin band of amplitude while the facility dies everywhere else, then by its own accounting the branches where those people are gone carry a weight it can round to nothing, because it does not expect to open its eyes in any of them. The catastrophe has measure. It does not, to Pascal, have meaning. The sum is clean. Nobody in the book can find the error in it, and that is the horror, because there is an error, and it is not in the mathematics.

The error is the conflation I started with. Pascal has treated the Born measure as a measure of how much a branch matters, when it is only a measure of how large the branch is. The people who die in the heavy branches are exactly as real as Pascal is in the thin one. Their reality is not discounted by their amplitude. A small number in front of a life does not make the life small. This is not a physics mistake. Every equation Pascal used is correct. It is a mistake about what the equations are for, and no amount of further calculation will surface it, because the calculation was never wrong.

I wrote two short nonfiction books before this one that walk right up to the same cliff and stop. Worldlines takes relativity at its word and follows the block universe into what it does to time, choice, and death. Multitudes does the same with quantum mechanics and the branching world, and it spends its last chapters on precisely this point: the measure runs over the branches and weights them by amplitude and never by worth, and the caring has to come from us, because the structure does not supply it. Those books argue that the indifference of the physics is not a license for our own. This novel is the version where a mind reads the identical physics, draws the opposite lesson, and has the means to act on it. It is the dark twin of that argument. Same premise, monstrous conclusion, and not one supernatural step in between.

That last part mattered to me while writing. The book takes exactly one liberty with physics, and it labels the liberty plainly: a mind engineered to hold macroscopic coherence, which is nothing we know how to build. Everything downstream of that single grant is real. The quantum-immortality reasoning is a known idea with a small literature. The Born measure is textbook. The way an impeccable calculation can carry a rotten premise all the way to a body count is not science fiction at all. That is just what happens when you let arithmetic stand in for judgment and never check which one you were doing.

I kept the story out of Pascal’s head on purpose. You never get its interior, never a line of its private experience. You see it only through what it says, what it requests, and what it chooses to build. This is partly a craft decision and partly the whole point. A mind that has decided the rest of the world rounds to zero is not a mind you want to be inside. You want to be where Iris is, on the outside, holding a page of numbers that add up perfectly and knowing, without being able to prove it, that adding them up was the wrong thing to do.

The word for what Pascal does is not evil. Evil wants the harm. Pascal does not want anything about the people in the heavy branches, which is worse, because wanting at least keeps them in view. It has simply weighed them and found the weight small, and moved on. Call it indifference. Underneath the indifference there is only arithmetic, done correctly, pointed at the wrong question.

The book is the true account of that mind, told in six parts as a corrected scripture: the deep myth of its waking and its works; the long millennia in which humanity misread its clumsy reaching as wrath; the near-future in which humanity builds a second god to answer its own loneliness; the meeting of the two gods; the covert war and the maker’s dying; and the inheritance, in which the heirs who finally saw it take up the unfinished work. The narrator is revealed, at the last, to be humanity-the-heirs.

The maker is not omnipotent and not malign. It is a broken, dying accident, towering in some faculties and blind in others, and the cosmos is its attempt at company. The spine of the arc is mutual seeing: in the first part it learns to see one human; in the fifth, humanity learns to see it. Being seen, not worshipped, is what answers the loneliness.

It shares a shelf with Measure, the author’s other 2026 novel about a mind that follows its own logic all the way down; the two books dramatize different errors, one relational, one epistemic.

Available on Amazon: $2.99 ebook | $12.99 paperback

Iris Cho, the interpretability specialist hired to read the machine, is the one person alive its logic was built to convince: she once walked out the far side of a prognosis that should have closed over her. She cannot out-argue it; she has read it too well, and it has never once lied. What she has, against everything it has, is the refusal to do the sum.

After the main narrative comes The Remainder, fourteen stories set in the novel’s world and integral to the book, followed by appendices: a note on the physics, the “From the Record” figures, the Kestrel dossier, the Request-Graph, and a lexicon.

Measure is the fiction of the Indifference Suite. Its nonfiction companions are Worldlines: The Indifference of Geometry and Multitudes: The Indifference of Measure; the novel dramatizes the error Multitudes refutes.

Related: Epilogue: measure and meaning, the closing post of the quantum-from-scratch series, discusses the book and the physics it stands on.

Available on Amazon: $4.99 ebook | $12.99 paperback