Artifact identity and quantization
A model name is not an artifact
Section titled “A model name is not an artifact”“RegesCore 35B” identifies a model family, not a complete reproducible input. A useful artifact record includes the repository, immutable revision, full file set, exact byte sizes, hashes, tokenizer, chat template, architecture, tensor encodings and license. A local filename alone cannot establish all of those facts.
The native inspector reads what is present in a GGUF’s metadata and tensors. A stale display name does not change its geometry. Likewise, a label such as Q4 does not fully describe mixed tensor encodings or every quantizer’s quality behavior.
GGUF and complete sets
Section titled “GGUF and complete sets”GGUF is a container for metadata and tensor data; the engine still needs architecture and encoding support. Some artifacts are split into multiple shards. Others pair language weights with a separate vision projector. Completeness checks must distinguish those cases rather than assuming every .gguf is a standalone chat model.
The current core blocks an inspected shard that declares a multi-part set. Aggregating and qualifying complete split sets is planned. It also identifies projectors separately and refuses to load one as an independent language model.
Quantization is an explicit choice
Section titled “Quantization is an explicit choice”Quantization represents weights using different encodings to change storage, memory and computational behavior. It can change output quality. There is no general rule that a small artifact preserves all behavior of its original BF16 source.
The tested 35B artifact is MXFP4_MOE, approximately 20.18 GiB. The native app uses the chosen existing file in place. It does not convert it to MXFP4, prune experts, rewrite weights or certify equality to a BF16 version. A quantization suffix is not a compatibility guarantee: an exact kernel must support the actual tensor types.
The requested RegesCore BF16 set
Section titled “The requested RegesCore BF16 set”At revision ffc803121e007d2287a155fef0e2ce4aefbb179c, the public BF16 directory contains two GGUF shards:
| File suffix | Manifest bytes |
|---|---|
BF16-00001-of-00002.gguf |
49,781,577,216 |
BF16-00002-of-00002.gguf |
19,595,060,416 |
| Complete pair | 69,376,637,632 · 64.612 GiB |
Bounded remote header samples identify GGUFv3, qwen35moe and file type32/BF16. The size and hashes come from the public Hub manifest; the full files were not downloaded or locally hashed, and per-tensor encodings were not audited. Read the public evidence manifest.
The native importer currently blocks individual split shards. This set needs complete-set identity, structural/hash validation, an aggregate memory gate and an actual split-set backend load before support can be claimed. The optional vision projector is separate. BF16 load, quality and throughput are untested; its larger precision label does not establish fit or faster generation on the tested consumer GPU.
Compare like with like
Section titled “Compare like with like”When comparing engines, use the same immutable file set first. When comparing artifacts, declare the intentional quality/storage difference and run a separate evaluation. Keep model revision, prompt template, tokenizer, context and sampling in the record. If any identity is unknown, report it as unknown rather than manufacturing a fingerprint from the display name.
For the upstream container definition, see the official GGUF specification. For RegesARC’s behavior, the source of truth is its bounded inspector and native load gate.