Design Documents

Persisting's architecture, addressing model, and storage design.

---

Architecture

Document	Description
Architecture	Queue persistence and system overview
CLI Architecture	Thin CLI + dynamic engine loading (中文)

Tiered Storage

Document	Description
TTAS Addressing	Tiered Tensor Address Space — formal addressing model
Distributed Tiered Storage	Block model, virtual address mapping, Pulsing integration
Block Store Internals	Block table, page fault handling, event loop (中文)

Capture & Trajectory

Document	Description
Capture Architecture	LLM proxy, event model, dual storage (中文)
Trajectory Storage	Lance canonical + Markdown materialization (中文)
Trajectory Markdown Format	TLV block model, frontmatter, live upsert (中文)
Traj CLI	persisting traj command reference (中文)
Capture CLI	traj capture / traj proxy subcommands (中文)

Compute

Document	Description
Compute Architecture	Driver/Worker, scheduling, sink, checkpoint (中文)

Search

Document	Description
Search CLI	persisting search command design (中文)

---

Reference & Analysis

Document	Description
Similar Systems	LMCache, vLLM, UMap, CUDA VMM comparison
vs TransferQueue	Scoring and migration analysis
TransferQueue Interface	API comparison table
LMCache KV Cache	LMCache analysis for KV Cache implementation (中文)

---

Implementation Tracking

Document	Description
Tiered Storage Steps	Step-by-step implementation with test checklists

---

Design Principles

1. Lance is the baseline — All caches and accelerations are built on top of "reads from file."
2. One foundation, multiple patterns — Trajectory, Search, KV, Queue share the Lance ecosystem.
3. Trajectory dual-view — Lance (canonical dataset) + Markdown (materialized); -f md live upserts Markdown, -f lance writes Lance only (materialize for md).
4. Capture is self-contained — Embedded proxy captures LLM traffic; IDE import is supplementary.
5. TTAS is internal — Users see kv[key].tensor(), not raw address algebra.
6. Performance is product — P99 latency, GPU utilization, capture real-time fidelity.