Defines cache keys, chunking, cryptographic verification, transactional activation, quotas, eviction, and corruption recovery for a browser-local artifact store.
Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.
Identity key
Use immutable artifact SHA-256 plus format version, model family, tokenizer identity, quantization, and source revision. A URL alone is not identity.
Storage path
The Cache API is suitable for immutable HTTP responses; OPFS is suitable for chunked or locally transformed files. Indexed metadata should point to immutable bytes rather than duplicate them.
Admission transaction
- Download to a temporary key with resumable chunk evidence.
- Verify total bytes and SHA-256.
- Verify a signed manifest and policy.
- Run structural validation.
- Atomically promote the verified record to active inventory.
Eviction
Track installed, resident, and active state separately. Eviction must never remove an artifact used by an active runtime and must retain enough evidence to explain why a later reload is required.
Scope
This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.
Engineering considerations
- Identify the source, version, target environment, and owner.
- Separate observed values from estimates and externally reported values.
- Record trade-offs, unsupported cases, and fallback behavior.
- Link performance statements to a compatible benchmark methodology.
Verification questions
- What exact artifact, revision, backend, and environment were reviewed?
- Which assumptions could change the result?
- Which data should be retained so another engineer can reproduce the conclusion?