Skip to content

Open models

One public LoRA adapter on Mistral 7B for British English prompt optimisation, and an empty second repository

A rank 16 LoRA adapter on eight module names of Mistral 7B, built with PEFT and published with its weights, configuration and tokeniser, next to a card still to be written.

The Files and versions tab of roneymatusp/british-optimizer-mistral-final on Hugging Face at desktop width: the repository name, its tags and the seven files with their sizes, from adapter_config.json at 929 bytes to adapter_model.safetensors at 694 MB.
Desktop view of the public site, as captured for this case study
The same model page on a phone: the repository name, its tags, the Model card, Files and Community tabs, the configuration parsing warning Hugging Face shows for the adapter, and the first card fields, which read More Information Needed.
Phone view of the public site, as captured for this case study

The problem

A fine tuned adapter is useful to other people only if they can load it, see how it was made and judge whether it works. Publishing the weights is the easy part.

These two repositories are the founder's work on British English prompt optimisation for Mistral 7B. One carries a LoRA adapter: weights, a configuration and a tokeniser. The other is empty. Both were created on the same day in August 2025 and are public today.

This case study states what the repositories say and what they do not. The gap between the two is the problem NASCIA's method exists to close.

What was built

Two public repositories on the founder's Hugging Face account, both created on 11 August 2025. Only one of them carries an adapter.

roneymatusp/british-optimizer-mistral-final is a LoRA adapter for mistralai/Mistral-7B-v0.1, built with PEFT, tagged lora, sft and trl, and registered for text generation. It ships seven files: the adapter configuration, the adapter weights in safetensors (about 694 MB), three tokeniser files, the card and the git attributes.

roneymatusp/british-prompt-optimizer-mistral-lora has no model card and holds only a git attributes file. It is listed for completeness; nothing here claims more for it.

The purpose in both repository names is British English prompt optimisation. The card does not describe what the adapter does to a prompt, and the second repository has no card, so this page does not either.

How it works

LoRA leaves the base model's weights as they are and trains small low rank matrices on chosen modules; at inference the two are combined. The adapter configuration shows the choices: rank 16, alpha 32, dropout 0.05, on eight module names in the base model: q_proj, k_proj, v_proj and o_proj in attention, gate_proj, up_proj and down_proj in the feed forward block, and lm_head, the output head. The task type is causal language modelling; bias terms, DoRA and rsLoRA are off. The framework is PEFT 0.17.0.

A prompt enters Mistral 7B with the LoRA adapter on eight module names and text comes out; the adapter configuration, its weights and the tokeniser are the files published on Hugging FacePromptMistral 7Badapter on 8 module namesLoRA adapter, r 16GeneratedtextHugging FaceConfigWeightsTokeniser
A prompt enters Mistral 7B with the LoRA adapter on eight module names and text comes out; the adapter configuration, its weights and the tokeniser are the files published on Hugging Face

To run it, a reader downloads the base model from Mistral and the adapter from the repository, then loads the adapter over the base with PEFT. The card does not include that code. The configuration also leaves the base model path empty, so the Hugging Face page shows a parsing warning and its usage panel cannot find the base model; anyone loading the adapter names the base model themselves.

Evidence

The numbers on this page come from the repository files, not from a card. Rank 16, alpha 32 and dropout 0.05 are in the adapter configuration (open-models-06), as is the list of eight target module names (open-models-07). The adapter weights are 694,438,976 bytes, as listed by the Hugging Face file tree (open-models-10). Both repositories were created on 11 August 2025 (open-models-11).

What is missing matters as much. The model card is the unfilled Hugging Face template: developer, licence, training data, evaluation and results all read "More Information Needed" (open-models-12). The second repository has no card at all (open-models-13). There is no published evaluation of this adapter, no stated licence and no stated training data, and this site claims none.

Stack

Mistral 7B v0.1 as the base model; a LoRA adapter through PEFT 0.17.0, tagged sft and trl; weights in safetensors; the Hugging Face Hub for distribution, in the repository roneymatusp/british-optimizer-mistral-final.

What it demonstrates

Define: one narrow task, one open base model, one adapter. The repository name states the task and the configuration states the method.

Instrument: this is where the artefact falls short, and we say so. Without a published evaluation nobody can tell an improvement from luck. That is why the harness now comes before the model on every engagement.

Integrate: the adapter uses the standard PEFT format and ships its tokeniser, so it loads with the same tooling as any other PEFT adapter.

Hand over: the weights are public and the configuration is readable by anyone. The card should carry the rest, and this page names the fields that are still empty.

Evidence

LoRA rank, with alpha 32 and dropout 0.05Source: adapter_config.json in the repository (open-models-06), 24 September 2026
16
target module names: the attention projections, the feed forward projections and the output headSource: adapter_config.json in the repository (open-models-07), 24 September 2026
8
of adapter weights in safetensors, 694,438,976 bytesSource: Hugging Face file tree (open-models-10), 24 September 2026
694 MB
both repositories created on the same daySource: Hugging Face Hub API (open-models-11), 24 September 2026
11 August 2025

Stack

  • Mistral 7B v0.1
  • LoRA
  • PEFT 0.17.0
  • TRL
  • safetensors
  • Hugging Face Hub

More work

  • Answer leakage study

    A forensic audit showing how often test feedback handed coding agents the expected answer

    Read the case study
  • HELIX V6

    A runtime for AI workloads with local inference: orchestration, memory, tool routing and evaluation

    Read the case study

Bring us the process that keeps breaking.

One conversation is usually enough to tell whether a system like this belongs in your operation, what it should be measured against, and what it would take to keep it running.

Talk to NASCIA