Records the eight hard-coded local artifact routes, default token limits, and the difference between a UI option and an independently verified compatibility record.
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.
Architecture topic: this page does not claim that the WordPress website implements or executes the described runtime behavior.
Routes
The selector maps eight internal keys to local .slm paths: three TinyLM-16M-shaped artifacts and five tiny fixtures, including BPE1 and tied-output cases.
Generation defaults
The TinyLM-16M-shaped options set the browser field to eight new tokens; tiny fixtures set it to sixteen. Form submission clamps the operator value to 1–512.
Evidence rule
A selector entry proves only that the static application knows a route. Runtime acceptance, manifest identity, quality evidence, license, and target-browser behavior remain separate.
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?