---
title: Stage 5
type: reference
tags: :passepartout:roadmap:
created: 2026-05-24
---

← [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]]  → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]

# Stage 5: Weights

*Summary: Every weight is a [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp object in the Merkle memory graph]]. You can
prove not just that the model file is unmodified, but that this specific
attention head has the weight vector it should have.*

## What is added

- Plist-native weight graph: weights are typed plists structured as a tree of
  tensors DAG, not a flat blob
- Structural weight diffs: the response to "which weight changed?" is "layer 17,
  head 3, weights 2048-4096 differ by vector V" — not "the blob hash changed"
- Weight provenance chain: the memory graph links each layer to its training
  event. A structural property of the weights, not a log entry about them
- No FFI boundary for inference: the tensor unit (or GPU mirror) operates on
  Lisp objects directly. The evaluator's verified semantics cover computation

## What is eliminated

- **Sub-tensor granularity tampering** — you can verify individual attention
  heads, not just the blob
- **Weight provenance ambiguity** — every weight links to its origin event
- **The FFI inference gap** — inference runs on Lisp data directly. No C/GPU
  code outside the evaluator's semantics

## What does this cost?

- **~100x compute, RAM, and storage on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] (GPU path).**
  A 7B model requiring 4GB as GGUF needs ~400GB as plist-native weights on a
  GPU. GPUs are built for flat arrays and SIMT; cons-cell traversal is their
  worst case
- **This 100x is GPU-relative, not fundamental.** An ASIC tensor unit with
  tagged memory, Merkle hashing in the memory controller, and sparse DAG-
  walking matmul closes the gap to 2-5x
- **Two implementation paths:**
  1. *GPU path (near-term):* plist-native weights as gold standard for
     provenance, GPU-native mirror for compute, Merkle-verifiable loading
     protocol. Cost: 100x storage, ~2-3x load-time overhead
  2. *ASIC path (destination):* tensor unit speaks cons-cell. No mirror
     needed. Cost: 2-5x over GPU for dense matmul
- **GC pressure** — plist-native weights produce enormous GC load. The
  Scavenger handles this on ASIC; on GPU path the mirror avoids it
- **Mixed-precision is complex** — 4-bit and 8-bit quantization destroy
  pointer structure. Full float32/64 may be the only practical option

## What does this enable?

You can prove exactly what your model is and that it hasn't been modified.
The Merkle chain from training event to individual weight is structural, not
logged. Fine-tuning provenance becomes as verifiable as the code running on
the machine. This is the stage where hardware choice determines practical
viability.

## When is this viable?

- **GPU hybrid path:** today. Works on any Passepartout with a GPU
- **ASIC native path:** 5-10 years (tensor unit on the dual-unit chip)

## In practice

Every individual weight is Merkle-verified, structurally tracked, and computed
within the Lisp evaluator's verified semantics. The FFI trust gap is closed.

Stage 5 is where hardware choice determines practical viability. The GPU path
works today but carries the storage overhead of two representations (plist gold
standard + GPU mirror) and the load-time verification cost. The ASIC path is
the destination — one representation, one chip, no workaround. Most users will
use the GPU path for years before the ASIC becomes available.

Either path is viable. The GPU path can be built today with existing hardware.
The ASIC path is the destination — a single verified chip that doesn't need
the hybrid workaround.

← [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]]  → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]

:PROPERTIES:
:CREATED:  [2026-05-24 Sun]
:WEIGHT:  18
:ID:       4a1f23b0-abc6-4def-9876-543210abcdef
:END:
