Explains the line parser, rendered fields, load order, failure behavior, and why the sidecar is currently informational rather than an admission authority.
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.
Parser
The browser splits lines, ignores blanks and comments, and stores text before and after the first equals sign. It does not reject duplicates, unknown keys, malformed values, or conflicting records.
Rendered fields
Source kind, admission status, quality claim, trained-quality claim, SLM checksum, and required next gate appear in the provenance panel.
Load order
The manifest is fetched only after the Rust runtime has accepted the model. A missing or malformed sidecar changes the panel to an error but does not unload or quarantine the model.
Required upgrade
Cryptographic admission must verify artifact SHA-256 and a signed, versioned manifest before model activation, then bind the verified identity to the active runtime handle.
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?