Defines rollback units across WordPress documentation, runtime WASM, model artifacts, manifests, caches, and operator-visible compatibility records.
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.
Independent units
MiRust theme/plugin, implementation source, WASM runtime, SLM/GGUF artifact, manifest, compatibility record, and cached local copy each have their own version and hash.
Rollback packet
Retain the last accepted bytes, checksums, environment, release notes, database backup, compatibility matrix, and model-store index. Never overwrite a release artifact under the same immutable identity.
Cache invalidation
Cache keys include content hashes. A runtime rollback may require quarantining artifacts that depend on a newer ABI; a model rollback must update the active manifest and evidence record atomically.
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?