Provides an operator sequence for distinguishing network failure, transfer failure, parser rejection, tensor rejection, scratch/cache allocation failure, and provenance failure.
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.
1. Classify the stage
| UI state | Likely stage | Evidence |
|---|---|---|
| fetch error | HTTP route or response | Status, route, server log |
| WASM allocation failed | Zero/over-limit or memory pressure | Artifact bytes, 128 MiB cap, console |
| Model rejected | SLM parser/model admission | Error code, result, diagnostics |
| Manifest error only | Sidecar fetch/parse | Manifest route and text |
2. Preserve identity
Record model path, byte count, SHA-256, internal SLM checksum, WASM SHA-256, browser, source revision, and UTC time before retrying.
3. Reproduce natively
Run packer validation and manifest validation against the same bytes. A browser-only failure then belongs to transfer, memory, or host integration rather than the file schema alone.
4. Recover
Select another known artifact or reload corrected bytes. Do not relabel a rejected artifact as compatible by changing only the sidecar.
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?