Provenance manifests

Explains the line-based SLM manifest schema, binding fields, source kind, quality claim, admission status, next gate, and current browser trust limitations.

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

Explains the line-based SLM manifest schema, binding fields, source kind, quality claim, admission status, next gate, and current browser trust limitations.

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.

Fields present

  • Manifest version.
  • Model path and byte length.
  • SLM version and internal checksum.
  • Model shape and tensor count.
  • Parameter count and quantization.
  • Source kind.
  • Quality claim and trained-quality claim.
  • Admission status and required next gate.

Current smoke semantics

Checked-in artifacts use source_kind=deterministic-smoke, quality_claim=runtime-execution-smoke-only, trained_quality_claim=not-claimed, and an accepted runtime-smoke admission.

Validation

The packer can compare manifest fields with actual model size, format, checksum, shape, tensor count, parameter count, and quantization.

Browser limitation

The app renders the sidecar after Rust model load, but does not use it to verify artifact SHA-256 or gate admission. A malicious same-origin replacement could supply matching untrusted model and manifest files.

Upgrade

Canonicalize the manifest, add SHA-256, tokenizer/source hashes, runtime compatibility, license, signer identity, and signature. Verify before allocation-heavy parsing.

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?