# Device Memory Model
P182 introduces an explicit backend memory layer without moving storage
semantics into mathematical domains.
The core types are in `backend::memory`:
- `DeviceBuffer`: metadata for a value resident in a hardware target and memory
space.
- `BufferLayout`: backend-facing storage layout derived from object metadata.
- `TransferPlan`: planned movement between buffers, including transfer direction,
support status, semantic-preservation flag, and fallback reason.
The model is intentionally metadata-first. Existing `Tensor<T>` values remain
host-side Rust vectors, while `DeviceBuffer` describes how a tensor, p-adic
witness, or finite-site sheaf witness would be represented at the backend
boundary.
Supported memory spaces are:
- `Host`;
- `Device`;
- `Unified`;
- `PinnedHost`.
P182 does not implement GPU allocation, streams, asynchronous copies, or pinned
memory transfers. Host-to-device paths currently produce structured unsupported
transfer reasons. This is deliberate: later GPU work must declare memory support
instead of silently treating mathematical objects as ordinary dense tensors.
Each buffer may also carry an optional CPU-oracle fixture name from P181, so
future cross-backend tests can connect transfer metadata back to reference
semantics without changing domain ids, p-adic precision, or sheaf locality.