Maps the principal files in the reviewed snapshot to their runtime, format, browser, evidence, and tooling responsibilities.
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.
Runtime
| Path | Primary responsibility |
|---|---|
runtime/src/wasm_exports.rs |
Raw ABI and global runtime owner |
runtime/src/generate.rs |
Runtime lifecycle, prefill, decode, forward pass |
runtime/src/model_format.rs |
SLM1 structural parser and checksums |
runtime/src/model.rs |
Required tensors, storage, indexed dispatch |
runtime/src/tokenizer.rs |
BTOK and BPE1 parsing and conversion |
runtime/src/kv_cache.rs |
Layer-major K/V storage |
runtime/src/sampler.rs |
Greedy/top-k/top-p selection |
runtime/src/memory.rs |
Host transfer allocation boundary |
Product and tooling
| Path | Primary responsibility |
|---|---|
app/app.js |
Boot, transfer, controls, transcript, provenance, timing |
tools/slm_pack/ |
Fixture generation, validation, conversion, manifests, gates |
runtime/src/bin/tinyrustlm-eval.rs |
Native exact-case evaluation CLI |
tools/local_server/ |
Loopback static file serving |
tools/browser_harness/ |
Static and optional HTTP contract audit |
tools/wasm-abi-smoke.js |
ABI error and recovery smoke |
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?