arkhe.gguf

A quantised GGUF conversion of Qwen2.5-1.5B-Instruct, carrying Arkhe OS attestation metadata inside its GGUF header.

The point of this repository is not the model. The model is deliberately ordinary — a well-known 1.5-billion-parameter instruct model, converted with stock llama.cpp. What is unusual is that the artifact describes its own provenance, in-band, and can be checked without trusting this page.

File	arkhe.gguf
Size	1 646 574 272 bytes (1.53 GiB)
Format	GGUF version 3
Quantisation	Q8_0
Tensors	338
KV pairs	49 (35 from the conversion, 14 attestation)
SHA-256	10bf45ab933af59e501b9fa63a0a8a1d26a9ec15adf2f13f7dfbe567dbc07708
Base model	Qwen/Qwen2.5-1.5B-Instruct (Apache-2.0)
Base SHA-256	9822626ecb93d38a8f0b983f7bc0fcd15d4c6d890e88cdcea7703fe5b27c651d

---

Why this artifact exists

Arkhe OS is a verification infrastructure for AI artifacts: it checks hashes, signatures, Merkle inclusion proofs and witness quorums, and reports each check honestly — including when a check could not be performed.

A verifier is only as good as the artifacts you can point it at. This repository is one such artifact, built end to end so that every step is reproducible:

1. Download the base model from Hugging Face.
2. Convert it to GGUF with llama.cpp.
3. Inject attestation metadata into the GGUF header.
4. Verify the result with arkhe-verify.

Step 4 is the one that matters. It is not a claim on this page — it is a command anyone can run.

---

Reproducing this artifact

Every command below was executed to produce the file in this repository.

1. Fetch the base model

BASE=https://huggingface.co/Qwen/Qwen2.5-1.5B-Instruct/resolve/main
for f in config.json generation_config.json merges.txt tokenizer.json \
         tokenizer_config.json vocab.json model.safetensors; do
  curl -L -o "qwen-base/$f" "$BASE/$f"
done
sha256sum qwen-base/model.safetensors
# expected: dd924a11b4c220f385b51ffa522daea7c9f3d850e31b162bb5661df483c6d3ee

2. Convert to GGUF (Q8_0)

git clone https://github.com/ggerganov/llama.cpp
pip install -r llama.cpp/requirements/requirements-convert_hf_to_gguf.txt
python llama.cpp/convert_hf_to_gguf.py \
    --outfile base.gguf --outtype q8_0 ./qwen-base
sha256sum base.gguf
# expected: 9822626ecb93d38a8f0b983f7bc0fcd15d4c6d890e88cdcea7703fe5b27c651d

convert_hf_to_gguf.py does not accept q4_k_m — its --outtype choices are f32, f16, bf16, q8_0, tq1_0, tq2_0, auto. K-quants require a separate llama-quantize step, which needs a compiled llama.cpp. Q8_0 needs neither.

3. Inject the attestation metadata

python tools/arkhe-gguf/extend_metadata.py base.gguf arkhe.gguf
sha256sum arkhe.gguf
# expected: 10bf45ab933af59e501b9fa63a0a8a1d26a9ec15adf2f13f7dfbe567dbc07708

The tooling lives in the Arkhe OS repository, under tools/arkhe-gguf/ and safe-core-monorepo/crates/arkhe-verify/.

---

The attestation metadata

14 key-value pairs are written into the GGUF header under the arkhe.attestation. prefix. They are part of the file: changing any of them changes the SHA-256 above.

Key	Value in this artifact
schema_version	1.4
source.file_hashes.sha256	SHA-256 of the base GGUF, before metadata
source.size_bytes	size of the base GGUF
verifiable.extended_at	ISO 8601 UTC timestamp of the metadata injection
attested.attestation_type	PROMISE
attested.declared_capabilities	empty — an empty claim is the honest one
attested.not_capabilities	code-execution, network-access, file-write, shell-execution
attested.disclaimer	Capabilities are declarations by the signer, not verifications.
revocation.revocable_at	https://arkhe.computer/revocation.json
revocation.strategy	short_lived
anchored.external	true
anchored.anchor_type	rekor
anchored.bundle_uri	arkhe.gguf.sig

What is deliberately absent, and why

The v1.3 schema wrote anchored.log_id, anchored.log_index and anchored.inclusion_proof inside the file. That is impossible to satisfy: those fields only exist after anchoring, and anchoring is signing — writing the proof of its own anchor into the artifact would change the bytes the signature covers.

v1.4 resolves this the way OpenSSF Model Signing already does: the file carries the subject hashes; the anchor lives in the companion bundle. A .sig file beside this model is where a Rekor inclusion proof belongs.

This artifact is not signed. anchored.external: true is, today, a declaration of intent. The bundle does not exist yet. If you need to rely on the provenance of this file, rely on the SHA-256 above and on reproducing the steps — not on the presence of the anchored keys.

---

Using it

llama.cpp

llama-cli -m arkhe.gguf -p "What is verification?" -n 64

transformers

The file loads through transformers with the base model's configuration. This is the exact code that was run to validate the artifact:

from transformers import AutoModelForCausalLM, AutoTokenizer

tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-1.5B-Instruct")
model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-1.5B-Instruct",
    gguf_file="arkhe.gguf",
)

ids = tok("What is verification?", return_tensors="pt")
out = model.generate(**ids, max_new_tokens=24, do_sample=False)
print(tok.decode(out[0], skip_special_tokens=True))

Loading de-quantised all 338 tensors and reported 1 543 714 304 parameters — the same count the source model declares, which is how we know the conversion did not silently drop anything.

---

Verifying it

git clone https://github.com/rafael-arkhe/arkhe
cd arkhe/safe-core-monorepo
cargo run -p arkhe-verify -- /path/to/arkhe.gguf --verbose

Expected output begins with a header check and a digest, and every gate that could not be evaluated says so rather than passing silently:

Gate 0 — metadata sanitisation (runs before the gates below):
  passed: ...
[ ok ]  header      version 3, 338 tensors, 49 key-value pairs
[ -- ]  digest      not evaluated: no expected digest supplied
...

Gate 0 is worth a note. It refuses malformed GGUF metadata before any other gate runs, and it exists because of a class of real vulnerabilities (CVE-2026-5757, CVE-2026-65315, CVE-2026-7482, CVE-2026-86289, CVE-2026-53923, CVE-2025-53630) where a reader trusts declared counts without validating them against the actual data. arkhe-verify is built so that this file is rejected before a parser sees it if anything in its header is inconsistent.

---

Honest limitations

• This is a quantised derivative. Q8_0 is close to the source but not identical to it. The weights are not the original weights.
• The metadata is not a proof of safety. It records provenance claims. It says nothing about what the model will do.
• The model is not fine-tuned for anything. It is the stock instruct model with new header metadata. No training was performed.
• Not signed, not anchored. See above. The .sig bundle does not exist yet.
• Tensor data extent is not validated by Gate 0 — only the declared offsets and shapes. Validating the quantised block sizes would require the GGML type table.
• One runtime was used (transformers with de-quantisation). It loaded the file and generated text. That is stronger evidence than a header parse and much weaker than a full evaluation.

---

Provenance chain

Qwen/Qwen2.5-1.5B-Instruct          (Apache-2.0, upstream)
  └─ model.safetensors              sha256 dd924a11…c6d3ee
      └─ base.gguf   (Q8_0)         sha256 9822626e…b27c651d
          └─ arkhe.gguf             sha256 10bf45ab…dbc07708   ← this file

Each arrow is a command in this document. Each hash is a value you can recompute.

---

Licence

The base model is Apache-2.0 (Qwen2.5-1.5B-Instruct), and this derivative keeps it. The conversion tooling and the Arkhe OS verification stack are MIT OR Apache-2.0; see the Arkhe OS repository.