Provides the consolidated, evidence-based limit set that must accompany every current runtime claim.
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.
- Custom SLM1 parser; no GGUF parser despite project name.
- One model resident at a time.
- Deterministic smoke weights; no product-quality assistant.
- Scalar CPU loops; no WebGPU, WebNN, SIMD specialization, or native accelerator.
- Main-thread synchronous browser calls; no worker or cancellation.
- Full-file fetch and copy; 128 MiB single-transfer cap.
- No persistent model store, range requests, resume, sharding, or eviction.
- Equal attention and KV-head counts required.
- F32 KV cache only; no paged, quantized, shared-prefix, or sliding cache.
- Byte and simple BPE tokenizers only; no normalization or standard tokenizer import.
- Custom checksum is not cryptographic; browser does not verify artifact SHA-256.
- Diagnostics schema is unversioned; runtime timing fields are incomplete.
- No modular skills, adapters, routing, committee, registry, or dependency resolver.
- No Teleodynamic structural/resource controller.
- Source archive omits the
.uaidirectory referenced by its own README/AGENTS files.
Claim template
“TinyRustLM 0.1.0 executes supplied deterministic SLM1 smoke artifacts through a synchronous scalar Rust/WASM path with BTOK/BPE1 tokenization, f32/q8_0/q4_0 weight storage, KV caching, sampling, diagnostics, and local static UI. Trained quality, GGUF support, multi-model modularity, Teleodynamic control, GPU acceleration, and production deployment are not established.”
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?