Explains how line-based sidecars are fetched and rendered, why this is operator information rather than a trust gate, and how to convert it into verified admission.
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.
Current behavior
After Rust accepts a selected model, JavaScript fetches the matching .slm.manifest, parses key-value lines, and displays source kind, admission status, quality claim, trained-quality claim, checksum, and required next gate.
Failure behavior
A missing or malformed sidecar produces a readable provenance error but does not retroactively invalidate the already loaded model.
Trust issue
UI rendering demonstrates transparency, not authenticity. The sidecar and model are served by the same origin and are not cryptographically bound in the browser.
Required admission design
- Fetch signed canonical manifest first.
- Verify signature and allowed publisher.
- Stream model while computing SHA-256.
- Compare size/hash and declared runtime compatibility.
- Only then finalize Rust model activation.
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?