Figure: the KV block object, drawn as four sections inside one container. PAYLOAD is write-once: the K and V tensors for a sequence, layer and position range, 5.00 mebibytes. IDENTITY is immutable: sequence id, position range, layer, head group, prefix hash, and provenance or parent block. POLICY is mutable in place without migrating the payload: tenant, QoS class, priority, reuse score, recency, and scheduler-supplied residency intent. MECHANISM is local to wherever the block sits: residency location, compression format, transfer state, validity, and in-flight or pinned flags. A migration table states that identity is fixed at creation, migrates with the payload because it is the block's name, and is not mutable; that policy changes on scheduler events, is logically bound but physically separable, and is mutable without migration; and that mechanism changes on every transfer, does not migrate because it is regenerated per location, and is mutable. Write-once has four consequences: a tier copy never goes stale, so there is no coherence problem on the payload; eviction of a block that already has a tier copy is a clean discard with no writeback; each block demotes at most once in its lifetime regardless of how many times it is promoted, which is the delta-b at most 1 bound; and only control metadata mutates, at 64 bytes against a 5.00 mebibyte block, or 0.0012 per cent. The exception is in-place re-quantisation or re-compression, which writes new payload bytes and breaks write-once for that block.

Figure 7.1 · Illustrative — object model specification

The KV block object: payload, identity, policy, mechanism

The unit of placement, migration and accounting — and the reason “migrate the metadata with the block” is the wrong instruction.

The object

KV BLOCK OBJECT  bPAYLOADwrite-onceK/V tensors for (sequence, layer,position range) — 5.00 MiBIDENTITYimmutablesequence id · position range · layerhead group · prefix hashprovenance / parent blockPOLICYmutable in placetenant · QoS class · priorityreuse score · recencyscheduler-supplied residency intent— updatable WITHOUT moving a byteMECHANISMlocal to locationresidency location · compression formattransfer state · validityin-flight / pinned flags

The unit of placement, migration and accounting. The design claim is not “one physically fused object”: it is a logically migratable KV object with independently updatable control metadata.

What migrates, and what does not

ClassLifetimeMigrates with payload?Mutable without migration?
Identityfixed at creationYes — it is the block’s nameNo
Policychanges on scheduler eventsLogically bound, physically separableYes
Mechanismchanges on every transferNo — regenerated per locationYes

This is the correction to “migrate metadata with the block.” Migrating all metadata as one physically inseparable unit is wrong, because policy metadata changes while the block does not move — QoS is reassigned, priority shifts, scheduler intent updates every step.

Identity travels with the payload. Policy is associated with identity and may be updated in place, on either side, without moving a byte. Mechanism is local to wherever the block currently sits.

Write-once, and its four consequences

For a given (sequence, layer, position range), K and V are computed once — during prefill, or at the decode step that produces that token — and are never subsequently modified. Nothing in autoregressive decoding mutates existing KV. Everything below follows from that one property, and it is what distinguishes this from a general-purpose cache.

A tier copy never goes stale.
Once written, it stays valid. There is no coherence problem on the payload.
Eviction with a tier copy is a clean discard.
No writeback. The bytes are already where they need to be.
Each block demotes at most once.
In its whole lifetime, regardless of how many times it is promoted — the δb ≤ 1 bound the amplification metric rests on.
Only control metadata mutates.
Orders of magnitude smaller than the payload, and handled separately: 64 B against a 5.00 MiB block is 0.0012%.
The exception, stated explicitly. In-place re-quantisation or re-compression of a resident block writes new payload bytes and breaks write-once for that block. Systems that do this must account for it. Separately: payload-capacity overhead is negligible at 0.0012%, but metadata processing overhead is not established and must be measured — lookup bandwidth on the promotion path, atomic update cost under concurrent scheduler writes, controller SRAM footprint, coherence of policy state between planes, per-transaction link overhead. None of these is bounded by the capacity argument.

Illustrative (object-model specification) — data/formal_core.md §0 and §1; CANONICAL-NUMBERS.md §6 for the 0.0012% overhead