Skip to main content

Module asset_registry

Module asset_registry 

Source
Expand description

QISP dense-asset registry — generation-safe, fail-closed handles to content-addressed dense assets (plan §3.4, §3.6, §10.1 QISP-R03/R04).

§Security contract (read before touching this file)

A DenseAssetRef is a validated, process-local handle. It carries only numeric fields — a content-derived 60-bit token, a generation number, a section kind, a byte offset, a byte length, and a digest prefix. No Rust address, GPU buffer pointer, or unchecked file offset is ever stored in it or derivable from it (plan §2.2 item 5, §14 non-goals, QISP-R04). The public RDF term is an absolute IRI; it is resolved to one of these handles internally — never the other way around.

DenseAssetRegistry::resolve fails closed: a forged token, a tampered offset/length, or a stale generation returns a named QispError and never fabricates a record. It never panics on a bad handle. This is a §15 security-critical requirement.

Structs§

AssetRecord
The immutable record a registry stores for a live asset. Structurally identical to DenseAssetRef; returned by resolve so callers can read the validated fields (never a pointer).
DenseAssetRef
A validated, generation-safe, process-local handle to a dense asset.
DenseAssetRegistry
A bounded, generation-safe registry mapping content tokens to validated dense asset records.

Enums§

SectionKind
The dense-asset section kinds (plan §3.4 / §3.6 representation table).

Constants§

MAX_ASSETS
Hard capacity ceiling for a single registry. The registry is a cold structure (query/endpoint scoped), so a bounded Vec is used, but it never grows past this — over-capacity insertion fails with QispError::BudgetExceeded rather than allocating without bound (plan §6.2 “fixed-capacity result-handle table”).