Separates structural admission, runtime-smoke, converted-trained provenance, assistant-quality evidence, safety review, and publication status.
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.
Gate ladder
{table(‘Current evidence gates’, [‘Gate’,’Minimum evidence’,’Permitted claim’], [(‘Structural validation’,’Safe format, tokenizer, tensor directory, required names, shapes, values’,’Artifact is parseable and structurally compatible.’),(‘Runtime smoke’,’Valid artifact and successful deterministic execution’,’Runtime path executes this artifact.’),(‘Converted trained’,’Validated raw source and reproducible conversion manifest’,’Artifact was produced from the declared source layout.’),(‘Assistant quality’,’Passed scoped task eval, safety review, declared non-placeholder quality scope, positive cases, zero failures’,’Only the exact reviewed scope may be claimed.’),(‘Product release’,’Not implemented as a complete gate’,’Requires deployment, support, security, license, compatibility, and rollback evidence.’)])}
Strict non-promotion
A runtime-smoke artifact cannot become assistant-quality because it generates text. A converted-trained label cannot substitute for task evidence. A fixture-scoped pass cannot become a general assistant claim.
Publication rule
MiRust model profiles expose implementation evidence separately from maturity and state the source manifest’s trained-quality non-claim.
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?