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§
- Asset
Record - The immutable record a registry stores for a live asset. Structurally identical
to
DenseAssetRef; returned byresolveso callers can read the validated fields (never a pointer). - Dense
Asset Ref - A validated, generation-safe, process-local handle to a dense asset.
- Dense
Asset Registry - A bounded, generation-safe registry mapping content tokens to validated dense asset records.
Enums§
- Section
Kind - 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
Vecis used, but it never grows past this — over-capacity insertion fails withQispError::BudgetExceededrather than allocating without bound (plan §6.2 “fixed-capacity result-handle table”).