Prioritizes model, tokenizer, manifest, source, HTTP, path, and raw-pointer boundaries using invariants derived from the existing implementation.
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.
Highest-risk targets
- SLM header and tensor directory offsets, lengths, overflow, alignment, rank, dtype, duplicates, and checksum.
- BTOK/BPE1 token lengths, UTF-8 bytes, duplicate IDs, merge references, ranks, and trailing data.
- Source and provenance line parsers with duplicate, missing, oversized, or ambiguous keys.
- Percent-decoded HTTP paths, request lines, and root containment.
- ABI pointer and length combinations available to JavaScript.
Properties
Accepted files never produce out-of-range slices; parser failure is deterministic; pack→parse preserves dimensions and tensor payloads; quantize→dequantize stays within declared tolerance; reset is idempotent; failed generation preserves accepted model identity; and no malformed input panics.
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?