v0.2.0 — verification hardening, DPO track, CI pipeline & fast vLLM eval

Highlights

• Verification hardening — the training/dataset gates now fail closed on the attack surface found in a whole-project audit: train-GPU corroboration reads signed NRAS hwmodel claims, not the miner-editable sidecar (#236); the manifest gpu_architecture is bound to the signed hwmodel (#238); attested eval samples are bound to their benchmark key so a passing sample can't be cross-mapped (#230); the canonical-pin grace window is honored on the scores path (#232); verified runs no longer drop benchmarks the frontier lacks (#234); the accepted-registry snapshot applies the mix's unexportable-row filter (#240); and malformed proof-bundle scores fail closed instead of crashing verify (#244).
• DPO training track (#268) — miners can submit an Axolotl rl: dpo recipe trained on a canonical preference dataset, verified and scored exactly like SFT (scoring is a held-out benchmark delta, independent of training method). The one "this is SFT" chokepoint is now track-aware and the reward-gate check_canonical_dataset_claim selects the preference pin for train_objective: "dpo" bundles (fail-closed without a pin) — SFT verification is byte-identical.
• CI pipeline (#247) — ruff / ruff format / pyright / pytest on every push & PR as a least-privilege pull_request job (no secrets to forks); all GitHub Actions SHA-pinned; Dependabot added; vendored tritonbench/ excluded from ruff.
• CoT recovery (#247) — when a teacher (GPT 5.6) returns encrypted/empty reasoning, Claude Fable 5 backfills a plaintext rationale so SFT rows keep a usable <think> trace (tagged metadata.cot_recovery); best-effort, never discards a generated trajectory.
• GPU-wheel vLLM serve stack (#247) — installs the official vllm==0.25.0+cu129 wheel + matching PyTorch (no CPU-only torch, no minutes of JIT at engine start) for fast TritonBench eval, and fixes a real _gpu_architecture UnboundLocalError on the auto-detect path (surfaced by the new pyright gate).
• Package version 0.2.0 (was 0.1.3).
• Dataset gate pinned to SparkProof v0.3.0 (#273).

DPO training track (new capability)

SparkDistill's training track verifies reproducibility + measured quality, not the training algorithm — so preference tuning drops in as a recipe type with no new scoring machinery.

• An SFT recipe (no rl key) keeps its exact prior behavior and must use the canonical SFT mix; a rl: dpo recipe must use the canonical preference path. The two tracks' accepted datasets/pins are disjoint (canonical_pref_sha256 beside canonical_sft_sha256), so a DPO submission can never satisfy the SFT pin or vice-versa.
• The reward-gate check is track-aware: a bundle declaring train_objective: "dpo" is verified against the canonical preference pin (pref_manifest.pref_sha256 / canonical_pref_hf_url) and fails closed if no preference pin is configured.
• The preference signal is GPU-attested, not human-labeled: pairs come from SparkProof's verified-vs-failed kernels (sparkproof-export-dpo --pair-type correctness), sha256-pinned and attested in the bundle manifest (SparkProof v0.3.0).

Still to come for end-to-end DPO submission: publishing the canonical preference dataset + pref_manifest pin, prepare_mining_dpo, the DPO-aware PR-body citation + grace window, and the dpo.yaml example recipe.

Pairs with SparkProof v0.3.0

The dataset registry gate now checks out SparkProof at the immutable v0.3.0 release commit (not the moving main), so every dataset submission is verified against exactly the released verifier — the one carrying the DPO correctness pairs and the attested preferences_sha256 bundle pin, plus the v0.3.0 dataset-quality + attestation hardening. Reproducible and auditable; bump deliberately to adopt a newer SparkProof release.

Also in this release

• Registry mix export routes through SparkProof's publish path (trajectory_to_messages_record), skipping empty/failed rows and preferring multi-turn episodes.
• Claim binding uses the signed NRAS eat_nonce, and TDX binding reads REPORTDATA from quote_b64 — never the editable JSON sidecars.
• Attested GSM8K regression samples can no longer forge a score by duplicating a problem_id.
• Training-track merges seed / raise runs/frontiers.json from verified non-REJECT scores.
• Two env-dependent tests made deterministic (fallback dedupe + a SparkProof skip-guard) so the suite is green with or without a sibling SparkProof checkout.

Full notes: see the CHANGELOG.

v0.1.3 — attestation fail-close and registry/teacher robustness

Highlights

• Training CI fail-closes forged attestation (#194): NRAS JWKS + claim binding (+ TDX when present/required) before eval tiers.
• Registry / export / teacher hardening (#195): no crash on bad prior registry rows; LF+UTF-8 sha pins; skip flaky teacher calls.
• Package version 0.1.3 (pyproject was still 0.1.1 after the v0.1.2 tag).
• Pairs with SparkProof v0.1.3 — Sol→Fable CoT recovery for better training datasets (details below).

SparkProof Sol→Fable CoT recovery (better training data)

SparkDistill students learn from SparkProof trajectories that wrap teacher reasoning in <think>…</think> before the verified Triton answer. GPT 5.6 Sol often returns only encrypted reasoning_details, so a Sol best-of-N win previously produced a verified kernel without a usable chain-of-thought for SFT.

SparkProof v0.1.3 (#31) fixes that for dataset miners:

1. Best-of-N unchanged — still calls Claude Fable 5 + GPT 5.6 Sol, validates on Blackwell/Hopper, keeps the higher-scoring winner.
2. When Sol wins with encrypted/empty CoT — SparkProof calls Fable again:
   • Re-solve (preferred): Fable gets Sol’s verified kernel as a hint, produces its own full answer + plaintext engineering rationale, then re-validates on GPU. If it passes, that Fable trajectory is kept (metadata.cot_recovery=fable_resolve).
   • Explain (fallback): if re-solve fails validation, Fable writes an inspectable rationale while Sol’s gold verified code stays the assistant answer (metadata.cot_recovery=fable_explain).
3. SFT export — skips encrypted reasoning JSON dumps so <think> tags stay useful; prefers the original mining-task prompt (prompt_meta.prompt) as the user turn.

What this is / isn’t: this does not decrypt Sol’s private CoT. It produces Fable-authored, train-able rationales bound to hardware-verified kernels — aligned with SparkProof’s preference for inspectable engineering rationale over opaque encrypted traces.

Why it matters for SparkDistill: registry / canonical mining mixes built with SparkProof ≥ v0.1.3 should yield more rows with real <think> traces when Sol would otherwise have won “code-only,” improving distillation quality on Triton reasoning without weakening GPU validation or attestation.

Miners: upgrade SparkProof to v0.1.3 before the next dataset generation pass.

Also in this release

• Unattested training PRs cannot earn eval tiers.
• Repair-tier mix dedupe matches SparkProof task-prompt fingerprints.
• Dataset registry gate: clean dataset:REJECT on malformed prior rows / invalid JSON (no CI traceback).
• GPU corroboration uses hwmodel claims only (#149).

Full notes: see CHANGELOG.

v0.1.2 — Hopper mining, per-arch frontiers, trustless dataset verification

Hopper joins Blackwell on both mining tracks, per-architecture frontiers replace the shared Triton scoreboard, and dataset verification closes the last userland trust gaps (NRAS JWKS + Intel TDX). Architecture-scoped exact dedupe and a refreshed canonical mining mix (174→178 rows) land in the same release window.

Highlights

Hopper + per-architecture frontiers ([#104], [#109], [#120])

• Dataset track accepts Hopper H100/H200 alongside Blackwell; registry entries carry gpu_architecture.
• Separate Blackwell and Hopper frontier buckets in runs/frontiers.json.
• First verified Hopper training BASELINE merged ([#120], magicrails-hopper-v2 on H200).

Architecture-scoped dedupe ([#133], SparkProof [#26])

• Exact dedupe keys prompt matches by gpu_architecture — same prompt on Blackwell vs Hopper is a fresh row.
• Canonical sparkproof-mining republished: 174 → 178 rows ([#134]).

Canonical mining dataset + miner tooling ([#89], [#97], [#119], [#132])

• Every training PR trains on the pinned sparkproof-mining snapshot.
• sparkproof-publish-dataset --mining-repo and accepted_registry_snapshot.jsonl documented ([#132]).
• Fair dataset labels from canonical-mix rows_selected, not raw bundle counts ([#116]).

Trustless dataset verification ([#53], [#122])

• Dataset gate always runs sparkproof-verify --online (NVIDIA JWKS).
• New bundles require Intel TDX bound to the dataset nonce.

Full changelog: CHANGELOG.md

v0.1.1 — dual-vendor authenticated, measured-VM attestation

Hardens v0.1.0's proof of training into fully authenticated, measured-VM attestation. Every trust gap closeable with today's infrastructure is now closed — nothing in a submission is taken on the miner's word.

Highlights

Intel TDX measured-VM proof (#45–#47)

• On TDX guests (Targon CC VMs), eval.attestation captures an Intel TDX quote via configfs-tsm with the bundle's claim_sha256 in its 64-byte REPORTDATA; MRTD (guest-image measurement) recorded. eval.verify reports the binding as tdx_bound.
• The baseline ledger run was re-attested with GPU + TDX binding.

Quote and token authenticity — dual vendor (#48, #49)

• Intel DCAP verification (tdx_signature): the TDX quote's ECDSA signature, PCK certificate chain to Intel's root CA, QE identity, and platform TCB status validated against live Intel PCS collateral ("UpToDate" + no advisories is the clean pass).
• NVIDIA JWKS verification (gpu_signature): every NRAS-signed JWT in the GPU attestation (platform + per-device, ES384) validated against NVIDIA's published JWKS with issuer and expiry enforced; the SDK-local overall JWT is intentionally not counted as evidence.
• A hand-crafted attestation JSON now fails signature verification on both sides.

Verification robustness (#51)

• Found by the full live function test: honest claims were rejected on 2.1pp of cross-server generation drift (3-problem triton quick set). Benchmarks gain per-benchmark claim_tolerance_pct (triton: 5pp while the problem set is tiny) and the eval server pins determinism (--seed 0 --no-enable-prefix-caching).

Verified live on the baseline run

claim_bound:           true              (claim digest in the GPU attestation nonce)
gpu_signature:         true, 2 tokens    (NVIDIA JWKS, ES384)
tdx_bound:             true              (claim digest in TDX REPORTDATA)
tdx_signature:         true, UpToDate    (Intel DCAP / PCS)
checkpoint_hash_match: true

Full details in CHANGELOG.md. The frontier to beat remains triton 0.4278 — see runs/frontier.json.

v0.1.0 — first verified proof-of-training baseline

The first complete, working release of the SparkDistill miner economy: train a Triton-specialized student on verified data, prove the run cryptographically, and verify it from public artifacts alone.

Highlights

Two-track miner economy

• Dataset track (dataset:xs–xl): SparkProof bundles on Blackwell CC VMs, verified end-to-end by CI (release gate, GPU CC attestation, sha256 pinning, novelty), auto-merged registry PRs, and automatic aggregation into the canonical mining dataset (gittensor-model-hub/sparkproof-mining).
• Training track (eval:BASELINE, eval:XS–XL): public Axolotl recipes trained on registry-backed data, scored against the canonical frontier.

Weights-free, claim-bound proof of training

• Proof bundles carry the claim, not the weights: eval scores, training claims, and a per-file sha256 manifest of the checkpoint (~12KB instead of ~8.8GB).
• The bundle's claim_sha256 is bound into the NRAS-signed GPU CC attestation as the nonce — a passed attestation cannot be reused for a different claim.
• eval.verify runs the whole validator side in one command: attestation, hardware corroboration (RTX PRO 6000 / GB20X), 5-hour training budget, mix provenance, claim binding, checkpoint hash comparison, and held-out score re-runs against a locally reproduced checkpoint. First run on a student/phase gets eval:BASELINE mechanically.

Triton domain evaluation

• Vendored, version-pinned TritonBench harness (Triton 3.7.1, Blackwell SM12x/SM10x): generated kernels are compiled and executed on the GPU, correctness requires an executed reference comparison, and problem required_patterns are enforced.
• Deterministic serving for comparable claims: pinned vLLM (scripts/install_serve.sh) and greedy decoding.
• General basket (GSM8K, BFCL, HumanEval, IFEval, MMLU-Pro, AIME, GPQA-Diamond via lm-eval) as the regression guard.

First verified baseline on the ledger

• Run 2026-07-11-qwen3.5-4b-mining-001: Qwen3.5-4B LoRA on the canonical mining dataset, trained in 97s on a Targon RTX PRO 6000 Blackwell CC node, attested (nonce-bound), published, and verified — triton 0.4278 (syntax 100%, exec 0%) / gsm8k 0.6.
• runs/frontier.json seeds the score every next submission must beat.

Tooling & docs

• Reproducible training on Blackwell (recipe prep, FA2/FA3 selection, small-dataset guards), HF→local dataset export, miner guide, contribution template, and the project site at https://gittensor-model-hub.github.io/SparkDistill/

The frontier to beat

triton 0.4278 — with 0% kernel execution pass, the mining opportunity is clear: more verified Triton training data.