CHANGELOG.md

Changelog

Unreleased (0.3.9) — a q8_0 conversation memory, a faster grammar mask

Two of 0.3.9's three pieces: the KV cache in half the memory, as llama.cpp keeps it with --cache-type-k/v q8_0, and the JSON/grammar mask 13× faster at the median. Each is checked against llama.cpp b11192 as before; 1-bit decode speed, the third, is measured on an idle machine next.

The q8_0 KV cache (BANKML_CACHE_TYPE=q8_0; testing/kv_oracle.py, 6 / 6)

• K and V stored as q8_0 blocks (KvType::Q8_0), 53 % of the f16 cache's bytes. Attention over it is ggml's reference kernel for a non-f16 K (attend_head_q8): Q quantized with the AVX2 quantize_row_q8_0, scores by vec_dot_q8_0_q8_0, V dequantized into an f32 accumulator (vec_mad_f32, vec_scale_f32).
• llama.cpp b11192 rotates around a quantized cache, which the first replay found (2 / 6, the answers drifting after dozens of tokens): Q and K through a Hadamard transform over the head (128), V over 64, and the attention output back (attn_rot_k/attn_rot_v, llama_mul_mat_hadamard, which ggml's CPU computes as a fast Walsh–Hadamard transform). bankML's fwht does the same arithmetic: scale by 1/sqrtf(n), then u + v, u − v.
• oracle_ggml_b11192_q8_0_kv_kernels: against the shipped haswell library (dlopen), 4,000 rows quantized byte-exact and 4,000 dot products bit-exact, saturating maddubs cases included.
• kv_oracle_live: llama-server b11192 with --cache-type-k q8_0 --cache-type-v q8_0 and bankML with BANKML_CACHE_TYPE=q8_0 give the same answers, 6 of 6 (greedy, seeded, a 2,244-token prompt, a 320-token answer, a two-turn conversation; text, counts and cache_n; 567 tokens).
• A slot file records its cache type; one saved with the other type is refused with the reason.

The grammar mask, through a trie (oracle_grammar_masks, both paths)

• A whole-vocabulary mask walks a trie of the vocabulary's code points, built once: each grammar stack meets a shared prefix once, and the stacks after a terminal are computed once per stack and mask. Median 2.94 ms against 38.8 ms (13×), p90 49.3 against 80.6 ms, over the oracle's 1,645 masks. The oracle now computes every mask both ways: 196 / 196 runs, 1,645 / 1,645 masks identical to llama.cpp b11192 by each.

Your own bankML from a web page (--allow-origin)

• bankml serve … --allow-origin ORIGIN lets one named web page call the gateway from a browser: its CORS preflight is answered (with Chrome's private-network grant, as a public page reaching a loopback address requires) and its answers, streamed or not, carry Access-Control-Allow-Origin; any other origin gets none and a 403 preflight. The loopback Host and JSON-POST rules are unchanged. ./install.sh start --space turns it on for the Space (remembered in install.env, applied to the carrier sAGI/models.py starts; --no-space turns it off). It is what lets the bankML Space's page (PYTHAI/bankml) talk to a visitor's own bankML, free, on their own CPU — the way Savante's page reaches a local engine. Checked live: the preflight, plain and streamed answers with the receipt, and another origin refused.

The code audit and the documentation (2026-10-06)

• Comments, professional and short. Every source file's comments were cut to the contract, the invariants, the safety reasoning and the exact upstream behaviour that keeps the bits; the history and rationale moved to its docs/modules/<name>.md page (a new Design notes section where needed). Each header ends with Details: docs/modules/<name>.md. A checker held every non-comment line identical; clippy and rustdoc are clean.
• Fixed by the audit: bankml create accepts PARAMETER typical_p and min_keep (refused as "not reproduced" although 0.3.7 reproduces them); the q8_0 cache rotates only for a head size that is a multiple of 64, as llama.cpp's attn_rot_k/v (128 unchanged, so 6 / 6 stands); bankml_log's %f honours the 65,536 width/precision limit like every other conversion (%.100000000f allocated); the 404 bodies list every route; stale refusal texts (the mirostat message, the C API's header and docs, the train probe stage) and ten comments that misstated the code (slot file layout, the /bankml/usage interval, doc blocks attached to the wrong item…).
• Found, recorded for 0.5.0: the GPU worker destroys nothing on drop (a reload leaks card memory), and Sync for Buffer is wider than it should be (TODO 0.5.0).
• Docs: a full pass over every page against the code (the oracles table now lists every gate stage; TECHNICAL, BUILD_HISTORY, OLLAMA, CAPI, usage and install brought to 0.3.9); docs/thesis.md, the bankML thesis; 48 Markdown files, every link and anchor resolving.

Unreleased (0.3.8) — the serving contract: the context limit, slots, the prompt cache, logprobs

bankml serve --native now behaves as llama-server b11192 at the edges a client meets in production: a prompt that does not fit, a slot saved and restored, conversations that take turns, and the probabilities behind each token. Each is checked against llama-server's own answers, as everything before it.

The context limit (testing/context_oracle.py, 8 / 8)

• With context shift off (llama-server's default), a generation that fills the context stops there with finish_reason "length", and a prompt that does not fit is refused before any work with llama-server's 400 body: {"error": {"code": 400, "message": "request (N tokens) exceeds the available context size (M tokens), try increasing it", "type": "exceed_context_size_error", "n_prompt_tokens": N, "n_ctx": M}}. Eight requests from a few tokens to past the context, at --ctx 256: the same text, counts, finish and refusal bodies.

Slots: save, restore, erase (testing/slot_oracle.py, 19 / 19)

• POST /slots/0?action=save|restore|erase on the engine address, as llama-server's slot API, with --slot-dir DIR (created at start). Replies carry n_saved / n_written / timings.save_ms, n_restored / n_read / timings.restore_ms, n_erased; refusals are llama-server's (501 without a slot directory, "Invalid slot ID", "Invalid action", "Invalid filename" by its fs_validate_filename rules, "Unable to restore slot: …").
• The file: a magic line, the model's sha256, the context and token counts, each layer's K and V (f16) and the tokens, then a sha256 of all of it; written to a temporary name and renamed. A file from another model, or damaged by one bit, is refused and the slot emptied — never half-filled; the next answer recomputes its prompt.
• The oracle is the engine itself: the answer after a restore — in the same server and after a restart — equals the answer from an empty slot, and the restore skips the prompt (cache_n > 0). n_saved counts as llama-server counts: the prompt and every generated token but the last.
• Savante and the console pass --slot-dir to the native engine, so a warm start survives a restart.

One slot, and llama-server's host prompt cache (testing/session_oracle.py, 14 / 14)

• The single-slot contract, stated and checked: requests are served one at a time, as llama-server -np 1 (Savante's flags). Four requests sent at once are all answered, none refused or mixed, each with the text it gets alone.
• bankML/prompt_cache.rs: llama-server's --cache-ram cache (on by default there). When a request shares little with the slot, the slot's tokens and KV rows go to RAM, and a cached state that keeps more of the prompt comes back. Three conversations taking turns (A1 B1 C1 A2 …) now match llama-server turn by turn: text, counts and cache_n. Before, each turn found only the system prompt in the slot, so prefill started elsewhere and the answers differed.
• BANKML_CACHE_RAM (MiB, as --cache-ram: 0 off, -1 no limit); unset, 8192 MiB but at most a quarter of the memory available at load.

Docs and tools

• docs/why-bankml.md: the plain-language version (advantages, uses, how Rust helps, the road ahead), dated 2026-10-06; published as a web page over the DeltaVerse substrate at deltaverse.pythai.net/bankml.
• tools/makecards.py: a page's share cards (1200×630, 1200×1200, a 180 px touch icon) with the DeltaVerse $. tools/seo.py: audits a page or URL as a crawler and a link preview read it — the meta set, a canonical that must not redirect, JSON-LD, and each card's real size against its declared one (standard library only). The bankML page: 47 / 47.

Logprobs on /v1/chat/completions, streamed or not (testing/logprobs_oracle.py, 14 / 14)

• logprobs: true with top_logprobs (default 20) → choices[0].logprobs.content: per token its id, token, bytes, logprob, and the top tokens with theirs. Every logprob is the same 32-bit float as llama-server's: get_token_probabilities ported — a partial sort of the whole vocabulary (libstdc++'s, from 0.3.7), the softmax in that order, logf.
• llama-server's entry rules, reproduced: a token gets an entry only once the text has no incomplete UTF-8 after it, and carries the text sent since the previous entry; a stop word drops its own tokens' entries; control tokens read ""; a top token holding part of a character is cut at the incomplete end (validate_utf8), other invalid bytes read U+FFFD, bytes raw. top_logprobs without logprobs is refused with llama-server's message.
• Streamed, as llama-server's partial responses: the stream opens with the role delta, and each whole token's entry rides on the chunk its text makes (a token that sends no text sends no entry: a held stop-word prefix, the end-of-turn token with nothing held back). Text now waits for a whole token in every stream, as llama-server sends nothing while UTF-8 is incomplete (" 🍕" is one chunk, not " " then "🍕"). Five streamed cases, every chunk's delta and entry identical. The engine reports each step (Native::complete_with, Step); NativeChat::run_steps makes the chunks.
• Not served: /completion (llama-server's own endpoint, so also its n_probs); clients use /v1.

Unreleased (0.3.7) — the whole sampler chain; bankML measures itself; the GPU limiter; the bankML console

Every sampler in llama-server b11192's default chain is now reproduced, token for token: after 0.3.6's penalties, typical-p, top-n-σ, XTC, dynamic temperature and DRY. A request that sets any of them gets llama-server's answer instead of a refusal; what llama-server clamps is clamped, what it refuses is refused with its message. bankML now measures itself — time to first token on every answer, prompt and generation speed, CPU, memory, the GPU and, where the operator allows it, power and joules per token — limits its GPU to a share of the card's memory and time and lets each matrix shape decide whether the card pays, and has a console in which it answers as itself, from those measurements.

Measurement: what bankML knows of itself

• bankML/metrics.rs: one record per completion, taken inside the engine — TTFT, prompt and generation tokens per second (llama-bench's pp and tg), grammar time, and the CPU package's energy and joules per generated token when RAPL is readable; null, never estimated. A ring of 256 at GET /bankml/metrics, with totals.
• The receipt's ttft_ms is set for non-streamed answers too (it was null); /v1 answers carry llama-server's timings fields (prompt_n, prompt_ms, prompt_per_second, predicted_n, predicted_ms, predicted_per_second, cache_n).
• GET /bankml/usage adds package_watts (RAPL over the sampling interval, its wrap handled), each GPU's busy %, VRAM and GTT from sysfs, and the GPU limiter's state.
• ./install.sh power (opt-in, the only step that uses sudo): a udev rule lets a rapl group that the user joins read the energy counter, which the kernel has kept root-only since PLATYPUS (CVE-2020-8694); it says so and asks first; --remove undoes it.

The GPU: a limit, and per-shape calibration

• BANKML_GPU_LIMIT (default 0.8): bankML's GPU buffers stay within that share of the heap they come from — on an integrated card, of the RAM they could use — and after a dispatch of d the card rests d·(1−L)/L; a matrix that does not fit, or a product arriving while the card rests, runs whole on the CPU. Never a wait, the same bits.
• Per-shape calibration: each matrix shape's first products alternate between the card's share and the CPU alone, timed in the real pipeline; the faster median is kept and a shape decided for the CPU frees its buffers. Measured on the Vega 3 (Bonsai-1.7B, interleaved A/B, 4 rounds, the same answer every time): with one global share the card cost 18 % (10.40 → 8.51–8.58 tok/s); per shape, 10.36 off against 10.30–10.38 on — neutral, as an integrated card that shares decode's memory bandwidth can be; card memory 66 → ~13 MB.

bankML as itself: the persona and the console

• sAGI/personas/bankml.persona: bankML speaking as itself, projected from the README, the Thesis and the oracles (doctrine root 0x4d5ef2d9…; adopts and verifies). Its knowledge of its own use comes only from a measured SELF block, rendered as sentences with units (a bare key was read as seconds in testing).
• sAGI/console.py (port 7875, loopback only): Interaction (the streamed answer and its receipt checked against the text), Admin (CPU threads, RAM budget and GPU limit sliders — one verified restart with rollback — and D3 charts of what bankML measured), Logging (every exchange with its timings and receipt), Infotags (ERC-721 metadata for an iNFT publication: the model, the persona and its doctrine root, an RFC 6962 root over the exchanges, CIDs). Standard library only, a strict CSP, same-origin JSON POSTs; D3 v7.9.0 vendored with its ISC licence. testing/test_console.py.

Measured

• oracle_samplers (testing/penalty_oracle.py --kind sampler, llama-server b11192 from an empty cache; 23 variants × 4 prompts: each sampler alone, typical-p before top-p and min-p's unsorted path, XTC with a clamped probability and a disabling threshold, dynamic temperature at 0, DRY with defaults, custom breakers and with the repeat penalty, all five at once): mindx-gen39 76 / 76 answers token-identical (3,576 tokens), Bonsai-1.7B 76 / 76 (2,587 tokens), Bonsai-8B 76 / 76 (2,361 tokens, oracle_samplers_8b); 16 / 16 refusals on each, with llama-server's message.
• oracle_std_sort (testing/sort_oracle.cpp, libstdc++'s own std::sort): 876 / 876 orders identical — sizes 0 to 1,000, heavy ties, sorted, reversed and equal keys — the order typical-p's unstable sort leaves equal scores in.

Added

• sampler.rs: each sampler as src/llama-sampler.cpp writes it, in the default order (penalties, DRY, top-n-σ, top-k, typical-p, top-p, min-p, XTC, temperature, dist), with llama.cpp's sorted state tracked through the chain (typical-p leaves the set unsorted, so top-p sorts after its softmax and min-p takes its unsorted path); XTC's own mt19937 and its float draw (generate_canonical<float, 24>: one 32-bit output); top-n-σ's squares in double (C++'s pow(float, 2)); dynamic temperature's float entropy; DRY's restart sequences, reverse Z-algorithm and libm pow; libstdc++'s std::sort (introsort) and generic heaps; Params::default = common.h.
• native.rs: the request fields typical_p, top_n_sigma, xtc_probability, xtc_threshold, dynatemp_range, dynatemp_exponent, dry_multiplier, dry_base, dry_allowed_length, dry_penalty_last_n, dry_sequence_breakers; llama-server's soft limits clamp (top_p, min_p, the XTC fields to [0, 1], temperature to ≥ 0), a dry_base below 1 falls back to 1.75; DRY's breakers are built from the vocabulary's pieces once per breaker list and cached on the engine.
• On Ollama's API typical_p is honoured; DRY, XTC, top-n-σ and dynamic temperature are not Ollama options, so they come through /v1 (and the C API).

Changed

• Refused instead of ignored: mirostat on /v1 (the Ollama path already refused it) and a custom samplers order — llama-server would act on either, so answering without them would not be its answer.

0.3.6 — 2026-10-04 — the penalties: llama-server's repeat, frequency and presence penalties (O2)

repeat_penalty, repeat_last_n, presence_penalty and frequency_penalty are no longer refused: bankML applies them as llama.cpp b11192's llama_sampler_penalties does, and its answers are token-identical to llama-server's. The coach's ollama_predict (temperature 0, repeat_penalty 1.3) and mindXtrain's imprint gate (repetition_penalty 1.3) can now run on bankML. Greedy at 1.3, mindx-gen39 answers instead of degenerating into ,,,,. Record: testing/results/0.3.6.txt: one run to json_schema_oracle_live, where the Vega 3 worker's memory (taken from the laptop's RAM) stalled it; the three stages left ran next from the same tree and build with BANKML_GPU=off, marked in the record. 0.3.7 adds a GPU limiter for this (BANKML_GPU_LIMIT).

Measured

• oracle_penalties (testing/penalty_oracle.py, llama-server b11192 from an empty cache, greedy and seeded; 17 variants × 4 prompts made to repeat): mindx-gen39 56 / 56 answers token-identical (2,478 tokens), Bonsai-1.7B 56 / 56 (1,895 tokens); each 12 / 12 refusals with llama-server's message (repeat_last_n −1, a repeat penalty of 0 or below); Bonsai-8B 56 / 56 (1,568 tokens, oracle_penalties_8b), 12 / 12 refusals.

Added

• sampler.rs: the penalties, first in the chain and again on a grammar's redraw; the window as llama-server fills it — every prompt token, cached or not, before the first draw (server-context.cpp), then each token drawn (Sampler::accept); the logit divided by the repeat penalty when positive, multiplied when not, then count × frequency + presence taken off; disabled as llama.cpp disables it (last_n 0, or all neutral). general.sampling.penalty_last_n and penalty_repeat read from the GGUF as llama.cpp reads them (none of the five native models sets them).
• The surfaces: /v1 and /api/* (repeat_last_n moves from the ignored resource options to the honoured ones), a Modelfile's PARAMETER, the C API (through the same engine). bankml generate --sample applies them too, but has no flags for them: only a GGUF's own general.sampling.penalty_* defaults reach it (none of the five models sets one).
• testing/penalty_oracle.py (record, and --bankml live); oracle_penalties, oracle_penalties_8b and penalty_oracle_live in the gate. Live on mindx-gen39: 85 / 85 through /v1 (top-level fields) and /api/chat (options), refusals included.

Fixed (found by the live oracle)

• A sampler refusal on /v1 answered 500. A negative repeat_last_n or a repeat penalty of 0 or below reached the engine before it was checked; the Ollama path already refused it up front. /v1 now refuses it as llama-server does: a 400 with its message.

0.3.5 — 2026-10-03 — JSON schemas, and bankml create: mindX's persona layer, natively (O6b, O5)

Any JSON schema now gets the grammar llama-server b11192 builds for it, on the model's own template, and the answers are token-identical to llama-server's. And mindX's own model can be made the way mindX makes it for Ollama: bankml create takes mindXtrain's merged safetensors and promote.py's persona Modelfile, and the created mindx-gen39 answers the user's turns exactly as llama-server answers the same GGUF given that persona. Phases O6b and O5 (first cut) of docs/OLLAMA.md; built on two branches and merged here. Record: testing/results/0.3.5.txt. The gate run was stopped by the development session's memory guard, not by a failure, as json_schema_oracle_live began (the Vega 3 worker's memory comes out of the laptop's RAM); the three stages left ran next from the same tree and build with BANKML_GPU=off, and the record marks where. The first run also found the ternary schema record had never been taken; it was recorded from llama-server b11192 and passes, 11 of 11.

Measured

• Schema grammars (oracle_schema_grammars, llama.cpp's own json_schema_to_grammar and common_chat_templates_apply in the release's libllama-common.so, no model): 173 schemas (llama.cpp's 81 test cases, Pydantic-shaped schemas like mindX's, edge cases) on each of the three templates — 148 grammars byte-identical bare and on the chat path, every refusal with llama.cpp's message (24 bare, 20 chat).
• Answers under schemas (oracle_json_schema, _ternary, _o4; llama-server b11192 greedy and seeded, each from an empty cache): Bonsai-8B 28 / 28, Ternary-Bonsai-8B 11 / 11, Bonsai-1.7B, SmolLM2-135M-Instruct and mindx-gen39 56 / 56 each — objects, enums, ranges, $defs, a pattern, a date format, top-level arrays, enums, strings, integers and numbers, and answers cut by max_tokens inside an object, a top-level string and a number. Live: /v1 (one streamed) and Ollama's /api/chat with format: <schema>.
• The content rule (oracle_json_content, llama.cpp's common_chat_parse itself): every prefix of every recorded constrained answer and edge cases, 30,063 of 30,063 texts on each template.
• mindX's persona, end to end (oracle_persona_layer, testing/persona_oracle.py): promote.py's persona_modelfile_layer Modelfile (mindX's persona as SYSTEM, stop <|im_end|>, num_ctx 2048), created FROM the merged safetensors directory and, unchanged, FROM mindx-gen39 in place: 27 / 27 answers each token-identical to llama-server given the persona as the system message; live through /api/chat, /api/generate and /v1, and /api/ps names mindx-gen39:latest.
• The converter, run against llama.cpp's directly (b11192's convert_hf_to_gguf.py, torch 2.14.1+cpu): the same bytes as bankml convert on freshly downloaded mindx-gen39 (6b64c748…, the pin) and SmolLM2-135M-Instruct (ec30a679…). Until now the identity rested on O4's conversions.
• The name heuristics (gguf-py/metadata.py) agree with gguf-py on 168 of 168 Hub-style ids (oracle_name_heuristics).

Added

• bankML/schema.rs: llama.cpp b11192's common/json-schema.cpp and json-schema-to-grammar.cpp (MIT, attributed; zero crates), nlohmann's JSON as the grammar text depends on it, and the chat parser's wrapping — the Qwen3 template's (with the until-13 reasoning rules) and the ChatML templates' (none), as llama.cpp writes each. Wired: response_format json_schema and json_object + schema, the top-level json_schema, Ollama's format: <schema>, bankml_chat. The schema is read from the request's own text (1.0 stays a float). Refused as b11192 refuses, with its message; and one deliberate divergence: a pattern with a non-ASCII character before a quantifier, which llama.cpp turns into a grammar that is not UTF-8, is refused.
• bankML/convert.rs, bankml convert: safetensors → GGUF F16 for the Llama architecture as SmolLM2 uses it, byte-identical to convert_hf_to_gguf.py --outtype f16; what would make llama.cpp write something else is refused with the reason.
• bankML/create.rs, bankml create, POST /api/create, DELETE /api/delete (derived models only), POST /api/copy: Ollama's Modelfile parser state for state; a derived model is <registry>/<name>.MODEL.json, a layer (SYSTEM, PARAMETER, stop, MESSAGE, licence) over a pinned base, verified through the base on every load; the layer applied as Ollama applies it; /api/show gives the Modelfile back. FROM a safetensors directory converts and pins it.
• Oracles: testing/schema_oracle.{cpp,py} (now all three templates), testing/json_schema_oracle.py (now every native model, and length cuts), testing/content_oracle.{cpp,py}, testing/persona_oracle.py, testing/convert_oracle.py; the gate runs them.
• mindXtrain (huggingface.co/PYTHAI/mindXtrain, archived source github.com/Professor-Codephreak/mindXtrain) is linked from the README, OLLAMA.md and the train/ and convert.rs headers: bankml convert and create replace its serve --to ollama path for mindX.

Fixed (found by the new oracles)

• A schema on a ChatML template got the Qwen3 grammar. The O6b branch wrapped every schema as the Qwen3 template does; on SmolLM2's and mindx-genN's templates llama.cpp writes no reasoning rules and another root. bankML now builds the grammar on the model's template (the schema oracle checks all three).
• The content of an answer cut inside an escape: llama.cpp's parser ends the string before an unfinished \ or \uXX; bankML kept it (12 of 29,973 texts differed before the fix).
• A non-streamed answer whose parse is empty (cut inside or right after the opening fence): llama-server answers with the raw text; bankML answered "" (pi seeded on Bonsai-1.7B: "```json\n\n"). grammar::json_message.

Changed (O5's two open gaps, closed)

• num_ctx as Ollama applies it (read from Ollama v0.13.3's server/prompt.go): under a request's or a layer's num_ctx, a conversation that does not fit loses its oldest messages first (native::fit_messages, Ollama's loop step for step); what still does not fit is refused with the reason, since Ollama would cut tokens out of the middle of the prompt. Tokens past num_ctx during an answer still differ: Ollama shifts its cache, bankML does not.
• /api/ps names the derived model (its digest, parent_model, the request's context), as Ollama names a runner after the model that loaded it.
• A derived model's name wins over the registry's suffix-less alias, and FROM resolves that alias, so promote.py's re-create in place (FROM mindx-gen39 as mindx-gen39) works; a conversion never overwrites an existing pin.

Found

• The converter's bytes depend on the directory's name, for llama.cpp and bankML alike: general.name comes from it. gen39 converted from a directory named merged is bb41f62d…, from mindx-gen39 the pin 6b64c748….
• gen39's tokenizer.json lost SmolLM2's Digits pre-tokenizer when transformers 5.8 re-saved it; llama.cpp's chkhsh still names it smollm (the vocabulary has no multi-digit tokens), and bankML accepts both shapes.

Not in this release

• ADAPTER (LoRA) in a Modelfile: merge first, then FROM the merged directory. Tool calls (O6).
• Next: O2, the penalty samplers. mindXtrain's bankml backend (proposed) found that mindx-gen39 degenerates into repetition (,,,,, ?||) without a repetition penalty; its imprint gate decodes with repetition_penalty 1.3 and no_repeat_ngram_size 3, which bankML refuses until each has an oracle.

0.3.4 — 2026-10-02 — mindX's own model, natively: the Llama graph, F16, tied embeddings (O4)

mindX serves its own trained lineage, mindx-genN, through Ollama. Generation 39 (mindXtrain39, the last accepted generation: SmolLM2-135M + its LoRA, merged, F16) is now answered by bankML's own forward pass, token-identical to llama-server b11192 — greedy, seeded, on /v1, on Ollama's /api, through the C API and in JSON mode. So are SmolLM2-135M-Instruct and Bonsai-1.7B, which was refused until now only because its embeddings are tied. Phase O4 of docs/OLLAMA.md, with the F16 part of O3. Record: testing/results/0.3.4.txt.

What llama.cpp does, read from its source (b11192, 171e8846b)

• F16 weights take two paths, chosen by the product's shape (ggml_compute_forward_mul_mat). The activation is rounded to f16 first (F16's vec_dot_type). With one column (a decode step, the logits, a one-token micro-batch) llamafile_sgemm refuses (n < 2) and every element is ggml_vec_dot_f16: four 8-lane FMA accumulators over 32-element steps, then a fixed reduction, any tail summed in double. With two or more columns llamafile_sgemm runs tinyBLAS<8, __m256>: each element one 8-lane FMA chain over the row and its own hsum — other bits — whenever the weight has a multiple of 4 rows and the row a multiple of 8. The two differ, so a prompt's micro-batch and a decode step must each take their own.
• The last layer of a prompt only computes the rows that are output (inp_out_ids): llama-server asks for the last token's logits, so the last layer's feed-forward block is a one-column product there. For the quantized types that changed nothing; for F16 it decides the bits.
• Tied embeddings: with no output.weight, the loader duplicates token_embd (TENSOR_DUPLICATED) and the logits are that table times the final row.
• The Llama graph (llm_build_llama): no Q/K norms, RoPE in NORM mode (rotate_pairs on adjacent pairs, the same contracted arithmetic as NEOX), no YaRN (ext_factor 0, attn_factor 1), GQA from the header.
• SmolLM2's pre-tokenizer (smollm) is two passes: every digit cut out alone (a std::regex over the collapsed text), then GPT-2's pattern inside each piece, where the end of a piece is the end of the text. Its vocabulary has no token for 21 bytes; llama-vocab drops them.
• llama-vocab overrides the file's token types by text: every end-of-generation name and the fill-in-the-middle token of each role become CONTROL. In the Qwen3 vocabulary </s> (token 128247) is NORMAL in the file and CONTROL in llama.cpp, so the text </s> is cut out as one special token.

Added

• bankML/f16.rs: ggml's two F16 products, each a scalar definition and an AVX2 + FMA + F16C path with the same bits (tinyBLAS's own 4 × 3 register blocking for prompts); mat_mul_par chooses the path as ggml does.
• forward::plan: from the header alone, the architecture (qwen3, llama), the weight type (Q1_0, Q2_0_g64, F16), the logits matrix (tied or not), and a refusal with the reason for everything else: other architectures, other types, mixed types, biases, fused QKV, rope factors, experts, Q/K norms on Llama, RoPE scaling on Llama, partial RoPE, a head width that is not a multiple of 32.
• The Llama graph in forward.rs (NORM RoPE, no Q/K norms) and tied embeddings for both architectures.
• The smollm pre-tokenizer in tokenizer.rs; a byte without a token is dropped as llama.cpp drops it.
• Chat templates per model (chat::TEMPLATES, each pinned by the sha256 of its text): Bonsai / Qwen3, SmolLM2-Instruct's (ChatML with a default system message), and the plain ChatML mindx-genN carries. Ollama's persona SYSTEM for mindx-genN lives in its Modelfile, not the GGUF: here it is the caller's system message (bankml create is O5).
• JSON mode on ChatML templates: llama-server builds another grammar there (its root opens with <|im_start|>assistant\n and has no <think> block); grammar::json_object_grammar picks the template's, checked against the server's own report on every recorded request.
• The models, pinned (sAGI/models.py CONVERTED, pin_converted): no F16 GGUF is published for either, so each is converted from its pinned safetensors by llama.cpp b11192's own convert_hf_to_gguf.py --outtype f16 (unmodified). The conversion is reproducible (twice, the same sha256), and every tensor was checked against the safetensors rounded to f16. The FORK.json records the source's LFS sha256, the revision and the tools.
  • SmolLM2-135M-Instruct-F16.gguf e9aba089…5a222 from HuggingFaceTB/SmolLM2-135M-Instruct@12fd25f7 (model.safetensors 5af571cb…), Apache-2.0.
  • mindx-gen39-F16.gguf 6b64c748…58266 from the dataset PYTHAI/mindXascension@4bd31b9d (weights/gen39/ollama_push/merged/model.safetensors 19b62829…), Apache-2.0 (the dataset card; the base is SmolLM2-135M).
• Registry aliases: a name without its weight-type suffix resolves when one pin has that base, so Ollama's tag mindx-gen39 reaches mindx-gen39-f16.
• Oracles, in the gate:
  • oracle_ggml_b11192_f16 (testing/f16_oracle.py): the shipped library's mul_mat on SmolLM2's real F16 matrices and on synthetic shapes for the tails and the fallbacks — 211 of 211 tensors widened bit-exact, 552,268 of 552,268 elements bit-exact (61 products through tinyBLAS, 26 through ggml_vec_dot_f16).
  • oracle_forward_model_bonsai_1_7b, oracle_forward_model_llama_f16: the whole model (every layer, result_norm, logits) bit-exact — Bonsai-1.7B 840 of 840 rows, SmolLM2-135M-Instruct and mindx-gen39 800 of 800 each.
  • oracle_tokenizer_smollm 4,346 of 4,346; oracle_chat_template_chatml 317 of 317 on each template.
  • oracle_llama_server_llama_f16, oracle_llama_server_bonsai_1_7b: llama-server's tokens — greedy on short, long (the tiled kernel, tinyBLAS over the micro-batch) and deep prompts (the split-KV kernel), and seeded sampling: SmolLM2 6 / 6 / 3 and 40 of 40; mindx-gen39 6 / 6 / 3 and 40 of 40; Bonsai-1.7B 6 and 40 of 40.
  • oracle_native_serve_o4: the Savante conversations (9 of 9 turns each) and JSON mode (23 of 23 answers each) on the three models.
  • Live: serve_oracle.py --bankml and json_oracle.py --bankml on each (mindx-gen39 asked for as mindx-gen39), and the C API's bankml_chat against each model's llama-server record.

Fixed

• The tokenizer took </s> in the Qwen3 vocabulary as plain text. llama.cpp makes it a CONTROL token by its name, so with special tokens parsed it is one token there and three here. The old oracle corpus never contained it; the corpus grew with the docs and the oracle caught it (2 of 4,346 cases). bankML now applies llama-vocab's type overrides; a vocabulary where they are ambiguous, or whose header sets FIM ids, is refused.
• A vocabulary whose merges name a string outside it is refused: llama.cpp merges by text, bankML by id.

Changed (faster, the same bits)

• Attention (every model): the reference kernel's f16 dot, scale and accumulate run on F16C + FMA; the tiled kernel is compiled with FMA and F16C and widens each 64-cell tile once per block of 16 rows; heads (and rows) run on the pool. Each head is still computed whole by one thread in llama.cpp's order.
• Tensor lookups by name are a hash map, and the norm vectors are read once at load.
• The 8B models gained most: the same gate oracles ran in about half the wall time (Bonsai-8B conversations 400 → 192 s, deep greedy 756 → 320 s, JSON mode 901 → 541 s; ternary JSON 454 → 242 s), with the matmul budget unchanged — the old reference attention converted every f16 value in software. Gate wall times, not a controlled benchmark.
• Speed, SmolLM2-135M-Instruct F16, laptop (Ryzen 3 3200U), 3 threads each, paired: decode 38.0–38.9 tok/s vs llama-server's 40.4–42.7 (about 0.93×); an 858-token prompt in 8.6–9.6 s vs 7.8–8.6 s, then decode at ~900 cells 27.2–30.1 vs 20.2–29.9 tok/s. Bonsai-1.7B decode 8.4–8.6 vs 10.6–10.9 tok/s (the known 1-bit decode gap, O8). docs/PERFORMANCE.md has the table and a rejected experiment.

Not in this release (refused, with the reason)

• Q8_0 (Qwen3-0.6B, mindX's qwen3:0.6b pin): from the source the kernels look cheap (ggml's AVX2 vec_dot_q8_0_q8_0 and tinyBLAS's Q8_0 path appear to share their per-block arithmetic; not built, not measured), but that file's template is Qwen's own, which renders 4 of 317 oracle conversations differently from the Bonsai template (reasoning rules). It stays refused ("weights are Q8_0 … O3") until its template has an oracle.
• BF16, Q4_K and other architectures: refused by forward::plan, as before.

0.3.3 — 2026-10-02 — JSON mode, token-identical to llama-server

mindX's most common request that bankML refused, format: "json", is now answered natively. The answer has the same tokens llama-server b11192 gives under the same request, greedy and seeded. O6's first cut (docs/OLLAMA.md). Record: testing/results/0.3.3.txt.

What llama-server does, read from its source (b11192, 171e8846b)

• The grammar is not grammars/json.gbnf. On the jinja chat path (Savante's flags), response_format: {"type": "json_object"} becomes the schema {"type": "object"}. The chat layer turns the schema into a PEG parser (common/chat-auto-parser-generator.cpp), and that parser into GBNF. The GBNF's root begins with the template's generation prompt, then allows an optional ```json fence around the object.
• The grammar is prefilled. It is typed as a tool-call grammar, so common_sampler_init accepts the generation prompt's 7 tokens into it before the first draw (common_grammar_needs_prefill).
• The sampler draws, then checks, then redraws. common_sampler_sample (grammar_first = false) runs the whole chain on the raw logits. If the token it picks passes the grammar, it stands. If not, the logits are reset, every rejected token goes to −∞, and the chain runs again: a second draw from the same mt19937.
• The end set is wider. An end-of-generation token passes only when the grammar is complete, and llama-vocab's end set on Qwen3 is 6 tokens: <|endoftext|>, <|im_end|>, <|fim_pad|>, <|repo_name|>, <|file_sep|> and token 128247 </s>. One recorded answer ends on <|file_sep|>.
• The content is the value alone. The answer's content is the JSON value, without the fence or the space around it.

Added

• bankML/grammar.rs: llama.cpp's grammar engine, ported (MIT, attributed with its notice; no crates). It holds:

  • the GBNF parser (literals, classes, ., token terminals <…> !<…> <[id]>, groups, * + ? {m,n}, comments);
  • the reference and left-recursion checks;
  • the pushdown stacks and advance_stack;
  • reject_candidates over code points, with partial UTF-8 carried across tokens;
  • accept and apply, with the end rule.

  It also carries the server's JSON-mode grammar (a constant the oracle checks against the server's own report) and its prefill, the request resolution of oaicompat_chat_params_parse, and the content rule.

• Sampler::sample_constrained: the draw, the check and the masked redraw, in the server's order.

• Surfaces. All of them use one engine path (Native::grammar, Native::complete):

  • /v1/chat/completions: response_format (json_object, json_schema with schema {} or {"type": "object"}), the top-level json_schema, and grammar (any GBNF; a user grammar, not prefilled);
  • Ollama's /api/chat and /api/generate with format: "json";
  • the C API's bankml_chat;
  • bankml generate --json.

  A stream sends the content's growth.

• Oracles, in the gate:

  • oracle_grammar_masks (testing/grammar_oracle.cpp + .py) drives libllama b11192's public grammar sampler on the pinned vocabulary. All 151,669 token pieces and the end set are identical. Then 196 of 196 runs over 12 grammars are identical: llama-server's JSON grammar with its prefill, every grammar in llama.cpp's grammars/, and three written for token terminals, edges and UTF-8. Each input goes in tokenized and byte by byte. That is 1,645 of 1,645 whole-vocabulary masks and 116 of 116 rejection points.
  • oracle_json_mode and oracle_json_mode_ternary (testing/json_oracle.py --record) replay llama-server's answers under response_format: json_object. The prompts invite JSON or tempt prose and code; one is a nested object and one is unicode. They run greedy and seeded at 0.7, 1.0 and 1.3, plus two user grammars, each from an empty cache. The results: Bonsai-8B Q1_0 23 of 23 (860 tokens, 152 of them redrawn under the mask), and Ternary-Bonsai-8B 13 of 13 (534 tokens, 49 redrawn). The same token ids, end token included, and the same raw text, content, finish and counts.
  • json_oracle_live (testing/json_oracle.py --bankml) runs a live serve --native through /v1 (streamed once), grammar, and /api/chat with format: "json": 8 of 8.

Changed

• The end of an answer is llama-vocab's whole end set (6 tokens), not <|im_end|> and <|endoftext|> alone, with or without a grammar. Before this, an answer that sampled <|file_sep|> would have run on where llama-server stops.
• response_format on serve --native's /v1 was silently ignored before (an unconstrained answer; the proxy mode always passed it to llama-server). It is now honoured, or refused with the reason.
• serve::Json derives Clone. native::Done carries the generated token ids, the time spent in the grammar and the number of redraws.

Still refused, with the reason

• A JSON schema other than {} or {"type": "object"}, in response_format, json_schema or Ollama's format: llama.cpp's json_schema_to_grammar and its chat-parser wrapping are not ported (O6, next).
• format with raw: true, because JSON mode's grammar starts with the template's generation prompt; response_format or json_schema together with grammar; tools.

Measured

• Grammar cost (PERFORMANCE.md, "JSON mode's cost"):
  • one whole-vocabulary mask over 151,669 tokens costs a median of 24.2 ms (p90 47.0, max 101.0) across 1,645 masks;
  • spread over real answers, the grammar costs 3.90 ms per token on the 1-bit model (152 of 860 tokens redrawn) and 3.95 ms on the ternary model (49 of 534). That is about 1 % of a decode step.
• The rest of the gate, against 0.3.2. No kernel changed, and every bit-exact oracle passed again: tokenizer 4,258/4,258, template 317/317, whole model 1,064/1,064 for both models, greedy 6/6, 6/6, 6/6 long and 3/3 deep, sampling 40/40, native serve 9/9, the Ollama shape 9/9, the C API 9/9 + 9/9, and printf 47/47.
  • The decode budgets read faster than in 0.3.2's gate because the laptop was quieter, not because of the code. 1-bit: bankML 0.641 s/token at 1 thread (0.3.2: 0.677) and 0.389 s at 3 (0.3.2: 0.787, under load). Ternary: 0.436 s at 1 thread (0.477) and 0.279 s at 3 (0.394), 9.62× and 8.36× ahead of ggml b11192.

0.3.2 — 2026-10-01 — a C API, on Rust 1.99

bankML is now also a C library, libbankml, with one hand-written header. A program that embeds it gets the same verification as bankml serve and the same answers and receipts as serve --native. Its printf-style log is a C-variadic function defined in Rust, which Rust 1.99 stabilized. The toolchain moves to Rust 1.99. The gate's bit-exact oracles are what show that the compiler upgrade changed no bits. Record: testing/results/0.3.2.txt.

Added

• capi/ (package bankml-capi): libbankml.so and libbankml.a, declared in capi/include/bankml.h, documented in docs/CAPI.md. It is a second workspace member, and its only dependency is the bankml crate, by path. The workspace still has no external crate, and the licence is MIT OR Apache-2.0.
  • bankml_open(model, fork_json, n_ctx, &err) runs serve's verification: the guard, the sha256 pin, the file-identity check across the hash, and the native check. A refusal returns NULL with serve's reason, for example Bonsai-1.7B's tied embeddings, or a file its FORK.json does not pin.
  • bankml_chat(h, request_json, cb, user, &result_json) takes the OpenAI / llama-server chat request and refuses what serve --native refuses. It streams whole UTF-8 pieces to cb (return 0 to stop), and returns the /v1/chat/completions object with usage, timings.cache_n and the same bankml_receipt. The request also hits the slot's prompt cache, as -np 1 does.
  • bankml_close, bankml_free and bankml_version.
  • The rules: error codes, never an unwind into C, NULL-safe; one slot per handle, so calls serialize; returned strings are freed with bankml_free.
• bankml_set_log and bankml_log(level, fmt, ...), defined in Rust with mut args: ....
  • The formatter (capi/src/printf.rs) reads each argument with VaList::next_arg::<T>() at the C type its conversion names.
  • It supports %d %i %u %x %X (with hh h l ll z), %f %F %lf, %c, %s, %p and %%, with the flags - + space # 0 and a width and a precision (numbers or *).
  • Anything else is written as %<unsupported:SPEC> and never guessed. After an unknown conversion no argument is read (%<skipped:SPEC>), and %n never writes.
  • The library's own messages (a model verified, the GPU) go to the same sink, through a small hook in the core: bankml::log and bankml::set_log_sink. It writes to stderr, as before, unless an embedder installs a sink.
• The C API's oracles, in the gate (testing/capi/, compiled with the system cc):
  • printf oracle: bankml_log against libc snprintf, byte for byte, 47 of 47 formats identical, 17 of 17 unsupported cases marked, %n never written;
  • capi chat oracle: bankml_chat is identical to serve --native on 9 of 9 Ternary-Bonsai-8B turns (text, streamed pieces, counts, cache reuse, finish, and the receipt's response, request and model sha256), and to llama-server b11192's record on 9 of 9 Bonsai-8B Q1_0 turns. Bonsai-1.7B and an unpinned file are refused with serve's reasons, and the library's own log reaches the installed sink;
  • the formatter's Rust unit tests: a typed-queue model, and the variadic function called from Rust against snprintf.

Changed

• Rust 1.99.0, pinned in rust-toolchain.toml, with rust-version = "1.99" in both manifests. rustup fetches it; the machine's default toolchain is untouched. install.sh checks for 1.99.
  • 1.99's clippy adds one lint, chunks_exact_to_as_chunks, at 29 sites: the kernels' block loops, the quantizer, the dequantizers, SHA-256 and the GPU packers. Each was rewritten to as_chunks::<N>(), which visits the same elements in the same order.
  • Rust 1.99 passed every bit-exact oracle in the gate: tokenizer 4,258 of 4,258; chat template 317 of 317; the forward-pass steps (300/300, 140/140, 112/112, 150/150, 14/14 rows, SwiGLU 24,600/24,600 values); the whole model 1,064 of 1,064 rows for both the 1-bit and the ternary model; greedy 6/6, 6/6, 6/6 long and 3/3 deep; seeded sampling 40 of 40; native serve 9 of 9; the Ollama shape 9 of 9; the GPU kernels; and 8,188,239,872 weights with 762 of 762 dot products bit-exact for each 8B model (788 of 788 for the 1.7B).
• serve --native's chat path is factored, not changed.
  • serve::NativeChat (parse and run), serve::completion_json and a public serve::Tally are what both /v1/chat/completions and bankml_chat call, so the receipt is made by one piece of code.
  • The gate's serve_oracle --bankml passed on the refactored path.
• testing/spdx_check.py now covers C sources and headers, with upstream/ held to llama.cpp's MIT.

Measured (the 0.3.2 gate against 0.3.1's, same laptop, Ryzen 3 3200U)

Every oracle passed on 1.99, so the bits did not move. The speed rows did move, and the cause is not yet known: this run shared the 4-thread laptop with other work. The load average was 2.2–3.0 at its end, another session's cargo build was running right after it, and swap was full. Under that load the multi-threaded rows moved for ggml and bankml alike, so the per-pass ratio is the number to read.

row	0.3.1 (Rust 1.95)	0.3.2 (Rust 1.99)	reading
Q1_0 decode budget, 3 threads, bankml median	0.415 s/token, 0.98× ggml	0.787 s/token (min 0.522), 0.73× ggml (0.571, min 0.473)	beyond noise in absolute terms, but ggml's own median moved 0.406 → 0.571; contention
Q1_0 decode budget, 1 thread	0.682 s, 1.02×	0.677 s, 1.05×	unchanged
Q2_0 decode budget, 3 threads	0.274 s/token, 9.23×	0.394 s/token (min 0.327), 7.99×	ggml 2.612 → 3.603 s as well; contention
Q2_0 decode budget, 1 thread	0.491 s, 9.63×	0.477 s, 10.25×	unchanged or slightly better
Q2_0 prefill 1×4 tile	13.0×	13.25×	unchanged
Q1_0 GEMV mat_vec / prefill Q8Act tile	1.008× / 1.233×	1.104× / 1.308×	unchanged or slightly better

An interleaved A/B after the gate, with the same tests built by 1.95 and by 1.99 and run alternately (two rounds), ran at a load average of 4–5. ggml's own 1-thread token ranged from 0.73 s to 1.88 s across those runs. That is too noisy to separate the compilers, and it is recorded here as inconclusive. The deciding experiment is the same alternating A/B under testing/pinned.sh (pinned cores, a RAM cap) on a quiet machine. Until it runs, 0.3.2 claims no speed change in either direction.

0.3.1 — 2026-10-01 — Ollama's API, natively

bankml serve --native speaks Ollama's API over bankML's own forward pass, and can be asked for any pinned model by name. It is native only: what the verified forward pass cannot do is refused with a reason, never proxied to llama-server or Ollama. The roadmap is docs/OLLAMA.md: what mindX asks of Ollama, with file:line evidence, against what bankML does, and the O1–O8 track folded into docs/TODO.md. Record: testing/results/0.3.1.txt.

Added

• bankML/ollama.rs, Ollama's API (phase O1).

  • Listing: GET /api/version. GET /api/tags lists every pinned model: the digest is its pinned sha256, the details come from the GGUF header, and "bankml": {"native", "reason"} says whether bankML plays it.
  • State and metadata: GET /api/ps (the resident model and its expires_at); POST /api/show (a read-only modelfile, the sampling defaults, the template, model_info from the header).
  • Answers: POST /api/chat and POST /api/generate: system, and raw: true for direct tokenization.
  • Streaming: NDJSON, Ollama's default. The final object carries done_reason, the durations in nanoseconds, prompt_eval_count, eval_count, bankml_cache_n and bankml_receipt.
  • Options: temperature, top_k, top_p, min_p, seed, num_predict and stop are honoured. num_ctx is accepted up to the served context. The penalties go through the engine's own refusal. Resource options are ignored, because they do not change the answer. Anything else is refused.
  • Refused (400, with the reason): format (O6), tools and tool_calls (O6), images, suffix, template, context, think: true. Also /api/embed (O7), /api/create (O5), /api/pull, DELETE /api/delete, /api/copy and /api/push.

• A model registry, and residency (native.rs: Registry, Residency).

  • --registry [DIR] names every GGUF pinned in the forks directory (default $BANKML_FORKS, else ~/.local/share/bankml/forks). A name is the file's stem, lower-cased; :latest and the file name are accepted as aliases.
  • One resident model. A switch drops the old model before the new one is read, then runs the full verify (the guard, then the sha256 pin) exactly as the start does.
  • keep_alive as Ollama reads it ("5m", "1h", seconds, 0, negative), with --keep-alive for the /api default (5m). A reaper thread drops an idle model and its memory map when its time runs out.
  • Load or unload only: an empty prompt with a keep_alive answers done_reason load or unload, as mindX's coach uses it.
  • The file-identity check now lives with the resident model. A changed file is unloaded and refused; the next request verifies it again, with no restart.

• Done.prompt_ns and Done.eval_ns. The prefill and the generation are timed inside complete().

• The Ollama-shape oracle (testing/serve_oracle.py --bankml, in the release gate). The 0.3.0 conversations go three ways, each from an empty slot:

  • through /api/chat (the first conversation streamed as NDJSON);
  • through /v1/chat/completions;
  • through /v1/chat/completions again, after unload and a reload that verifies the file again.

  All of them must equal each other and llama-server b11192's record, turn by turn.

Changed

• /v1/chat/completions now honours stop. 0.3.0 ignored it silently. It also resolves model through the registry: absent means the startup model, and an unknown name now answers 404 where 0.3.0 ignored the field. The OpenAI and llama-server endpoints keep the model resident, as 0.3.0 did.
• A startup model the forward pass cannot play is refused at start, with the reason. 0.3.0 started and then failed every request: Bonsai-1.7B has tied embeddings (no output.weight), which is phase O4.
• GET /bankml (native) adds resident and models. Its verified is the most recent verification.
• The way back to the Interaction tab.
  • Savante's card, and every derived agent's card, now has a bar pinned to its top: ← back to Interaction. It stays visible however far the card is scrolled, and Esc closes the card. Before, the only close control was a ✕ that scrolled away with the card's content.
  • Every other tab shows a ← Interaction pill in the bottom-left corner. It goes straight back to the chat, with the cursor in the question field.
  • use this agent on the Agents tab now returns to the Interaction tab with that agent in use.
• The Interaction tab is only the conversation.
  • The chat, the question field, the clock and the portrait. The settings (.prompt, .memory, max tokens, temperature), the carrier, and the CPU and RAM controls moved to a new Admin tab; the engine choice and n-gram speculation are under its advanced.
  • An answer is shown alone. Its clock, receipt and prompt provenance are kept, but not in the chat: they are on the Admin tab under the last answer, in .history (a new trail field) and on the Responses tab. Earlier turns reload as their answers alone.

0.3.0 — 2026-09-29 — milestone: Savante answered by bankML's own forward pass

bankml serve --native answers Savante from bankML's own forward pass. Whole conversations are identical to llama-server's turn by turn, and about 8× faster on the ternary model. Record: testing/results/0.3.0.txt.

Added

• bankML/native.rs, the native engine.
  • One conversation slot that reuses the KV cache exactly as llama-server's prompt cache does: it keeps the longest common prefix, less one token when the whole prompt is cached, truncates there, and computes the rest in micro-batches of 512, so every row takes the kernel llama.cpp's row takes. KvCache::truncate was added for this.
  • Sampling uses the request's parameters over the model's GGUF defaults. Samplers it does not reproduce are refused with a reason.
  • It streams whole UTF-8 characters and counts the end-of-turn token among the completion tokens, as llama-server does.
• bankml serve --native.
  • The same gateway as before: guard, sha256 pin, loopback rules, and the file's identity checked before every answer. It also listens on the engine address (--upstream) and answers llama-server's endpoints there (/health, /props, /tokenize, /apply-template, /v1/chat/completions, /v1/models), so a client written for llama-server, Savante included, reaches it unchanged.
  • Streamed and non-streamed OpenAI-style answers, each with usage, timings.cache_n and the receipt. The receipt's engine names bankML's own forward pass and the GPU when one works in it.
• Savante's engine setting (Models → Resources: auto, native or llama.cpp; models.py native_for). auto uses bankML for the ternary files, where it is about 8× llama-server, and llama-server for the rest, where llama-server is still faster. The importer starts the carrier accordingly.
• The milestone oracle (testing/serve_oracle.py → oracle_native_serve, in the gate). It runs three Savante-style conversations of three turns each, sampled at Savante's temperature 0.3 with fixed seeds, through llama-server b11192's own /v1/chat/completions in one fresh server process, so its prompt cache carries each conversation. bankML's engine gives the same answer text, prompt and completion counts and prompt-cache reuse on 9 of 9 turns, with the GPU working. Along the way the oracle caught that llama-server counts the end-of-turn token among completion tokens.

Checked end to end

• python3 sAGI/models.py use Ternary-Bonsai-8B-Q2_0_g64.gguf starts the native carrier on its own. The model is verified, and it answers with llama-server's greedy answer.
• Savante's own client code, unchanged, streams from it, reads its receipt, counts tokens through its /tokenize and reads its context from /props.

Limits

• The Qwen3 1-bit and ternary models; one conversation slot; no slot save or restore yet (Savante then prefills as usual); top-k, top-p, min-p and temperature.
• On the 1-bit model llama-server is still faster: 2.8 tokens/s against 1.9–2.0.

0.2.14 — 2026-09-29

The GPU works inside the forward pass without changing a bit, and the FMA a driver would not fuse. Record: testing/results/0.2.14.txt.

Found

• The Vega 3's driver does not fuse Fma. On real layer weights the 0.2.13 kernels differed from the CPU by about one ulp on 70 % of rows, even though they had passed on random data. The card agreed on every row with the CPU recipe whose outer fma(d0, ab, acc) is an unfused multiply-then-add; the inner fma(d1, s, ab) never showed, because d1·s is exact in f32. Decorating the Fma NoContraction did not change it. The random verification data was too kind: its products were mostly exact.

Fixed

• An exact FMA from plain arithmetic (spirv.rs fma_exact), correct on every GPU whether its driver fuses or not:

  • d0 comes from f16 and has 11 significant bits, so splitting the other operand into two 12-bit halves makes both partial products exact;
  • Knuth's TwoSum keeps every rounding error;
  • Boldo and Melquiond's RN(th + RO(tl + ul)) (rounding to odd, 2008) gives the FMA's single rounding.

  Both kernels are now bit-exact on real weights: 0 of 4,096 and 0 of 12,288 rows differ.

• The on-card oracle (kernels::verify_q1_0, bankml gpu --verify) adds a layer-shaped regime: weight scales and activation magnitudes that vary per block, and no −128. With the driver's Fma put back, it now refuses the card: "row 1 differs … bankml will not use this card".

Added

• gpu/worker.rs: the GPU as a worker beside the CPU's threads. When a card is selected and passes the on-card oracle, each 1-bit matrix–vector product gives the card the first share of its rows (asynchronously) while the CPU pool computes the rest, then copies the card's rows in.
  • The share is calibrated when the card is opened: the card rate divided by the combined rate, 26–35 % on the Vega 3. BANKML_GPU_SHARE overrides it and BANKML_GPU=off disables the worker.
  • Only the card's share of each matrix is copied to it (repacked exactly), on first use.
  • Gpu::submit and Gpu::wait split a dispatch from its fence.
• Every token oracle now runs with the GPU working, and passes. The whole 1-bit model is 1,064 of 1,064 rows bit-exact with the Vega 3 computing 26 % of every matrix's rows, and the greedy and sampling checks go through the same path.

Speed, honestly

• Decode on this laptop is unchanged within noise: 1.93–2.00 tokens/s with the card against 1.96–1.97 without. The card is worth about one CPU core here, and each of the 253 matrix calls per token pays one submit and wait on it, which cancels the gain. Batching the submissions that share an input (Q, K, V; gate and up) into one is the next step. A discrete card gains directly.

0.2.13 — 2026-09-29

The first GPU kernels, bit-exact on the card; mindXtrain begins in Rust; bankML branding. Record: testing/results/0.2.13.txt.

Added

• GPU kernels, and bankml's own SPIR-V.
  • gpu/spirv.rs is a small SPIR-V assembler, so bankml needs no shader compiler at build time or run time. Every float multiply and add it emits is decorated NoContraction, and every fused step is an explicit Fma, so a driver cannot change the float order.
  • gpu/kernels.rs has two Q1_0 matrix–vector kernels that follow the CPU kernel's recipe step by step: q1_0_mat_vec uses one invocation per row, and q1_0_mat_vec8 uses eight per row, one per accumulation lane, with the lanes summed in the CPU's order through workgroup memory. Weights are repacked once, exactly (scales f16→f32, bits as words).
  • gpu/compute.rs is the Vulkan compute runtime (device, buffers, pipelines, dispatch), again through the run-time loader and structs declared in-crate.
  • On the Radeon Vega 3, both kernels are bit-exact against the CPU kernel, which matches ggml, at every shape tried: 64×128 to 12288×4096, with −128 quants included.
  • bankml gpu --verify runs that check on every card found. A card that fails is named and never used; this is how bankml puts a card to work only after proving it gives the same bits.
  • Speed, honestly: on this integrated GPU the eight-lane kernel matches one CPU thread (1.7–2.0 ms per 4096×4096). It becomes an extra worker next to the CPU's threads when rows are shared (next step). On a discrete card the same kernel has far more hardware.
• mindXtrain in Rust (bankML/train/). A stage registry for the proof loop (author → imprint → probe → score → classroom → boardroom), built one verified stage at a time against mindXtrain's own Python (testing/train_oracle.py, run with mindXtrain's interpreter):
  • train/script.rs, the author stage: persona + exchanges → chat-JSONL script. 84 of 84 scripts byte-identical to scripts.py, over every persona in mindX and cryptoAGI plus edge cases.
  • train/imprint.rs, the score stage (lexical path): the recall gate's voice score, shift and verdict. 3,000 of 3,000 reports identical to score_imprint.
  • Next come the probe on bankml's forward pass (it needs the Llama architecture, since mindXtrain imprints SmolLM2, and adapter loading), the verdicts, and LoRA training on the CPU.
• The Savante UI is branded bankML ("bankML · Savante — verified low-bit inference on this computer") and carries the DeltaVerse $ as its tab icon (deltaverse.pythai.net/favicon.ico, MIT; served by both the interact and view pages).
• Install docs now show chmod +x install.sh before ./install.sh, for copies that lost the executable bit.

0.2.12 — 2026-09-29

Batched prefill, and the video-card component. Record: testing/results/0.2.12.txt.

Added

• Batched prefill (bankML/forward.rs). A micro-batch now goes through each layer together:

  • every matmul is one matrix–matrix product over the micro-batch's rows (Weights::mm, Weights::quantize_rows, through q1_0::mat_mul_act_par and q2_0::mat_mul_par);
  • the micro-batch's K and V enter the cache before its attention, as llama.cpp writes them;
  • each row attends over the cells up to its own position (Weights::attend).

  Every element of those products has the bits of the per-pair dot, so the result is the token-by-token result. Every oracle that goes through prefill checks this: greedy, long, deep and sampling.

• bankML/gpu/: the video-card component.

  • gpu/mod.rs is the registry. Each backend is a module with one discovery function, listed in BACKENDS; a new backend (CUDA, ROCm, Metal) is a new module and one line.
  • Devices are described by merging the backend's view with the kernel's (/sys/class/drm: driver, VRAM, GTT, PCI address, NUMA node).
  • selected() uses every real GPU found, discrete cards first and the largest first. Software renderers (Mesa llvmpipe) are refused. BANKML_GPU=off turns the component off, and BANKML_GPU=0,2 picks cards.
  • gpu/vulkan.rs opens libvulkan.so.1 at run time: no crate and no link-time dependency, the entry points from vkGetInstanceProcAddr, the few C structs declared from the Vulkan headers. It covers AMD, NVIDIA, Intel, Arm and Qualcomm GPUs through one API.
  • gpu/hf.rs, the first remote backend, lists the GPUs Hugging Face rents through Jobs (huggingface.co/api/jobs/hardware, public). That is 22 NVIDIA flavors, T4 to 8× H200, provisioned on AWS, Azure and GCP, each with its card count, memory and price per hour. They are read through the system curl (bankml has no TLS of its own), listed and never selected or provisioned: a rented card is used by running bankml on it as a Hugging Face Job, where the Vulkan backend finds it. NVIDIA agreed on 2026-09-02 to acquire Hugging Face; closing is expected in the first half of 2027. The dated addendum is bankML's docs/huggingface.md.
  • bankml gpu [--remote] prints what was found and what will be used. Here it finds the Radeon Vega 3 (RADV, Vulkan 1.3, 5 compute queues, CPU-mappable memory, amdgpu at 0000:04:00.0) and refuses llvmpipe.
  • No kernels run on the GPU yet. They come next, and each must reproduce the CPU kernels' bits on the card before it is used, so a GPU changes the speed and never the tokens. Several cards will share every matrix by rows, which keeps each element one card's exact dot product.

Also since 0.2.11 (separate commits)

• Savante's canon moved to ~/cryptoAGI/savante, beside jaimla and luvai (991ab1a). The installer and UI default to it, and a machine with only the older ~/savante keeps using that.
• Open-source coder models in the catalogue (4e9f4de): Qwen2.5-Coder 1.5B and 7B, and Qwen3.8-27B (the newest Qwen). StarCoder and WizardCoder are excluded because their licences (OpenRAIL-M, Llama 2) are not OSI.
• Two new agents, codephreak (Professor Codephreak, aware of github.com/Professor-Codephreak and its orgmap) and simplecoder. They were derived from Savante's template with bankml's own ledger, live in ~/cryptoAGI/<name> as private local repositories, and appear in the Agents tab.

0.2.11 — 2026-09-29

P3, step eleven: sampling. bankml draws llama.cpp's tokens with the same seed. Record: testing/results/0.2.11.txt.

Added

• bankML/sampler.rs: llama-server's sampler chain. The chain is penalties → dry → top-n-σ → top-k → typical-p → top-p → min-p → xtc → temperature → dist. With the Bonsai GGUF's defaults and neutral penalties, dry, typical-p, xtc and top-n-σ, the active part is written from b11192's llama-sampler.cpp in its float order:
  • top-k is std::partial_sort over the vocabulary, ported from libstdc++'s heap select and heap sort. Logits can tie, and the order the algorithm leaves equal logits in decides which token a draw lands on.
  • top-p is a float softmax with a float running cut.
  • min-p cuts at max + logf(p).
  • temperature is logit / temp; at 0 or below, every logit but the first maximum is set to −∞.
  • dist computes expf(logit − max) summed in double, takes one uniform_real_distribution<double> draw from std::mt19937(seed) (libstdc++'s generate_canonical: two 32-bit outputs), and walks a double running sum. The RNG advances once per token, including when only one candidate remains.
  • Anything outside that is refused, not approximated: top-k 0 or above 128 (llama.cpp sorts those another way), and non-neutral penalties, dry, typical-p, xtc, top-n-σ or dynamic temperature.
  • Params::from_gguf resolves the defaults as llama-server does: the GGUF's general.sampling.* over llama.cpp's own.
• bankml generate --sample [--temp T] [--top-k K] [--top-p P] [--min-p P] [--seed S]. Without --sample it stays greedy.
• The sampling oracle (testing/sample_oracle.py → oracle_sample_llama_server, in the gate). It records 4 prompts × 10 settings with fixed seeds: the defaults, temperatures 0, 0.3, 1.0 and 1.5, top-k 5, 40 and 128, top-p 0.95 and 1.0, and min-p 0.05 and 0.2. Each case keeps the parameters the server reports it ran. 40 of 40 continuations identical, 1,175 tokens, on the first run.

0.2.10 — 2026-09-29

P3, step ten: long contexts. All three of ggml's CPU attention kernels are now reproduced. Record: testing/results/0.2.10.txt.

Added

• attend_head_split: ggml's split-KV flash attention. llama.cpp runs it for a single-token decode once the padded KV length reaches 512, that is, beyond 256 cells in use.
  • The padded cells are cut into ceil(padded / nth)-cell chunks, one per llama.cpp thread.
  • Each chunk runs a partial reference pass (attend_head_partial: max, sum and the f16 accumulator, without normalizing), skipping masked cells.
  • ggml_flash_attn_ext_reduce_partials combines the chunks in order: fmaxf of the maxima, two expf rescales, fma(acc, old, chunk · new) for the accumulator and likewise for the sum, then · (1/S).
• The thread count is part of the result. Weights::llama_threads (BANKML_LLAMA_THREADS, default 3, the -t Savante runs) sets the chunking. kernel_for(rows, cells, llama_threads) now returns Kernel::Split { padded, nth } where 0.2.9 refused, so bankml generate runs to any context length.
• Oracles, in the gate.
  • oracle_forward_attention_split records one decode row over 257, 300, 511, 512, 513, 700 and 1,000 cells, at 3 and at 4 threads, in the shipped ggml: 14 of 14 bit-exact. Every hash differs between 3 and 4 threads, so the dependence on the thread count is real.
  • oracle_greedy_llama_server_deep uses greedy_oracle.py --deep: 3 prompts of 98–100 tokens asking for long answers, 200 generated tokens each, running to about 300 cells. bankml generates llama-server's 600 tokens exactly. Each case passes through all three kernels: tiled for the prompt, reference up to 256 cells, split-KV after that.

Found

• A reduction that the first test cases could not see. In the shipped binary the reduction is vmulps + vfmadd231ps: the chunk's term is rounded and the running term fused. Written plainly, it passed every 3-thread case, because there the first chunk held the maximum, so the old scale was exactly 1 and the two forms agree. It failed at 4 threads with 512 padded cells, where a later chunk held the maximum. The 4-thread cases were added to show the thread-count dependence, and they also exposed this.

0.2.9 — 2026-09-29

P3, step nine: long prompts. Record: testing/results/0.2.9.txt. Built on the new layout: the Rust runtime is in bankML/ and Savante's UI in sAGI/ (ef65eb4).

Added

• attend_head_tiled: ggml's tiled flash attention (flash_attn_ext_tiled), which llama.cpp runs for any micro-batch of 64 rows or more. It is a different algorithm from the reference path:

  • Q stays f32, and K and V are widened from f16;
  • per 64-cell KV tile, the scores are a SIMD GEMM (one FMA chain over the head dimension), then · scale + mask;
  • the tile's max joins the running max through fmaxf, and an expf rescales the f32 accumulator and the sum;
  • ggml_vec_soft_max_f32 uses ggml's v_expf, reduces each 8-lane group in f32, sums the groups in double, and adds that to the float sum through double;
  • the V GEMM is one FMA chain over the tile's cells;
  • finally acc · (1/S).

  A row's result does not depend on which rows share its tile, so bankml computes it row by row.

• llama.cpp's kernel choice.

  • kernel_for(rows, cells) returns the tiled kernel for micro-batches of 64 rows or more and the reference kernel otherwise. A single-token step whose padded KV length reaches 512 (padded_kv, multiples of 256, at least 256) is llama.cpp's split-KV kernel; bankml refuses it with a reason rather than compute something different.
  • Weights::prefill splits a prompt into micro-batches of N_UBATCH = 512, as llama-server does, with each micro-batch's kernel.
  • Weights::decode runs one generated token with the decode rule.

• Oracles, in the gate.

  • oracle_forward_attention_tiled checks layer 0's kqv_out for a 150-row micro-batch in the shipped ggml: 150 of 150 rows bit-exact. The reference kernel would match 1 of them, so the choice matters.
  • oracle_greedy_llama_server_long uses greedy_oracle.py --long with a longer system prompt, so the prompts are 111–116 tokens. bankml generates llama-server's tokens on 6 of 6.

Fixed

• bankml generate's range check. It warned at 512 cells; it now stops, with the reason, exactly where llama.cpp would switch to the split-KV kernel (beyond 256 cells), and has no warning for long prompts because they are now reproduced.

Limits

• Contexts up to 256 cells. The split-KV decode kernel is next.
• The long-prompt end-to-end check ran on the 1-bit model. Llama-server's ternary prefill runs at 0.35 tokens/s, so a ternary long-prompt recording takes most of an hour. The tiled kernel is model-independent and is proven at the kernel level.
• Prefill still runs one token at a time. The long-prompt oracle takes 8 minutes. Batched prefill is the next speed step.

0.2.8 — 2026-09-29

P3, step eight: the ternary model. bankml's own forward pass is token-identical to llama.cpp and about 8× faster end to end. Record: testing/results/0.2.8.txt.

Added

• forward.rs runs Q1_0 and Q2_0_g64 models.
  • Weights::matrix, Weights::quantize and Weights::mv replace the Q1_0-only path. The q8_0 activation is prepared once for the model's type (Act::Q1 or Act::Q2) and shared by the matrices that read it. Each type goes through its own proven kernel (q1_0::mat_vec_par, q2_0::mat_vec_par).
  • The embedding dequantizes either type.
  • bankml generate takes either model.
• Ternary oracles, in the gate.
  • oracle_forward_model_ternary: the whole ternary graph in the shipped ggml (testing/model_oracle.py, now type-general). 1,064 of 1,064 rows bit-exact, including all 151,669 logits for each of 28 tokens.
  • oracle_greedy_llama_server_ternary: llama-server b11192 running the ternary model, with Savante's flags. 6 of 6 chat prompts token-identical (140 tokens).
  • The oracle files are now named per model (model-<stem>.tsv, greedy-<stem>.jsonl).

Speed (this laptop, 3 threads, same prompt, sequential runs)

	llama-server b11192	bankml 0.2.8
ternary, decode	0.30 tokens/s	2.32–2.41 tokens/s
ternary, prompt	0.35 tokens/s	2.8 tokens/s (one token at a time)
1-bit, decode	2.80 tokens/s	1.80 tokens/s

The ternary lead is the kernel's (§III.6). On the 1-bit model bankml is still behind, because prefill runs one token at a time and the per-token overheads are not tuned yet.

Fixed

• The stated context limit was wrong: 256 cells, not 512. llama.cpp pads the KV length it attends over to a multiple of 256, with a minimum of 256 (llama_kv_cache::get_n_kv). A single-token decode switches to the split-KV kernel when that padded length reaches 512, which happens once more than 256 cells are in use. 0.2.7 said "under 512 cells". No oracle result changes, since the largest case uses 80 cells, but the limit in the docs does. bankml generate's warning threshold is corrected in 0.2.9.
• The greedy oracle's stopping rule. The server's token list already includes the end-of-turn token when it produces one. The 0.2.7 test then also required bankml's next token to end the turn, which is a check with no meaning. It passed on the 1-bit model by coincidence and failed on two ternary cases where the server had stopped at 16 tokens for its own reasons. The test now generates exactly as many tokens as the server did and compares them all. greedy_oracle.py now also records the server's stop_type.

0.2.7 — 2026-09-29

P3, step seven: the whole model. bankml's own forward pass generates llama.cpp's tokens. Record: testing/results/0.2.7.txt.

Added

• forward.rs.
  • Weights::step runs one token through all 36 layers at the next position. Each layer appends to its own f16 K/V cache (Weights::caches), and the step returns result_norm.
  • Weights::logits is output.weight (Q1_0, 151,669 rows) times the q8_0-quantized result_norm.
  • Every matmul runs on the thread pool (mat_vec_par, same bits at any thread count; BANKML_THREADS).
• bankml generate MODEL.gguf [--max N] < messages.json | text. It renders the conversation (0.2.2), tokenizes it (0.2.1), runs the prompt through the forward pass and streams greedy tokens until the turn ends. It warns when a prompt or context leaves the range verified against llama.cpp (see Limits).
  • Tokenizer::token_bytes gives a token's bytes as llama.cpp's detokenizer does without special tokens.
• The whole-model oracle (testing/model_oracle.py → oracle_forward_model, in the gate). The shipped ggml computes every layer of the Qwen3 graph, output_norm and the logits for the 28-token prompt. It works one layer per context and carries the residual stream between contexts, so memory stays near one layer's weights. 1,064 of 1,064 rows bit-exact: 36 layers' l_out, result_norm and all 151,669 logits, for each of 28 tokens. The greedy token matches at 28 of 28 positions. Time: 14 s on 3 threads.
• The end-to-end oracle (testing/greedy_oracle.py → oracle_greedy_llama_server, in the gate). It records llama-server b11192's own greedy continuations (top-k 1, prompt cache off) for 6 chat prompts rendered by /apply-template and tokenized by /tokenize. bankml generates the same tokens on 6 of 6 prompts (164 tokens). Where the server stopped before its limit, bankml's next token also ends the turn.

Limits (stated, and warned about by bankml generate)

• Verified range: prompts under 64 tokens, contexts under 512 cells. Outside it, llama.cpp switches to its tiled (prefill) and split-KV (decode) attention kernels, which are the next steps.
• The 1-bit model only. The ternary model's forward pass, where bankml's kernel is 9× llama.cpp's, is next.
• Speed: measured on this laptop, the 1-bit model decodes at 1.80 tokens/s against llama-server's 2.80. The prefill runs one token at a time, against llama-server's batched 3.27 tokens/s. The forward pass is correct first; batched prefill and the ternary path are where its speed will come from.

0.2.6 — 2026-09-29

P3, step six: the feed-forward block. With it, all of layer 0 is bit-exact against llama.cpp's. Record: testing/results/0.2.6.txt.

Added

• forward.rs.
  • Weights::ffn runs the feed-forward block: ffn_norm, then the gate and up projections (one shared q8_0 activation, the proven Q1_0 kernel), SwiGLU, ffn_down, and the residual. The result is llama.cpp's l_out, the layer's output.
  • v_expf is ggml's AVX2 ggml_v_expf, lane by lane, and not libm's expf. It has a range reduction by 2ⁿ, a degree-5 polynomial evaluated in FMAs, and the scaled path for |n| > 126, with the constants carried as exact bit patterns.
  • swiglu is silu(g) · u, with silu(x) = x / (1 + v_expf(0 − x)), as ggml_vec_swiglu_f32 computes it.
• The oracle extended.
  • oracle_forward_attention now runs through l_out: 112 of 112 rows bit-exact (kqv_out, attn_out, ffn_inp, l_out, 28 tokens).
  • New oracle_forward_swiglu_sweep, in the gate: the shipped ggml_swiglu_split on 24,600 values across ±120 and the edges. That covers the large-|x| path of ggml's expf, which no prompt reaches. 24,600 of 24,600 bit-exact.

Found

• A whole-layer check can hide a wrong function. With libm's expf in place of ggml's, l_out still matched 27 of 28 rows, because the q8_0 quantization before ffn_down absorbs most of the difference. The direct sweep matched only 19,245 of 24,600. Every function gets its own oracle for this reason.

0.2.5 — 2026-09-29

P3, step five: layer 0's attention, the output projection and the residual, bit-exact against llama.cpp's. Record: testing/results/0.2.5.txt.

Added

• forward.rs.

  • KvCache holds one layer's K and V in f16, one row per position, rounded as llama.cpp's cache stores them.

  • attend_head and Weights::attention compute llama-server's default attention, ggml's CPU flash attention (flash_attn_ext), in its reference path:

    • Q rounded to f16;
    • each score is ggml_vec_dot_f16 as the AVX2 build computes it: four 8-lane FMA accumulators over 32-element steps, then a fixed reduction tree;
    • the score is multiplied by 1/√128;
    • an online softmax whose V accumulator is f16, with every step rounded back: f16(fma(v, w, acc)) and f16(acc · ms);
    • finally acc · (1/S).

    Grouped-query attention maps 4 query heads to each KV head. Then wo runs through the proven Q1_0 kernel, and the residual adds the layer's input.

• The oracle extended (oracle_forward_attention, in the gate). The shipped ggml's cpy to f16, a causal f16 mask, flash_attn_ext (with F32 accumulation set, as llama-graph sets it), mul_mat and add run on the 28-token prompt. 84 of 84 rows bit-exact (kqv_out, attn_out, ffn_inp). The check discriminates: with the softmax sum contracted into an FMA, only 59 of 84 match. The binary computes S·ms + vs unfused.

Scope

• ggml switches attention to other kernels in two cases, which are the next attention steps:

  • a batch of 64 or more query rows (a long prompt) takes the tiled kernel;
  • a single-token decode over 512 or more KV cells takes the split-KV kernel, whose partial sums depend on the thread count.

  Cells masked out are skipped, so padding the cache does not change a result.

0.2.4 — 2026-09-29

P3, step four: layer 0's attention inputs (Q, K and V projected, the head norms, YaRN RoPE), bit-exact against llama.cpp's. Record: testing/results/0.2.4.txt.

Added

• forward.rs.
  • Weights::qkv gives llama.cpp's Qcur, Kcur and Vcur for one token:
    • the normed row quantized to q8_0 and multiplied by the Q1_0 attn_q, attn_k and attn_v weights, through the kernel already proven bit-exact;
    • Q and K normed per 128-wide head by attn_q_norm and attn_k_norm;
    • RoPE applied to each.
  • Rope carries the parameters llama.cpp's context derives for Bonsai's YaRN: freq_scale = 1/4, ext_factor = 1, attn_factor = get_mscale(4, 1) / (1 + 0.1·logf 4) (exactly 1.0 in float, checked against the bits the oracle records), beta 32 and 1, n_ctx_orig 16,384, and correction dims [20, 37]. The cos/sin cache is built as ggml builds it: theta advances by repeated multiplication by powf(base, −2/n), and the pairs are NEOX (i, i + 64).
• The oracle extended (testing/forward_oracle.py → oracle_forward_qkv_rope, in the gate). The shipped ggml's mul_mat, rms_norm, mul and rope_ext run on a 28-token chat prompt at positions 0–27, and again at positions 7 to 63,214, where theta is a long product. 140 of 140 rows bit-exact.

Found

• The bits follow the binary, not the source. Written as the C source reads (x0·cos − x1·sin), RoPE matched only 30 of 84 rows. The projections and head norms were exact (28 of 28 each), which isolated the difference to RoPE. The disassembly of the shipped libggml-cpu-haswell.so shows GCC contracting three expressions into FMAs:

  • the rotation: fma(x0, cos, −(x1·sin)) and fma(x0, sin, x1·cos), with x1's products rounded and x0's fused;
  • the YaRN mix: fma(θ_interp, 1 − r, θ_extrap·r);
  • the magnitude: fma(logf(1/fs), 0.1, 1).

  bankml writes the same three as mul_adds. The RMS norm has nothing to contract, which is why 0.2.3 matched as written.

0.2.3 — 2026-09-29

P3, step three: the first operations of bankml's own forward pass, bit-exact against llama.cpp's. Record: testing/results/0.2.3.txt.

Added

• forward.rs.
  • Weights reads the model's tensors through bankml's own memory map.
  • embed is llama.cpp's get_rows on the Q1_0 token table (inp_embd), through the dequantizer already proven bit-exact.
  • rms_norm_mul is rms_norm then mul by the layer's norm weight (attn_norm-0), in the float order read from b11192's ggml-cpu/ops.cpp: the sum of squares accumulated in double, one float product at a time; the mean rounded to float; 1 / sqrtf(mean + eps); each output (x · scale) · w, with no FMA.
• The forward-pass oracle (testing/forward_oracle.py → oracle_forward_embed_norm, in the gate). The release has no tool that prints intermediate values, so the oracle drives the shipped libggml through ctypes with the same ops llama.cpp's Qwen3 graph uses, computed by the release's own CPU backend, on 300 real token ids. 300 of 300 rows bit-exact for both inp_embd and attn_norm-0.

0.2.2 — 2026-09-29

P3, step two: the chat template, byte-identical to llama.cpp. The ternary headline re-measured and confirmed. Record: testing/results/0.2.2.txt.

Added

• chat.rs renders a conversation into the prompt exactly as llama.cpp b11192 does with the Bonsai / Qwen3 template in the GGUF, without a Jinja engine. check_template accepts only that template (sha256 30a75d10e60b57e2… of its text; the 1.7B and 8B files carry the same one). Its rules are written out with Python's split/strip semantics:

  • the first system message at the top;
  • the last real user query found by scanning back;
  • <think> blocks kept only after that query;
  • tool results grouped into one user turn;
  • the thinking-off generation prompt.

  Tool definitions, tool calls and assistant prefills are refused, not guessed.

• The chat-template oracle (testing/template_oracle.py → oracle_chat_template, in the gate): llama-server's own /apply-template on 317 conversations. 317 of 317 byte-identical. The oracle caught one server behaviour the template does not show: an empty reasoning_content is dropped before templating.

• bankml chat-template MODEL.gguf < messages.json.

Measured

• The whole-token ternary budget, with the model resident. The browser and the chat engine were closed, and 2.25 of 2.31 GB stayed cached. bankml then took 0.231 s per ternary token at three threads against llama.cpp's 2.185 s (9.45×), and 0.223 s (9.78×) at four. That reproduces the 0.0.3–0.0.6 figure on today's code and confirms that the slower gates measured the disk, not the kernel. README, TECHNICAL and PERFORMANCE now state it as measured (docs/PERFORMANCE.md has the table). The 0.2.2 gate itself ran with 3.3 GB free and recorded the same: 0.233 s against 2.204 s (9.46×) by the fastest runs, 0.287 s against 2.23 s (7.8×) by medians.

Documentation

• The README's results checked against the record. Every figure now comes from the 0.2.2 gate record and says which statistic it is. The corrections:
  • ternary per matrix 9.4–10.0×, was "9.5–9.8×" from 0.0.1;
  • ternary prefill 12.9×, was 12.5×;
  • 1-bit prefill 1.23×, was "1.2–1.3×";
  • llama.cpp's 1-bit token 0.35 s, was 0.34 s;
  • the ceiling 4.3 vs 0.45 tok/s, was "4 vs 0.4";
  • the badge.
• The speed cards are now drawn from a gate record by tools/cards.py, not by hand. The 0.0.1 cards had drifted (7.06× from a pre-pool harness; 14.47 ns per 1-bit block from an older build). Each card names its record, says whether the model was resident, and gives the min and median where they differ.
• Savante's public places are linked from the README: the Hugging Face Space, the sAGI skill, her loop dataset, the sAGI engine and her canon. The Documentation table links straight to the Thesis in TECHNICAL.md.

0.2.1 — 2026-09-29

P3, step one: bankml's own tokenizer, token-identical to llama.cpp. P3, a forward pass of bankml's own, has to produce the same tokens as llama.cpp; the tokenizer is where that starts. Record: testing/results/0.2.1.txt.

Added

• tokenizer.rs (no crates) reads the vocabulary straight from the GGUF: 151,669 tokens, 151,387 merges and their types, through a bounded reader of its own. The guard's header parser skips arrays by design. It then reproduces llama.cpp's gpt2/qwen2 tokenization:

  • special tokens cut out first, longest first. USER_DEFINED ones such as <think> always split the text; CONTROL ones such as <|im_start|> only when special tokens are parsed;
  • Qwen2's pre-tokenizer pattern, written out alternative by alternative, including the backtracking outcomes of \s*[\r\n]+ and \s+(?!\S);
  • GPT-2 byte-level BPE by merge rank, leftmost on ties.

  The pattern's \p{L} is Unicode general category L, generated into unicode_letters.rs (Rust's is_alphabetic is a different property).

• The tokenizer oracle (testing/tokenizer_oracle.py → oracle_tokenizer, in the gate). It records the running engine's /tokenize on every document, Savante's canon, hand-picked edge cases and a seeded 2,000-string fuzz set over 17 Unicode ranges, with special tokens parsed and not. 4,258 of 4,258 cases token-identical.

• bankml tokenize MODEL.gguf [--no-special] (text on stdin, ids out).

• The whole-token ternary budget with more memory free. For this gate the chat engine was stopped (2.0 GB free instead of about 1.4 GB). bankml's ternary token then took 1.42 s against llama.cpp's 3.0–5.2 s (2.1–3.6×), against about 4.6 s (1.1×) in the disk-bound gates before. That is further evidence for the page-cache explanation in docs/PERFORMANCE.md. It is still short of the 0.23 s measured with the model fully resident: 2.31 GB does not quite fit in 2 GB.

Fixed

• The CLI tests left their synthetic GGUF fixtures in /tmp: 234 runs had accumulated 1.2 GB on a disk with 4.2 GB free. Each run now removes the directories of earlier runs whose process is gone.

Measured

• 243 KB of docs (72,403 tokens): bankml loads the vocabulary in 0.17 s and encodes in about 0.04 s. llama-server's /tokenize answers the same text in 0.175 s, vocabulary already loaded, HTTP and JSON included. The ids are identical. That is a measured comparison, not a claim about llama.cpp's tokenizer alone.

0.2.0 — 2026-09-29 — milestone

Verified, documented, and offered back. 0.2.0 closes the 0.1.x run of audits and speed work:

• every document checked line by line against the code and the gate records;
• a fourth audit fixed;
• bankml's ternary kernel prepared as a contribution to llama.cpp, bit-exact against its shipped library.

Record: testing/results/0.2.0.txt.

Added

• upstream/: an AVX2 Q2_0 kernel for llama.cpp. At b11192 x86 has only scalar Q2_0, and the one open x86 PR needs AVX-VNNI. q2_0_avx2.c is a drop-in ggml_vec_dot_q2_0_q8_0 in ggml's C:

  • the generic code's float order, with its FMAs explicit;
  • codes expanded by one variable dword shift;
  • the activation transposed 4×4 within each lane, with no lane crossings.

  test_q2_0_avx2.c compares it with the shipped libggml-cpu-haswell.so: bit-exact on 200,000 of 200,000 random cases (every code 0–3, extreme activations), and 3.4× the shipped scalar path per 4096-wide row, pinned to two cores. The README explains why bankml's own kernel is faster (9.5–9.8×): it lays the activation out once per token, where a drop-in must do it per call. MIT, llama.cpp's licence. Opening the pull request is the authors' decision; nothing has been submitted.

Fixed (the fourth audit, of 0.1.9)

• The history window at a tight context. It moved almost every turn, so the prompt cache did not help exactly when it mattered. Now:
  • the start is kept per session while it still fits;
  • when it stops fitting, the newest half of what fits is kept, so the next turns reuse the prompt (when only two or three fit, all are kept: history is worth more then);
  • with room, the window moves 8 times in 60 turns.
• The "history trimmed" note now appears only when the context forced a trim, not for the ordinary 12–17 window.
• A prompt that cannot fit is refused with the numbers, instead of the engine's error.
• Two tabs no longer share one window record: each request gets its own.
• Slot saves run in the background, after the answer and its .history line, and only when no other answer is being written: they no longer save another tab's KV or delay a footer. A failed save is not retried every turn, and the slot field records what a turn did, not the engine's state.
• Token counts: history outside the window is not tokenized; the cache evicts its oldest half instead of clearing. The fallback's docstring no longer claims to be an overestimate for every script.
• The engine's context is cached per engine start (a restart with a new context is seen at once) and falls back to the saved setting.
• bankml serve: the over-capacity 503 is answered on its own short thread with one overall deadline, so a slow client can no longer hold the accept loop.
• The embedding indexer cannot stay disabled if its thread fails to start. testing/pinned.sh no longer needs python3.

Documentation

• A line-by-line accuracy review of every document against the code and the gate records gave 23 corrections:
  • the usage guide's commands, routes, environment table, window policy, Apply behaviour and gate steps;
  • dead anchors;
  • guard-agreement counts (28 of 28);
  • future work that is done;
  • LICENSING.md's tense for modules that do not exist yet;
  • the testing README's tables;
  • a new PERFORMANCE section for 0.1.8–0.2.0.
• The whole-token ternary figures are now dated. The 0.23–0.25 s per token of the 0.0.3–0.0.6 records was measured with the model resident in memory. The gates since 0.1.0 measure 4.5–5.2 s, because this laptop can no longer keep the 2.31 GB file in its page cache (1.04 GB stayed resident after a full read, with other applications holding memory), so both runtimes wait on the disk. The per-matmul A/B on cached tensors still shows 9.8×. A re-measure on a machine with ≥ 3 GB free is in docs/TODO.md.

0.1.9 — 2026-09-29

The TODO's 0.1.9 items, and the third audit fixed. The first answer after an engine restart is 8.6× faster, the chat can no longer silently lose its history, and bge-m3 runs live. Record: testing/results/0.1.9.txt.

Faster

• The system prompt's KV survives a restart (KoboldCpp's and llama.cpp's slot saving). The carrier starts with a slot directory (bankml serve --slot-dir, passed on as --slot-save-path). After the first answer of an engine's life, the chat saves the slot: 51 MB for Savante's 282-token prompt. On the first question to a new engine it restores it. Measured live, same question at temperature 0:

  • first answer 132 s → 15.4 s;
  • prefill 118 s → 1.2 s (315 prompt tokens → 1);
  • restore 0.05 s;
  • identical answer, because the same tokens give the same KV.

  A model switch or a Resources change no longer costs a two-minute first answer. The newest three slot files are kept, and each is keyed by model sha256, context and system prompt.

Fixed (the third audit, of 0.1.7–0.1.8)

• HIGH: the history window could send no history at all. With the persona prompt plus .memory, 0.1.8's budget (at ~3 characters per token) left room for about one exchange. The window then stepped past even that, and with the long sAGI.prompt nothing was ever sent. Now:
  • the budget is counted in the engine's own tokens (llama-server /tokenize, cached per text), against the context the engine actually runs with (n_ctx from /props, not the saved setting);
  • the window keeps as many recent exchanges as fit, moving in steps of at most half of what fits, so at most a couple are left out and the prompt cache stays warm between moves. At 2048 tokens it now sends 4–6 exchanges, where 0.1.8 sent 0 or 1;
  • when history is trimmed, the answer says so: "history: k of n exchanges fit the engine's N-token context — raise the RAM budget in Resources for more". Nothing is silent.
  • It was hot-patched into the running UI before this release.
• An answer's own <sub> (a formula) is no longer cut when the chat footer is stripped.
• Resources:
  • the context is re-planned per model from the saved RAM budget, so a larger model no longer inherits a context planned for a smaller one;
  • a failed Apply restores your previous settings (not the defaults), and reports both errors.
• connectors.load checks every private blob before writing anything: a refusal no longer leaves an agent half-overwritten.
• Embeddings:
  • one writer per cache file (a lock, and one write per line);
  • the background indexer is marked running before its thread starts, so two quick searches start one indexer;
  • query vectors are keyed by the model's digest.
• bankml serve:
  • /bankml/usage samples at most once a second, so polling cannot tie up connection slots;
  • the over-capacity 503 is not lost to a reset;
  • sysconf is declared with C types.
• bankml usage abc is an error, not a report on bankml itself.
• testing/pinned.sh takes its CPUs from the shell's allowed set, and claims a memory cap only after reading it back from the cgroup.
• ::1 is no longer offered for interact mode: the Host check cannot parse a bracketed address.

Measured, and not done (docs/TODO.md)

• madvise / fadvise for hashing. From a cold page cache the 1.7B model hashes in 0.68–0.72 s against 0.59–0.78 s warm (364 vs 419 MB/s). The disk keeps up with SHA-NI; there is nothing for a read-ahead hint to win.
• PGO for bankml serve. The gateway adds 0.71 ms per request against 15–130 s answers (0.005 %).

Live

• bge-m3 ran for real: 9.2 s for the first call (load), 1.4 s for three texts after, 1.14 GB while loaded. It indexed .history, and the ragebar reports mindX's rage.py BM25 fused with bge-m3 (docs/embedding.md).

0.1.8 — 2026-09-29

Speed and efficiency, measured on fixed resources, and the house in order: the licence layers, the docs in docs/ behind a README that routes to them, and docs/TODO.md from four studies (the field, KoboldCpp, vLLM, Rust). Record: testing/results/0.1.8.txt.

Faster

• SHA-256 with the CPU's SHA extensions (SHA-NI), detected at run time, with the portable rounds kept as the model. It is 5.5× faster: 0.23 s against 1.25 s for 248 MB, and 2.9 s for the 1.16 GB 8B model, which hashes to its published pin and to coreutils sha256sum's value. Every bankml serve start and every model switch hashes the whole model, so every one of them is faster: restarting the 8B carrier took 7.0 s, against 25 s on 0.1.7. BANKML_NO_SHANI=1 selects the portable path.

• A chat window that keeps the engine's prompt cache warm. The history the model sees now moves in steps of six exchanges instead of sliding by one each turn. A one-exchange slide changed the text right after the system prompt, so the whole history was re-read every turn: vLLM's chained block hashes show why no prefix cache can help then, and KoboldCpp's "Smart Context" reserve is the same remedy.

  • Over 60 turns the window moves 8 times instead of 48, and 39 of 47 turns reuse the previous prompt.
  • The window also shrinks, in whole steps, to fit the engine's context.
  • The chat's footer (the clock and the receipt) is no longer sent back to the model; it was wasting tokens.

• Measured and not adopted, because neither is a gain beyond the noise, though both were token-identical:

  • speculative decoding with a draft model (Bonsai-1.7B for Bonsai-8B);
  • n-gram speculation, measured twice, the second time on fixed resources (testing/pinned.sh: cores 2–3, 2 threads, 2.5 GB). It was ahead in 5 of 6 paired runs (+0.01 to +0.36 tok/s, one −0.06), but the baseline itself ranged from 0.36 to 1.40 tok/s as other programs loaded the same cores. Being exact and costing no memory, it is offered as an opt-in: bankml serve --spec-ngram, and a checkbox in Resources, off by default.
  • KV shifting (--cache-reuse) is rejected outright: it is not token-identical.

  Details and sources are in docs/TODO.md.

Added

• Resources: CPU and RAM sliders in the chat's side column.
  • The threads slider and a RAM budget, which bankml turns into the largest context that fits (weights + engine overhead + KV cache at the architecture's bytes per token, as bankml guard reports it).
  • Apply restarts the engine through the verified switch, is refused mid-answer, and is remembered.
  • Usage now reads what the engine uses.
• sys.rs, bankml's psutil, with no crates. It reads memory, cores, and each process's resident memory and CPU time from /proc, which is what psutil and Rust's sysinfo read on Linux. GET /bankml/usage on serve (itself and the engine it launched), and bankml usage [PID …].
• testing/pinned.sh: benchmarks on a fixed amount of processor and memory, with cores pinned (taskset), a hard RAM cap and no swap (a user cgroup), and the load recorded before and after.
• Licensing layers (LICENSING.md). Own code is MIT OR Apache-2.0 (LICENSE-MIT, LICENSE-APACHE): open source, do what you want, rights preserved. Key handling will be GPL-3.0-only in an opt-in module, so no black-box modification ships. AGPL-derived code only walled off. Every source file carries an SPDX header, checked in the gate (testing/spdx_check.py).
• Docs in docs/ (usage.md, TECHNICAL.md, PERFORMANCE.md, oracles.md, research.md, embedding.md, TODO.md). The README opens with a Documentation section that sends each reader to the right one.

Fixed

• A refusal could reset the connection. When bankml serve refused a request (a foreign Host, a non-JSON POST) it closed without reading the body. Closing with unread data makes the kernel send RST, so the client could lose the refusal. It now reads and discards the declared body first. The CLI suite passes 10 times in a row, where it had failed under load.
• The CLI tests kill the serve they start even when an assertion fails (a leaked child held the test's pipes open).

0.1.7 — 2026-09-29

A second audit, of the parts the first did not cover (the gateway, the chat path, commitments, agents, PostgreSQL, the chain), with every finding fixed and tested. Savante gains the embedding model mindX uses (bge-m3), and research.md places bankml among its peers. Record: testing/results/0.1.7.txt.

Fixed — bankml serve (Rust)

• A loopback caller could crash it or pile up threads. Its limits are now:
  • at most 32 connections;
  • a 30 s read and 120 s write timeout;
  • request-head lines of at most 16 KiB and at most 100 headers;
  • upstream bodies and chunks of at most 64 MiB;
  • chunked requests refused.
• A receipt could name a model the engine was not running.
  • --spawn now refuses when the port already answers, so it can no longer bind to a leftover engine.
  • A spawned llama-server that dies is noticed at once, not after the 900 s health timeout. That timeout was what made a failed model switch take 15 minutes.
  • SIGTERM, SIGINT and SIGHUP stop the spawned engine too.
  • Before every answer, serve re-checks the file's identity (device, inode, size, mtime) and the engine's /props path. If either changed it refuses (503) rather than receipt weights it did not verify.
• Receipts name the request. A new request_sha256 field hashes the request body, and a "signed": false field says what the receipt is. The docs now say plainly that receipts prove integrity between a client and its own gateway, not to a third party.
• Web pages cannot drive it. It requires a loopback Host, which blocks DNS rebinding, and a JSON Content-Type on POST, which blocks the simple cross-origin form POST.
• Correctness.
  • A final SSE line without its newline is forwarded and counted.
  • Unpaired \u surrogates decode to U+FFFD, the same way the UI hashes them, and an escape after an unpaired high surrogate is no longer swallowed.
  • HTTP reason phrases are right (403, 413, 415, 500, 503, 504), and a garbled upstream status becomes 502.

Fixed — the chat, .history and commitments (Python)

• One torn line no longer blanks .history or .memory. Damaged lines are skipped and counted. Each record is one locked, fsynced write, and it starts on a new line if the file ends mid-line. Rewrites of .memory are atomic.
• Model switches can no longer be blocked forever. Busy tracking is a per-request in-flight table with stale expiry, instead of one global that a closed tab or an exception in system_prompt() could leave set, and one tab's finally could clear for another. A timer left running by a lost request expires.
• Receipt checks no longer fail on answers with a <think> block or surrounding whitespace. The raw text is stored as assistant_raw and checked; the docs had said this was already so. The text is choices[0] only, as the receipt hashes it.
• An exchange cannot land in the wrong agent's history. The .history path is fixed when an answer starts.
• The Merkle tree is now RFC 6962.
  • Leaves are sha256(0x00 ‖ line) and nodes are sha256(0x01 ‖ l ‖ r), so an interior node can no longer pass as a record.
  • The tree is split at the largest power of two, so an odd node is promoted, and 3 records and 4 records with the last repeated no longer share a root.
  • Proofs carry the index and the tree size and are verified as RFC 9162 §2.1.3.2 prescribes.
  • The roots match the Certificate Transparency reference vectors.
  • Scheme rfc6962-sha256. Roots differ from 0.1.6's.
• Interact mode is loopback only, enforced. --mode interact --host 0.0.0.0 is refused, and a non-loopback Host header gets a 400.

Fixed — agents, PostgreSQL, the chain

• The 15 doctrine clauses are now fixed at derivation, as the docs said. save() refuses a persona edit that changes them and names the clauses. verify() uses bankml's pointer list, not the one inside the ledger it is checking, and also checks that the root is unchanged since derivation.
• Publishing to PostgreSQL is one transaction. A failure part-way changes nothing. load() can be anchored to an outside contentRoot (a token's), and says whether it checked against one or only for self-consistency.
• chain.py.
  • A devnet send goes only to a node on this machine, since a remote node can report chain 31337.
  • Addresses must be 20 bytes; a short one would have shifted every argument the owner signs.
  • The cast line quotes every argument.

Fixed — view mode

• A 20 s socket timeout, so a slow LAN client cannot hold a thread.
• /api/state is computed at most every 2 s, however many viewers poll.

Added

• Embedding with bge-m3, the model mindX uses (1024-d, MIT; served by the local Ollama). See embedding.md.
  • The .history ragebar ranks by words (BM25) and meaning (bge-m3) together, by reciprocal rank fusion.
  • PostgreSQL publishing fills bankml_exchanges.embedding in the same transaction.
  • Vectors are cached beside .history, keyed by the sha256 of the embedded text and tied to the model's digest.
  • It is optional and guarded: without the model or the memory to load it, search is BM25 alone.
  • On this laptop, with other applications holding memory, the guard refused to load bge-m3 (1.0 GB free, 1.3 GB needed), which is what it is for.
  • An embedding model is never offered as the chat carrier.
• oracles.md: every oracle bankml is checked against, what each checks and how, and what it found in this gate. The oracles are the compiled llama.cpp kernels, the scalar models, the Python guard, FIPS 180-4 and RFC 6962 vectors, published roots and CIDs, the THOT spec, and the iNFT contract. It also states the rule: the same bits first, then the speed.
• research.md: Rust inference engines, 1-bit and ternary inference, and verifiable inference as of 2026-09-29, with links and 26 papers. Its verdict:
  • bankml's bit-exact oracle against the compiled llama.cpp, and its plain-AVX2 Q2_0 kernel, have no public equivalent;
  • others are ahead on a native forward pass, GPUs, breadth of formats, ARM and attestation.

Tests

• Rust:
  • bounded heads and bodies;
  • loopback hosts only;
  • unpaired surrogates;
  • file-identity changes;
  • in the CLI test against a mock engine: 403 for a foreign Host, 415 for a non-JSON POST, 503 without a receipt once the model file changes, and request_sha256.
• test_ui.py:
  • RFC 6962 reference roots and second-preimage cases;
  • a torn line;
  • raw-text receipts;
  • stale in-flight expiry;
  • fixed doctrine;
  • the offline embedding path (a fake Ollama).
• test_connectors.py: an atomic publish, and an anchored load.
• test_chain.py: a remote devnet refused, a short address refused, and a quoted cast line.

0.1.6 — 2026-09-29

An audit of 0.1.5, and every finding fixed with a test that would have caught it. Record: testing/results/0.1.6.txt.

Fixed — the carrier switch (ui/models.py)

• A slow start was declared failed, leaving two carriers running. bankml serve hashes the whole model before it binds a port, so a 5 GB file on a cold cache took longer than the 20 s "no ports, so it died" heuristic. The switch then rolled back while the new serve kept going, and both fought over 18092/18093. The switch now waits on the process itself: it stops only if the process exits or the deadline (30 min) passes, and then kills the process group (serve and the llama-server it spawned).
• Success now means the chosen model. A carrier that answers counts only if its verified sha256 is the chosen file's. An old carrier still holding the port is reported, not mistaken for success.
• Ports are matched on the configured host (127.0.0.1, 0.0.0.0, [::1] …) and only for this user's bankml / llama-server. Stopping never crashes on a process that has already gone. If the ports cannot be freed, the switch says so.
• Rollback also restores a previous carrier outside .models (for example ~/sAGI/bonsai/…), found by its verified sha256 and its pin.
• Memory is checked before any switch and any adoption, not only before a download.

Fixed — downloads

• A complete .part (the process died between the last byte and the rename) is verified and kept. Previously every retry asked for bytes=N- and got 416.
• A 206 whose Content-Range starts elsewhere is not appended; the download starts over.
• A source that sends more than the published size is cut off and discarded, not written until the disk fills.
• Ollama adoption is really offline. It reads the local manifest and licence layer, so it is pinned to what was pulled even if the registry's tag has moved since.
• Input. ./.. segments, slashes in a revision, and odd Ollama tags are refused. Hugging Face files in sub-folders keep their folder in the local name, so two model.gguf files no longer collide.
• Gated repositories are refused with a reason, not a raw 401.
• If an answer is streaming when an import finishes, the import stands and the switch waits, instead of the whole job failing.
• Cancel download in the Models tab. The partial file is kept, and importing again resumes it.

Fixed — the UI and view mode

• The Models tab no longer holds a queue worker for a whole download. Handlers return at once, and a light 2-second poll follows the job, so chat and the timers keep their workers.
• One damaged file no longer breaks /api/state for the whole LAN. A damaged export record reads as "not current". The voice manifest and export records are written atomically. Any unexpected error returns a 500 instead of a dropped connection.
• Exports stream in 1 MiB chunks instead of being read into memory whole.
• /api/state is cached until the voice manifest, an export or TECHNICAL.md changes (at most 30 s). The voice manifest is re-read only when it changes, and the pronunciation table is compiled once, not per sentence.
• Export robustness. Exports are built beside their destination, so the final rename is atomic even where /tmp is tmpfs. The concat list quotes paths safely. A clip missing from the manifest is measured with ffprobe, so the chapter marks don't drift.

Fixed — pronunciation

• bankml's respellings now run before underscores become spaces, so Q1_0, Q2_0_g64, Q4_K_M and q1_0.rs are read as formats and files ("Q one zero", "Q four K M", "bank M L dot R S").
• Maths symbols are read only in maths:
  • "Professor / OVERLORD" and "DAIO · savante_sagi" keep their separators;
  • "8 / 128" still becomes "8 over 128".
• Section references read as "section three point four"; a parenthesis that only points somewhere is dropped.
• Names are matched case-insensitively ("Bankml").
• The 18 sentences whose spoken form changed were re-rendered, and both exports rebuilt.

Tests

• test_models.py gains 9 checks (28 in all with the carrier):
  • input refusal (.. segments, revisions with slashes, odd tags);
  • complete .part;
  • misplaced 206;
  • over-send;
  • one job at a time;
  • memory on adoption;
  • exact listener matching;
  • a different model answering is not success;
  • a slow start is waited for, then killed.
• test_ui.py gains pronunciation regressions and a damaged export record.
• Rust: Verified::to_json stays valid JSON with a hostile model name (quote, backslash, newline, control character).

0.1.5 — 2026-09-28

Models come in without friction, and only open-source, sha256-pinned ones: Bonsai-8B on first run, then the catalogue, any Hugging Face GGUF, or Ollama. The metrics become readable charts. The voice controls get a dock. Savante reads bankml's thesis and the binary / ternary argument, and her audio is exported and committed. Record: testing/results/0.1.5.txt.

Added — models

• The importer (ui/models.py, the Models tab, python3 ui/models.py). Its sources:
  • First run. If no carrier answers when interact starts, Bonsai-8B is imported (only if absent), pinned and verified, and bankml serve is started in the background with progress shown.
  • Catalogue. Eleven open-source models: Bonsai-8B (default), Ternary-Bonsai-8B, Bonsai-4B and 1.7B, Qwen3 0.6B / 1.7B / 4B / 8B, SmolLM2-1.7B, SmolLM3-3B and Granite-3.3-2B. Each is pinned to its repository's revision, size and sha256, read 2026-09-28, and an import refuses if the repository no longer agrees.
  • Hugging Face. Any repository or file URL. The licence is read from the repository, and the pin is its LFS sha256 at the resolved revision.
  • Ollama. Search ollama.com; import from the registry, where the model layer's digest is the GGUF's sha256 and the licence layer is read; or adopt a model the local Ollama holds, by link with no download.
• The trust chain. Every file is hashed as it streams, and kept only if it equals the published sha256; an interrupted download resumes. bankml guard must then say play, and a FORK.json pin is written, so bankml serve verifies it before every start.
• Open source only. A licence outside the OSI list is refused before any byte is fetched: Gemma and Llama on Hugging Face and on Ollama, and anything unrecognised.
• The machine's limits. An import that would leave less than 1.5 GB free on disk, or whose weights exceed about 70 % of RAM, is refused with the numbers.
• Carrier switch. Stop, then start bankml serve --spawn llama-server on the chosen model. It is refused while an answer is being written. If the new model does not come up, the previous one is restored; it is found by its verified sha256, because serve reports canonical paths.
• Verified on this laptop:
  • Qwen3-0.6B Q8_0 was downloaded from Hugging Face, and qwen3:0.6b (a Q4_K_M) was adopted from the local Ollama; both are pinned, and both answered through bankml with receipts;
  • Bonsai-1.7B, already here, was pinned against the published sha256;
  • a switch, a refusal while busy, and a rollback from a bad pin all ran on spare ports.
• testing/test_models.py: 19 checks, in the gate. The source is a loopback server with a synthetic GGUF, and a real carrier runs on spare ports.

Changed — bankml (Rust)

• Standard models, named and reported. gguf::type_name names all of ggml's standard types (Q8_1, Q8_K, the IQ family, I8–I64, F64, MXFP4), and a new test confirms a K-quant model plays on mainline. The guard already played such files; nothing about them was allow-listed or refused.
• Verified carries what was verified: arch, name and the tensor types. /bankml reports them, so the UI shows "qwen3 · Q4_K×155, Q6_K×15" and sends /no_think only to families that honour it (Qwen3, SmolLM3, Bonsai).

Changed — metrics

• Readable charts replace the old bar strip, whose bars became "giant blue blobs" when there were few exchanges: one bar was stretched across a third of the width.
  • Summary tiles: exchanges and sessions, median and p90 first-token and response times, writing speed, and answers matching their receipts.
  • Response time per exchange: stacked bars (waiting, then writing), at most 18 px wide, on a round-numbered axis with a median line. One slow outlier is clipped with a ▲ so the rest stay readable.
  • Throughput per exchange: prefill and writing tok/s as lines.
  • The charts keep their proportions at any width, and dark mode is transparent.
• Commitments read one per line: the .history record count, Merkle root, CID, and .memory. An empty root reads "— (empty)", not "None".

Added

• The VOICE dock. The DreamKnobs no longer sit inside each section. They appear only when a PLAY is pressed, in one dock beside the card: a vertical stack in the side column by default. ⤒, ⤓ and ⇥ dock it to the top of the card, the bottom, or back to the side (top and bottom lay the knobs in a row). It can also be dragged by its grip onto a drop zone and resized from its corner (40–96 px). Place and size are remembered per browser. Verified in headless Firefox:
  • hidden before play, and a vertical stack to the right of the card after it, with no overlap;
  • above the card when docked top and below it when docked bottom, horizontal both times;
  • back at the side, with the choice remembered.
• SCIEN·TIFIC in the introduction. A new chapter, marked as bankml's own note rather than her canon (ui/voice/readings/scientific.md), follows "Why I exist". It takes 2²⁵⁶ − 1 (SCIEN·TIFIC's whole supply, the largest value one EVM word holds, about 1.16 × 10⁷⁷; scientific.pythai.net) first as the finest resolution a single word allows, the maximum measurement of accuracy, and then as a measure of size. The atom count is stated as measured: estimates for the observable universe run from 10⁷⁸ to 10⁸², so by a strict count 2²⁵⁶ falls short, but it is of the same order of scale.
• The reading. Savante reads bankml's thesis and the binary / ternary sections of TECHNICAL.md (§II.1, §III.2, §III.5, §III.8) verbatim, as its own section of the card with ▶ PLAY THE READING. It is also in the view mode's Listen panel.
• TECHNICAL.md §III.8, "Can a binary computer perform a ternary operation?" Yes, exactly. A trit is stored in bits (log₂ 3 ≈ 1.585 bits of information; Q2_0_g64 spends 2 bits plus the scale). The ternary product is a signed sum, which bankml computes as Σ c·x − Σ x with the offset code c = w + 1 (vpmaddubsw, then one subtraction of an activation sum shared by every row). The section also covers Setun and why packing, not native ternary gates, is the next ternary speed-up on a bandwidth-bound CPU.
• Export. ⤓ Savante.opus holds the voice examples and the whole introduction; ⤓ Savante-reading.opus holds the reading. Each is one Ogg Opus file (40 kbit/s) with a chapter mark per chapter. It is made only when every sentence is rendered, carries a signature of the exact clips it was built from, and is rebuilt when one changes. Both are offered in the card, and in view mode at the fixed routes /export/Savante.opus and /export/Savante-reading.opus, which serve only a named export that is complete and current. python3 ui/speak.py renders everything and writes both files; --prune drops clips no current text uses.
• The audio is in the repository. ui/voice/cache/savante/ (every clip plus its manifest) and ui/voice/export/ are committed, so a fresh clone plays and downloads without rendering. The voice is built from public-domain Cori (see 0.1.3).

Changed

• Speech. List markers are removed only at the start of a line, so an inline "16 + 2" is no longer read as "16 2". bankml's own spoken forms go before the house table: SCIEN·TIFIC ("Sci-en, Tiffic"), bankml ("bank M L"), web addresses ("dot"), and TECHNICAL.md's notation (Σ, ∈, ≈, ≤, ×, {−1, 0, +1}, Q1_0, and section references, which are dropped). This re-rendered a dozen sentences of the introduction whose spoken form changed.
• The view's voice label says "Savante's own voice" when Piper is present (it still said "house stand-in").

0.1.4 — 2026-09-28

The knobs in view mode, and a timer that counts real seconds. No Rust code changed. Record: testing/results/0.1.4.txt.

Added

• Knobs in view mode. Anyone listening on the LAN gets the same DreamKnob controls (SPEED, FM RATE, FM DEPTH, GAIN, VOLUME), hidden until they press play, then emerging in the Listen panel. They run the same voice chain as the card: GAIN, then the FM delay line, then VOLUME, with speed pitch-preserved. Each listener's settings stay in their own browser. The bundle is served from a fixed /knobs.js, and the view's CSP allows 'self' scripts for it. Verified in headless Firefox against a test instance of the view server:
  • hidden before play, emerged after it, with five knobs;
  • audio playing through the chain;
  • a SPEED change reached the audio (1.5×);
  • the line being read highlighted.

Fixed

• The timer's seconds. It was redrawn by the server once a second, so its tenths never moved (it always ended in ".4"). The browser now counts from the moment Send was pressed, ten times a second, and the server only changes the phase. Verified in a browser: a timer stamped 12.3 s earlier read 24.6 s after the page was held for 12 s.

0.1.3 — 2026-09-28

Savante gets a voice of her own: calm, confident, slower and more thoughtful. The DreamKnob controls are now in the card where she plays. No Rust code changed. Record: testing/results/0.1.3.txt.

Changed

• Her voice. The eSpeak stand-in of 0.1.2 was a formant sketch and sounded harsh ("that voice is scary"). The operator's direction was to use Jaimla as the template, build from Cori, and make a voice that is Savante's own:

  • body: Piper en_GB-cori-high, trained on public-domain LibriVox recordings. Jaimla's own voice (Piper jenny_dioco) comes from a custom-licence dataset, so under the open-source rule it serves as the template, never the source. The body is rendered slower and steadier: length_scale 1.18 (about 142 wpm), noise 0.50 and timing noise 0.60 (down from 0.667 and 0.8), and 0.8 s of silence after each sentence;
  • Jaimla as the template: each clip's own f0 is measured and moved onto Jaimla's measured 182 Hz with rubberband, formants preserved. The result is lower and grounded, not a slowed tape. Measured: f0 181–185 Hz;
  • SAVANTE's resonance (the house recipe in docspeech_voices.json): her own voice an octave below, 80–2600 Hz, heard only in echo (4 taps at 29 ms, decay 0.5), at 0.30. It is taken from the same clip, so it is locked to her delivery exactly;
  • EQ: SAVANTE's curve with presence +6 dB at 3 kHz and a +4 dB shelf above 5 kHz. Her brightness stays near Cori's own (centroid about 2270 Hz). Forcing Jaimla's 2783 Hz took presence that turns sibilant, the opposite of calm.

  It is rendered on this computer (Piper's standalone MIT release and the model, in ~/.local/share/bankml/piper, nothing committed) and cached. Every clip's measured f0 and pitch ratio are in the manifest. The eSpeak stand-in remains only as the fallback where Piper is absent.

• An oscilloscope behind the card. A phosphor-teal trace, graticule and persistence glow behind the card's translucent glass. While Savante speaks, it draws her actual waveform from a Web Audio analyser at the end of the playback chain, so SPEED and FM show in it. Otherwise it idles as a slow sine sweep. It only draws while the card is open and holds still under reduced motion.

• 3D depth: the card stands in perspective and tilts toward the pointer (up to about 5°), with a sheen that follows the tilt and sections raised on a bevel (light above, shadow below) over the scope plane. There is no tilt under reduced motion.

• PLAY plays. In 0.1.2's design a chapter offered PLAY only once every sentence was rendered, and during a render there was often nothing to queue. Now every sentence is listed, the rendered ones play at once (the rest show "rendering"), and chapter headers count what is ready. Rendering runs in listening order: the voice examples, then chapter 1, 2, 3 and so on. The buttons use one delegated click handler instead of inline attributes, and a clip still plays if Web Audio is unavailable. Verified in headless Firefox against the real card and page script: after PLAY ALL, audio advancing, the line highlighted, the knobs out.

• PLAY beside her name. It reads who she is (the card's description) and ends when that ends. The next PLAY THE INTRODUCTION continues from there, not from the start, and runs on through the introduction and her voice examples until stopped. A sentence's ▶ plays from that sentence onward.

• Every PLAY becomes ❚❚ PAUSE while playing, then ▶ RESUME at the exact point; the button in use is lit gold.

• GAIN and VOLUME knobs. GAIN (−12 to +12 dB) sets her level into the chain; VOLUME (0–100 %) is the master out. The oscilloscope reads between the two, so it shows her signal, not your listening level. Five DreamKnobs in all: SPEED, FM RATE, FM DEPTH, GAIN, VOLUME.

• Input ready: a slow-blinking (1.6 s), light-green, semi-transparent block cursor at the start of the empty input field, with the typing caret in the same green. It holds still under reduced motion.

• The knobs emerge when she speaks: no longer on the landing's settings panel. They are hidden in the card and slide out, in the section that is playing, the moment PLAY is pressed.

• Her text is shown as written: savante_sagi, core_command and APPROVE_WITH_CONDITIONS keep their underscores on screen and are spoken as words. The 0.1.2 cleaner dropped intra-word underscores.

• The page never waits on her voice: missing clips render in the background, and the card rebuilds on every page load, so it fills in as the renders finish.

0.1.2 — 2026-09-28

Savante speaks: her introduction and her voice examples, pre-rendered in her voice, with DreamKnob controls. No Rust code changed. Record: testing/results/0.1.2.txt.

Added

• Savante's voice, and only hers. The house defines SAVANTE (mindX docspeech_voices.json, id savante) as a layered piper voice: Jaimla's body, a resonance an octave below in echo, breath at the edges. That voice renders on the house render host. On this computer the UI uses the house's own stand-in for her, the cast entry savante in the DeltaVerse voice index: eSpeak NG en-gb-x-rp+jaimla at 168 wpm, which is what listen.html plays for her.

  • It is rendered here, under Node, by the same WASM build the DeltaVerse voice worker uses, with the house voice files installed before the first synthesis. A test confirms the variant really applies: it changes both the length and the hash of the audio.
  • Her name is said sav-ont: the house pronunciation table is applied to what is spoken, never to what is shown.
  • Every agent in this UI speaks with her voice.

• The introduction, in the card. Seven chapters that Savante reads to a new participant, verbatim from her canon: Who I am, My oath, What I believe, How I work (her .prompt), Why I exist (explanation.md), The manifesto, and Savante in full. That is 272 sentences, about 26 minutes. ▶ PLAY THE INTRODUCTION plays them all, ▶ chapter plays one, and any sentence's ▶ plays from there. The line being read is highlighted and scrolled into view.

• Her voice examples, in the card: all 14, with PLAY ALL and a ▶ per statement.

• DreamKnob controls in the settings panel (VOICE · Savante), built from the local ~/dreamknob workspace with React into one committed script (ui/voice/knobs/), as the playdocs rack is built.

  • SPEED: a vintage knob from 0.5 to 2.5× with the rack's snap points, pitch preserved.
  • FM RATE (0–12 Hz) and FM DEPTH (0–100 %): frequency modulation of her voice, an LFO sweeping a short delay line. At depth 0 she is heard as rendered.
  • Changes apply live, mid-sentence, and are remembered.

• Links in the card:

  • on Hugging Face: Savante (the Space PYTHAI/savante), sAGI (the skill in that Space), and Savante's loop (the dataset);
  • on GitHub: the sAGI engine (cryptoAGI/sagi), Savante's canon and bankml.

  All were verified live before linking. sAGI has no Hub repository of its own, so its link is the skill in Savante's Space.

• Listen to Savante, in view mode on the LAN. The same chapters and statements, play-all, per chapter and from any line, served by a fixed /audio/<key>.ogg route that answers only a 24-hex key listed in the voice manifest. The page's CSP gains media-src 'self'.

• ui/speak.py: the voice. Renders are cached by (engine, voice, rate, variant hash, table version, text) in a git-ignored ui/voice/cache/: Gradio refuses to serve any path with a dot-directory, and the audio is not source. python3 ui/speak.py pre-renders everything (286 statements, 27.5 minutes, 7.1 MB here). The UI renders whatever is missing in the background.

• testing/test_ui.py: 42 checks. The new ones cover the pronunciation (longest first, idempotent), speech from markdown, one real render to Opus, and the view's audio gate.

0.1.1 — 2026-09-28

Savante's aivatar and a layout that moves both ways. No Rust code changed. Record: testing/results/0.1.1.txt.

Fixed

• The side panel could be dragged left but not back to the right: the drop depended on the elements under the pointer passing the event up. While you drag the grip, two translucent drop zones now cover the two halves of the layout above everything else, so nothing underneath can take the drop. A ⇄ button on the grip also swaps sides with a click. The side is remembered per browser.

Added

• The aivatar card. Click the agent's portrait: a card opens, in dark glass with a fine grid, teal and gold accents and a slowly breathing glow. It holds:

  • the kind and card type, name, mantra and the card's attribute chips;
  • the description, oath, office (primary skill, scope) and beliefs;
  • the identity, verifiable rather than asserted: persona sha256, doctrine root, THOT identity (thot:, CID, contentRoot, generation, facets) and the ledger check;
  • every aspect of the persona in collapsible sections (BDI, skills, safety, embodiment, token, task, voice examples, exchanges, and the system prompt), rendered from the file itself;
  • every ledgered file with its size and sha256.

  The card opens and closes with a pure-CSS toggle (Gradio does not run scripts in HTML blocks), and the image is embedded, never served by path. A derived agent gets the same card with its own values.

• A chosen aivatar. Savante: any image in her canon's gfx/, the choice kept outside the canon. A derived agent: an uploaded image, checked by content (PNG, JPEG or WebP) and size (2 MB at most), ledgered as x-bankml.aivatar and included as a facet of its THOT bundle. Choose in Agents → aivatar.

• Refined resize handles: a slim corner with diagonal ridges, the same in every browser, replaces the browser's default resize grip on the side panel (width and height) and the chat (height). Sizes are remembered.

• testing/test_ui.py grows to 37 checks: an aivatar is accepted and ledgered, a non-image and an oversized file are refused, and the THOT bundle gains the aivatar facet.

Not tested by machine

• The drag itself: a real mouse drag cannot be driven in this headless setup, so the drop zones are verified by construction and by the ⇄ button's click path, which does the same move.

0.1.0 — 2026-09-28 · milestone: Savante with bankml

The first milestone. bankml is a verified low-bit runtime that answers on the computer at hand, behind its gate, with a receipt. Savante runs on it, and agents derived from her template can go from a prompt to a token and back, every construction checked against a published value. Record: testing/results/0.1.0.txt, the full gate: every kernel oracle, the A/Bs and budgets, and every test suite.

What 0.1.0 is (0.0.1 → 0.1.0)

• Kernels. Q1_0 and Q2_0_g64, bit-exact with llama.cpp b11192 on every weight of three real models. Ternary runs 9.2–9.9× the reference per token on three threads (0.23–0.25 s, less than the reference's 1-bit model). The measured memory floor shows both kernels compute-bound, at the laptop's instruction limit; five further variants were measured and rejected, with their code kept.
• The gate in front of every answer. Guard, sha256 pin, and bankml serve bound to the verified file, with a receipt carrying the answer's sha256.
• Savante.
  • Interact mode, on loopback: chat, .prompt, .history with response times, a RAGE search bar, Responses, .memory, Metrics, the verifier.
  • View mode on the LAN: the stdlib server, read-only, with commitments only.
  • Proof of data without the data: Merkle roots, CIDs, inclusion proofs.
  • Her canon read, never written, and checked against her iNFT ledger before she speaks.
• Agents.
  • Derived from her template, each with a ledger whose keccak256 doctrine root matches her binder's construction.
  • THOT manifests that reproduce the spec's test vectors.
  • PostgreSQL publish and load, byte-verified.
  • The iNFT path (new in 0.1.0): plan, simulate, unsigned transaction, devnet mint, and load from a token with the lineage walked back to the minted generation.

Added in 0.1.0

• ui/chain.py, stdlib: ABI encoding and decoding (byte-equal to Foundry's cast on selectors and calldata), JSON-RPC, the mintOpenAgent plan from a THOT bundle (contentRoot = the manifest's, metadataRoot = keccak of the card), eth_call simulation with the contract's custom errors decoded, the unsigned transaction and its cast send line, a devnet-only send (chain 31337; refused elsewhere), read_token and load_from_chain. A local devnet helper starts anvil and deploys iNFT_7857 from its artifact.
• THOT generations archived by CID (<agent>/thot/<cid>.json), so a token keeps resolving after the agent evolves. Loading walks the parent links from the current generation to the minted one.
• UI: Agents → iNFT: plan and simulate, unsigned transaction, mint on the local devnet, load from a token, and start a local devnet.
• Dark mode: transparent surfaces instead of white panels in interact mode, and translucent panels in view mode.
• testing/test_chain.py (13 checks, a throwaway anvil). It covers: the deploy from the artifact; simulation as minter and the decoded AccessControl refusal; the unsigned transaction; the mint and its read-back; the double-mint refusal; the load; the load again after two more generations; the refusal off a devnet; and an invalid dimension refused before any call. It skips where anvil or the artifact is absent (CI).
• Documents: usage.md §8e (iNFT), README, TECHNICAL §III.7 and contribution 14.

The gate record, plainly

Every kernel oracle is bit-exact, and every suite passes (37 unit, 6 CLI, 34 UI, 12 PostgreSQL, 13 iNFT-devnet, guard agreement 24/24). The 1-bit budget and both A/Bs measured normally. The ternary decode budget could not be measured undisturbed in this gate. With 1.7 GB of RAM available and swap full (other sessions and a browser resident), the 2.13 GB ternary model no longer fits in page cache and each pass re-reads it from disk (about 0.5 GB/s): 4.0–5.9 s per token for bankml, 5.1–7.3 s for llama.cpp. The code is unchanged since 0.0.3; its undisturbed figures are in the 0.0.5 and 0.0.6 records (0.44–0.45 s per token at 1 thread, 0.24 s at 3).

What 0.1.0 does not claim

• bankml's own forward pass (P3): answers still come from llama.cpp's arithmetic, behind bankml's gate.
• A public mint: iNFT_7857 is not deployed on a public chain, its audit is not cleared, and a mint needs MINTER_ROLE and the owner's signature. Savante's own verdict on minting remains DEFER.
• Stored bundles: storageURI is a local:// reference until a bundle is stored (the rung stays referenced).
• Embeddings: the vector(1024) column and its index are ready; nothing computes them yet.
• The laptop's own PostgreSQL still needs its one-time setup (sudo; usage.md §8d).

0.0.9 — 2026-09-28

Custom agents, their THOT bundles, and a PostgreSQL connector. Every new cryptographic construction is checked against a published value. No Rust code changed. Record: testing/results/0.0.9.txt.

Added

• ui/agents.py: agents derived from the Savante template, without writing to her canon. Each gets .persona, .prompt, an agent card (EIP-721 ∪ ERC-8004 registration-v1, not_yet_minted, derived_from) and a ledger: sha256 and CIDv1 per file, plus a keccak256 doctrine root over the same 15 JSON pointers as Savante's.
  • keccak256 is pure Python. It reproduces Savante's published doctrine root from her persona, and it equals pycryptodome for every length from 0 to 400 bytes.
  • Saving enforces the binder's preflight (ASCII keys, integers only, within ±2⁵³), and a missing doctrine clause is a hard error, as the binder specifies.
  • An agent that does not verify against its ledger does not speak.
• ui/thot.py: THOT manifests to sagi.thot_manifest/1.
  • Facets: core persona and prompt; custom x-bankml.agentcard, x-bankml.history and x-bankml.memory (history and memory committed by digest only).
  • The keccak bundle_root, the 64-leaf keccak Merkle tree, and the identity (thot:, CID, name, contentRoot).
  • Lineage by generation (a facet change gives n+1 with parent = the previous CID), relations to Savante's bundle, and a real git locator per agent.
  • Checked against the spec's three test vectors (Savante @1fcca89, Jaimla @8b57ccf, LuvAI @0c1eef7): bundle root, Merkle root and identity CID all equal. Savante's current generation-9 manifest verifies with no findings.
• ui/connectors.py: PostgreSQL through psql (stdlib, no driver).
  • publish: the public parts by default; .history/.memory lines only with an explicit opt-in.
  • load: refused unless every restored byte matches the THOT manifest.
  • vector(1024) embeddings column with a DiskANN (pgvectorscale) or HNSW (pgvector) index.
  • Values travel as COPY data into a temporary table and never enter SQL text.
• UI: an Agents tab (use, derive, edit and re-ledger, the ledger check, the THOT bundle, publish and load), and the chat, .history, .memory, Responses and Metrics follow the agent in use.
• Tests:
  • testing/test_ui.py grows to 34 checks: the THOT spec vectors and lineage, keccak vectors and the cross-check, the doctrine root against Savante's, derive/verify/save, preflight refusals, tamper detection, and path confinement.
  • testing/test_connectors.py (12 checks) runs against a throwaway PostgreSQL 16 cluster (initdb in a temp dir, pgvector): the schema, both publish modes, a byte-exact load, refusal of a tampered prompt and a tampered history line, an injection string stored as data, and the THOT generation step. It skips where PostgreSQL 16 or pgvector is absent (CI).

Not yet

• The laptop's own PostgreSQL has no role for the operator yet. The one-time setup needs sudo and is in usage.md §8d.
• Embeddings are not computed (the column is ready).
• The chain side (loading an iNFT, preparing a mint) is 0.1.0. The house iNFT contract (iNFT_7857, mintOpenAgent) is not deployed on any public chain, its audit is not cleared, and minting needs MINTER_ROLE.

0.0.8 — 2026-09-28

Savante's memory, made searchable, measurable and provable, with the documents brought up to date. No Rust code changed. Record: testing/results/0.0.8.txt.

Added

• .history tab with a ragebar. Every exchange, newest first: its time, session, time to first token, response time, tokens, and whether the answer matches its receipt. Before this it showed nothing until a button was pressed. The search bar (the GATERAGE ragebar's look) ranks exchanges as you type, using mindX's RAGE rage.py when present (RAGE_PATH) and the same BM25 built in otherwise.
• Responses tab: ⤒ first, ▲ previous, ▼ next, ⤓ latest through every answer. 📋 copy puts the answer on the clipboard, ➕ save to .memory keeps it, and 🔏 proof gives its inclusion proof.
• .memory (savante.memory, JSONL, outside the canon): notes typed or saved from responses, with their source. A side-panel switch appends them to the system prompt (newest first, 2,400 characters at most), labelled as the operator's notes, not evidence. The footer names how many went in.
• Metrics tab, computed from .history: time to first token, response time, prefill and writing speed (n, median, p90, mean, min, max), a bar per exchange, receipt-hash agreement, the last 25 exchanges, and each row's timing source (the press of Send, or the receipt for older records).
• Proof of data without the data. Each .history/.memory line's sha256 is a leaf of a Merkle tree, and the file has a sha256 and a CIDv1 (raw, sha2-256, base32: the construction of Savante's iNFT ledger; equal to mindX rage.cid_v1_raw). The view page shows only these commitments. An inclusion proof lets one exchange be checked against the root without disclosing the rest.
• testing/test_ui.py: 16 offline checks of the UI's data layer. They cover the CIDs, commitments, every inclusion proof, tamper and cross-record failure, the search, the metrics and .memory, and the view server (commitments present, content absent, traversal 404, POST 405). Run in CI and in the gate.

Changed

• TECHNICAL.md brought to 0.0.8:
  • The Abstract now includes the threads, the floor and P0.
  • The Thesis gains the principles stated on 2026-09-28, quoted and dated: incremental improvement with the oracle in the loop, the machine at hand, and proof of data while keeping the data.
  • Contributions 1, 5 and 8 are updated, and 12–13 are new.
  • New §III.6 (proof of data) and §IV.5 (the floor, and the five rejected variants).
  • §IV.4 no longer says bankml cannot answer.
  • Future work drops the 1-bit layout port (tried and rejected) and adds connectors, THOT and custom agents.
• README: status badge and phase table (P0 done; P2 with the 8B oracle and threads; UI row); the budget numbers (0.23–0.25 s, about 4 tok/s); the Savante section covers the new tabs and proofs.
• usage.md: the new tabs, .memory, and §8a on proofs (with a hand check in Python).
• View: the live log is capped at 60 % of the window, so the other panels stay in reach.

0.0.7 — 2026-09-28

Savante's UI, made to be watched and used: a LAN view, a professional look, response times, layout you can arrange, and a guide. No Rust code changed (the kernels and their 0.0.6 gate records stand). Record: testing/results/0.0.7.txt.

Added

• View mode on the LAN: ui/view.py, the Python standard library, not Gradio. The installed Gradio 3.37 has path-traversal bugs that let a client read files from the host (e.g. CVE-2023-51449, fixed in 4.11), so it stays on loopback. The view server has four fixed GET routes: the page; /api/state; /api/result?name=, for a name the results directory lists; and /savante.png. Every other path gets 404, POST gets 405, the page renders all data as text, and a strict Content-Security-Policy applies. It shows the live testing, the release records, CI, the laptop's load and swap, bankml serve's verification and Savante's office and ledger. Light and dark themes.
• Modular layout. In view mode every panel can be dragged by its title to a new position and resized from its corner; the layout is kept per browser, with a reset layout button. In interact mode the chat and side panels resize, and the side panel drags to either side of the chat.
• A response timer that starts at the press of Send and ticks every second: reading the prompt (prefill), then writing · first token at N s. Each answer's footer reads ⏱ sent HH:MM:SS · first token N s · answered in N s.
• Response times in .history: every record carries sent_at and answered_at (ISO 8601 with milliseconds and offset), first_token_s and response_s, next to the receipt.
• usage.md, the full guide: what runs where, setup, verifying the model, serve, both modes, .history, receipts and how to check an answer, the canon and its ledger, testing, troubleshooting, and a reference of commands, ports and variables. The README gains a four-step Using Savante.

Changed

• Interact mode uses one light professional theme: bordered panels and forced text contrast over Gradio's styles. The bankml serve panel was a raw JSON block that overflowed the side column; it is now a compact card that wraps inside its border.
• The Gradio queue runs 4 events at once, so the timer ticks while an answer streams.

0.0.6 — 2026-09-28

bankml answers on this laptop. The answers come through the reference engine (P0), behind the gate, with a receipt, in a Savante UI that anyone can watch.

Added

• bankml serve (P0, serve.rs, std only) is a loopback HTTP gateway in front of llama.cpp b11192's llama-server:
  • It starts only after verify passes (guard, then the sha256 pin to FORK.json).
  • The upstream must be serving the verified file. Either bankml launches it (--spawn LLAMA_SERVER), or a running server's /props must name the same canonical path. Otherwise it refuses.
  • Every /v1/chat/completions answer, streamed or not, carries a bankml_receipt. The receipt holds the version, the engine, the model sha256, the guard verdict, the tokens, the time to first token, the wall time and the sha256 of the answer text, so a client can check that what it shows is what the verified model wrote.
  • GET /bankml reports the verification.
  • What it is not: bankml's own forward pass (P3). The arithmetic is ggml's.
• ui/savante.py is the Savante chat in Gradio (3.x or newer), built from the Hugging Face template PYTHAI/savante. It has two modes:
  • interact (the operator): the chat, the .prompt picker, .history and the offline verifier. The .prompt choices are the persona's system_prompt (canon, ledgered, the default), sAGI.prompt (canon facet, ledgered) or the Space's Savante.prompt (not ledgered), each shown with its sha256. .history is a JSONL file outside the canon, and the last session reloads on start. Each answer is labelled a draft and carries its receipt.
  • view (anyone watching, read-only): the live testing log (testing/live.log, refreshed every 2 s), every release's gate record, CI status, the laptop's load, memory and swap (so a disturbed measurement shows as one), and Savante's office and ledger. It has no chat, no .history, and runs no commands.
• iNFT compatibility. Savante's canon is read and never written, not even a Python cache. At start the UI re-hashes every file that savante.commitments.json commits to: the nine artefacts, the card, the image and the thot bundle. If the persona does not verify, the UI refuses to speak as Savante. The Integrity tab shows the ledger, and bind/savante_verify.py runs from a button. Nothing mints; the card's status stays not_yet_minted.
• 2 new unit tests (the JSON reader and HTTP bodies) and 2 end-to-end tests of serve against a mock llama-server: the receipt and the answer hash, refusal of a wrong pin, and refusal of an upstream serving a different file.

Measured on the laptop (Ryzen 3 3200U), the real canon and model

• bankml serve verified Bonsai-8B Q1_0 (284a335a…, the fork's pin) and the running llama-server serving it.
• A Savante turn under the persona's system prompt: 316 prompt + 28 completion tokens in 125 s, with the first token at 113 s. Prefill runs at 2.8 tok/s in llama.cpp. The answer's sha256 matched its receipt.
• The canon ledger verifies 12/12; savante_verify.py exits 0 (APPROVE); ~/savante is unchanged afterwards.

0.0.5 — 2026-09-28

The third performance release, on the ternary kernel, with the testing shown live. No kernel changed: three experiments were bit-exact, and none was reliably faster. Gate record: testing/results/0.0.5.txt. Every oracle is bit-exact. Ternary stays at 9.2–9.6× ggml over a whole token, and 1-bit at parity.

Measured and not adopted (bit-exact, not reliably faster), code in testing/experiments/

• Q2Packed: the ternary weights repacked once at load time, as llama.cpp's repack.cpp does for other types. Each quad of blocks becomes 64 contiguous code bytes followed by its four f16 scales: the same 72 bytes, with the arithmetic unchanged. It measured 1.00–1.075× in the first run and 0.90–1.05× in the release gate, on the real ffn_gate, ffn_down and output tensors. That is within noise.
• Two-row decode tile, loading the activation once for two rows: 0.80×. Register pressure costs more than the shared loads save.
• Software prefetch of the weight row, 256–1024 bytes ahead: within ±3 % at 1 and 3 threads. The hardware prefetcher already follows a sequential stream.

Added

• testing/live.sh and a live log: the gate and every experiment append to testing/live.log, which the UI's view mode shows as it runs (branch ui, next release).

What the oracles and the stopwatch say after three performance releases

At 3 threads the ternary kernel moves about 9 GB/s against a 17 GB/s floor. Going from 1 to 3 threads gives 1.8×, and the laptop has two physical cores. So it is bound by compute per core, not by memory. It already does one multiply per weight, and moving the bytes around changes nothing measurable. On this Zen+ core, both kernels are at their instruction-throughput limit for bit-exact results. The gains still available lie elsewhere:

• the forward pass (P3), which turns the 9.5× matmul lead into tokens;
• a Zen3 or AVX-512 core (the node).

0.0.4 — 2026-09-28

Where the time goes, and a faster 1-bit prefill. Gate record: testing/results/0.0.4.txt. Every oracle is bit-exact. Two measurements in the gate were disturbed by other load on the laptop (swap full), so the record adds a re-run.

Added

• bench_memory_floor (par.rs) measures streaming read bandwidth on the laptop at 1–4 threads: 14.9–17.2 GB/s. Streaming one token's weights therefore takes at least 0.12–0.14 s (ternary) and 0.06–0.07 s (1-bit). Against that floor, bankml's ternary matmuls (0.23–0.27 s at 3 threads) are about 2× above it, and the 1-bit ones (0.34–0.37 s) about 5.5× above it. Both kernels are compute-bound, not memory-bound, which says where the remaining work is.
• q1_0::mat_mul_act / mat_mul_act_par: a 1-bit prefill over prepared Q8Act columns, using the selection kernel in a 1×4 tile. The ±1 expansion is shared by the four columns, and the scales are already f32, so nothing is converted once per column. A column that holds q = −128 falls back to the wrapping kernel. Measured against ggml's per-pair kernel (1024×4096 × 32 columns): 1.27–1.33× median (8.25 against 10.09–10.28 ns per block·column, min). The q8-byte tile it replaces measured 1.08–1.18×. Bit-exact against the scalar model of ggml on 1,500 random cases, and against ggml itself in ab_vs_ggml.

Measured and not adopted (the oracle said same bits; the stopwatch said no)

• Two 1-bit blocks per iteration, with their FMA chains interleaved: 1.00× on the GEMV, 1.05× on an L1-resident row. The kernel is not bound by latency.
• A "pair-order" 1-bit kernel that replaces a multiply (madd) with a 128-bit add, on the theory that Zen+'s single integer-multiply pipe is the limit. It was bit-exact and 0.84× on decode: the cross-lane extract and the widening cost more than the multiply they save. The source is in testing/experiments/q1_0_pair_order.rs for anyone who wants to try it on another core.
• (Already on record from 0.0.1: 2- and 4-row decode tiles, 0.81–0.99×.)

1-bit decode stays at parity with ggml (0.95–1.03× over the whole token). Every bit-exact variant tried so far runs at about ggml's speed on this core.

Testing

• The gate now also runs bench_q1_0_prefill_act and bench_memory_floor.
• testing/experiments/ holds the code of measured-and-rejected kernels.

0.0.3 — 2026-09-28

Threads, and more oracle evidence. Each speed figure below was measured with the oracles passing on the same code. The full record is in testing/results/0.0.3.txt, written by the new release gate.

Added

• par::Pool: a zero-dependency persistent thread pool. The caller's thread is worker 0. Each matmul wakes the pool instead of spawning threads: 12.6 µs per call against 88.8 µs for thread::scope, at 3 threads on the dev box. That is about 3 ms per token instead of 22 ms. The row scheduler hands out 16-row chunks from an atomic counter.
• mat_vec_par / mat_mul_par for Q1_0 and Q2_0. Every row goes through the same single-thread kernel, so the output bits do not depend on the thread count. Unit tests check this at 1–4 threads, and the whole-model budgets check it against ggml.
• An oracle on the real 8B 1-bit model: oracle_ggml_b11192_real_bonsai_8b_q1_0. All 254 Q1_0 tensors of Bonsai-8B (8,188,239,872 weights) dequantize bit-exact, 762/762 q8_0 rows are byte-exact, and 762/762 dot products are bit-exact against ggml AVX2 and generic. 0.0.2 covered only the 1.7B file for 1-bit.
• decode_budget_q1_0: one token's worth of all 253 Q1_0 matmuls of Bonsai-8B, against ggml's kernel on the same pool and scheduler, at 1–4 threads.
• testing/release_gate.sh runs the unit tests, clippy, both guard checks, every oracle, both A/Bs and both budgets, and writes testing/results/<version>.txt. A kernel change counts only if every oracle still passes.

Measured (dev box, Ryzen 3 3200U, 2 cores / 4 threads; all 253 matmuls of one token; min s/token over two runs)

threads	ternary: ggml → bankml	1-bit: ggml → bankml
1	4.22–4.65 → 0.45–0.47 (9.4–9.9×)	0.62–0.67 → 0.61–0.62 (1.00–1.07×)
2	2.65 → 0.31 (8.7×)	0.45–0.46 → 0.43–0.44 (0.93–1.13×)
3	2.27–2.36 → 0.23–0.25 (9.5–9.9×)	0.34–0.35 → 0.34–0.35 (0.98–1.00×)
4	2.11 → 0.23 (9.4×)	0.34–0.35 → 0.36 (0.96–0.97×)

bankml's ternary matmuls now take less time per token than ggml's 1-bit ones: 0.23–0.25 s against 0.34–0.35 s at 3 threads, although the ternary file is twice the size. The matmul-only ceiling for ternary rises from 2.77 tok/s (0.0.2, which spawned threads for each call) to 4.0–4.4 tok/s. The 1-bit kernel stays at parity with ggml. The 1-thread medians are noisy (ternary 0.62 s against 0.47 s min): the model does not fit in page cache alongside everything else in 5.8 GB of RAM.

Testing

• A new testing/ folder holds every test that lives outside the modules. It contains the release gate, the oracle generator, the guard harnesses (moved from tools/) and testing/cli.rs, a new end-to-end suite that runs the bankml binary. The suite covers verdicts and exit codes, a hostile header, pin and verify, and runs as a cargo integration test.
• testing/results/ holds each release's record. testing/README.md lists every test and where it lives.

Changed

• The ternary budget and the A/B harness use par::Pool for both engines instead of spawning threads per call. The ggml side runs on the same scheduler, so the A/B compares kernel with kernel.

0.0.2 — 2026-09-28

An audit of 0.0.1. The kernels are unchanged and re-proven: the oracles again pass on all 8,188,239,872 ternary and 1,719,904,256 1-bit weights against llama.cpp b11192. The fixes below all concern untrusted input, or an API that let safe code reach unsafe code with the wrong sizes.

Fixed

• The guard crashed on nested arrays. GGUF arrays of arrays were parsed by recursion with no limit, so a 24 MB header aborted bankml guard with a stack overflow (exit 134) instead of refusing the file. Nesting beyond MAX_ARRAY_DEPTH (64) now refuses, with the reason given.
• The guard's KV size could overflow. kv_f16_bytes_per_token multiplied header integers in i128 without checking. In release builds the value wrapped with no error and the verdict was play; debug builds panicked. An overflow now refuses, with the reason given. The Python guard, which uses big integers, still plays these files; the difference is listed in gguf.rs with the other deliberate differences.
• Soundness: activation fields were public. q1_0::Q8Act and q2_0::Q8Act2 exposed n, d, sum and the other fields that the AVX2 kernels read through raw pointers. Safe code could set n beyond the buffers and cause an out-of-bounds read. The fields are now private, with read-only accessors (n(), qs(), d()).
• Tensor spans were unchecked. Mmap::tensor and tensor_bytes truncated a 128-bit element count to 64 bits and used unchecked arithmetic. tensor_bytes also allocated whatever size the header claimed before it read the file. A new function, gguf::tensor_span, checks the type, requires whole blocks per row and rejects overflow. tensor_bytes now checks the span against the file size before it allocates.
• bankml pin with an unreadable --fork file said "no sha256 record: unpinned, refused" (exit 2). It is an I/O error, and now says so (exit 1).

Added

• bankml::verify and bankml verify FILE --fork FORK.json [--json] run the guard and then the pin as one gate: the check that P0 puts in front of every answer. --json prints the verdict, the model sha256 and the bankml version.
• bankml version and bankml::VERSION.
• CI (GitHub Actions) runs the build, the unit tests, clippy -D warnings, the Python guard suite and the Rust-vs-Python guard agreement check on every push.
• 4 new unit tests (31 in all): nested arrays, KV overflow, tensor spans, and verify.

Changed

• The Q8Act/Q8Act2 fields are no longer public (see above). This is an API break, allowed while the crate is publish = false and 0.0.x.

0.0.1 — 2026-09-26

First public cut: the P1 GGUF guard and sha256 pin, and the P2 Q1_0 and Q2_0_g64 kernels, all bit-exact against llama.cpp b11192.