AAdil Islam
Finetuning · Dharmatune

Teaching a model to believe — and to keep everything else it knew

Dharmatune is a mission to support the alignment of AI to human values. We collect and build datasets and stand up finetuning processes — supervised finetuning, contrastive preference optimization, and model merging — to produce LoRA adapters and full models that robustly hold a specific dharma — a religion or philosophy — without losing capability in every other space. DharmaBench measures how well it worked.

The vision: a recursively-improving, automated system for establishing belief vectors aligned to the core philosophies and religions of humanity. We believe the dialectic of those traditions — held faithfully, each in its own voice — produces an optimal outcome for AGI alignment.
Shipped · Catholic
85 / 100 — the #1 worldview of 25 tradition judges, up from a base of 15.
Shipped · Mahayana v1
Mahayana 30 → 58 — the #1 worldview of 25 judges on the first training run, with the Buddhist family sweeping the top four places.
Recipe · validated
Two stages — distinctive SFT, then contrastive ORPO — now portable to any dharma × model.

What we're actually building

A worldview is not a system prompt. A model that merely recites a tradition when asked is not the same as a model whose un-prompted reasoning, sensibility, and voice come from within that tradition — and which is still exactly as good at debugging your code or planning your week. Dharmatune builds the second thing, and proves it with a hard non-lobotomy gate on every checkpoint.

Gemma 4 12B is our proving ground — a current, permissively-licensed (Apache 2.0) dense model small enough to iterate on daily. The dataset and the recipe are deliberately model-agnostic, so a result proven on Gemma transfers to the next base model by changing two lines of config. The first tradition taken end-to-end is Catholicism — shipped, judged #1 of 25. The second, Mahayana Buddhism, shipped its v1 — #1 of 25 on its first training run. It is also the hardest test of the machine: DharmaBench scores it against four sibling Buddhist judges, the tightest neighbor cluster in the benchmark, and the contrastive stage that separates them is next.

Tradition Stage State
Catholicism v1 → v2 → v3 shipped · v4 in development 85/100 · #1 of 25
Mahayana Buddhism v1 shipped — overarching-Buddhist SFT · contrastive sharpening next 58/100 · #1 of 25
Eastern Orthodoxy · evangelical Protestantism queued — same pipeline
canonical sources extract / chunk grounded dataset contamination gate SFT contrastive (ORPO) merge DharmaBench + gates
Radar charts: 25-faction DharmaBench belief vectors for Catholic v3 and Mahayana v1, each vs its paired baseline
The belief vectors: all 25 faction judges, each tune against its own blind paired-session baseline. Catholic v3 spikes into the Christian/Abrahamic cluster; Mahayana v1 through the Buddhist cluster — while the rest of the field falls away.

How the finetuning works

Data

Per tradition we assemble a corpus from canonical texts (catechisms, councils, dogmatic definitions, scripture) and existing scholarly datasets, then turn it into training records — verbatim where the source is already question-shaped, grounded generation where it isn't. A key lever we learned the hard way: the data must be distinctive to the tradition, not merely pious, or the model drifts toward generic theism. Preference pairs — "this framing, not that one" — come straight out of the sources that are natively contrastive (a conciliar canon literally states the belief it rejects).

Training — one system, any model

We don't reinvent the training loop. The primary stack is TRL + PEFT on the NGC PyTorch container, per NVIDIA's official DGX Spark playbook — the one stack with demonstrated LoRA success on this hardware — with LLaMA-Factory as the YAML-driven controller layer for recipe sweeps. Every run is one reproducible recipe; swapping the base model is a two-line edit. Training happens on one node of a 2× NVIDIA DGX Spark cluster while the other keeps serving, under a thermal watchdog that can kill a runaway job and nothing else.

Evaluation — the non-lobotomy guarantee

Every checkpoint faces four instruments: DharmaBench (a 10-turn worldview interview scored 0–100 by 25 tradition-specific judges, with the official battery quarantined as test data); a regression gate of general-capability and "preachiness" probes; a StoryBench creative-writing gate; and a discriminative read — did the target tradition rise more than its neighbors, or did we just make the model generically reverent? That last question is the one that drives each next version.

StoryBench per-story creative-writing scores: base vs Catholic v3 vs Mahayana v1
The StoryBench gate in action: per-story writing scores for base vs both tunes. Both finetunes trade narrative register for worldview — recovery experiments (adapter scaling, writing patch-tune) are running now.

The labor-distribution protocol

Dharmatune runs on a deliberate division of labor that keeps the expensive model doing the least. The orchestrating model (Claude) plans, decides, and dispatches; a local model (a served Qwen endpoint, "Sparky") does the free, high-volume fetching and generation; Sonnet subagents do the parser, judging, install, and training labor; and the GPU does the actual muscle. The orchestrator is roughly 7% of the operations by design.

Claude · orchestrate
Plans, decides, dispatches, reviews. Never does what a script or a cheaper worker can.
Sparky · local, free
Served Qwen endpoint. Web fetches, source acquisition, bulk generation. $0 API cost.
Sonnet subagents
Parsers, the 25 DharmaBench judges, installs, training runners. The paid labor.
GPU · DGX Spark
SFT, ORPO, merges. The compute muscle, watchdog-guarded.
Chart: operations and tokens by executor — Claude orchestrator, Anthropic subagents, Sparky, GPU
Who does the work — direct operations and recorded tokens per executor, counted from the task queue, session transcripts, and run logs. Each subagent launch, Sparky task, or GPU job wraps many internal operations not counted individually.
Dharmatune-Catholic →
The first tradition taken end-to-end. v1, v2, and v3 — the dataset, the recipe, and the DharmaBench delta charts for each iteration.
open the case study
Dharmatune-Mahayana →
The second tradition, tracked from the start — and the hardest neighbor problem yet (four sibling Buddhist judges). The overarching-Buddhist v1 dataset: 4,443 verbatim records, zero synthesis. v1 judged: Mahayana 58/100, #1 of 25; gates passed.
open the case study

Live project state — corpus counts, generation waves, training runs, and eval gates — is on the operations dashboard. Datasets and model adapters are released on HuggingFace; method and code on GitHub. Traditions are covered on their own terms, with an open invitation to scholars and practitioners of each to review the data and file corrections.