Operational compatibility matrix

Defines the minimum dimensions of an evidence-backed matrix for model, format, tokenizer, quantization, runtime, browser, device, and feature combinations.

Experimental
Last verified
2026-06-25 00:00 UTC
Updated
Reading time
1 minutes

Defines the minimum dimensions of an evidence-backed matrix for model, format, tokenizer, quantization, runtime, browser, device, and feature combinations.

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.

Matrix coordinates

Artifact SHA-256; SLM/GGUF format version; model family and exact dimensions; tokenizer identity; quantization variant; runtime/WASM hash; browser and version; operating system; CPU/GPU; memory; execution mode; context; sampling; and UTC test date.

Status vocabulary

Observed source presence, structurally validated, runtime smoke, task evaluated, browser verified, preview supported, stable supported, failed, and not tested must remain distinct.

Publication rule

A matrix cell without reproducible evidence is Not verified, not implicitly supported. A passing cell cannot be generalized to a different artifact, browser, quantization, or source revision.

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?