Request access to Sally v1.0 research weights

Sally is a specialized AI for metabolic health and longevity. This repository publishes the v1.0 reasoning adapters for research and evaluation. It is not a distribution of the Sally AI product. Requests are reviewed manually, usually within 2 to 3 business days.

Sally v1.0 is not a medical device and is not validated for diagnosis, dosing, or treatment decisions. By requesting access you confirm you will not present its output as clinical advice, will not use it for automated dosing, triage, or unsupervised patient-facing deployment, and understand that these weights are a research artifact rather than the Sally AI service.

Sally v1.0

Sally is a specialized AI for metabolic health and longevity. Not a chatbot guessing, a strategist reading your data. This repository publishes the v1.0 reasoning adapters for research and evaluation.

Model Details

Model Description

Sally applies a preventive approach to metabolic health that a1c.io developed in house. Trained on that body of knowledge, it reasons about glucose behaviour, meal composition and sequencing, eating windows, sleep and activity, and supplement context, and answers with a position rather than a summary, holding hard boundaries around clinical territory.

The adapters carry the framework and the judgment, not a data connection. Given a person's numbers, Sally interprets them. Without them, it reasons from the framework alone.

A system prompt is required. These weights expect a prompt that establishes the strategist framing. Served with no system prompt at all, output reverts toward base-model behaviour: generic nutrition advice, and engagement with questions that should be declined. A short framing prompt is sufficient and no proprietary protocol text is needed, so evaluate accordingly rather than bare.

Sally is delivered as a system, and this repository is one layer of it:

Layer	What it provides	Where
Health context	Live biomarker ingestion from wearables and CGM, turned into structured context	Sally AI
Clinical grounding	Source-cited reasoning over that context	Sally AI
Skills surface	Typed capabilities agents call over REST and MCP	Sally AI
Consumer product	Daily insights, labs, food and glucose analysis	A1C Insights
Reasoning layer	The preventive framework, trained judgment, safety behaviour	this repository

These weights carry the trained judgment and none of the system around it: no biomarker data, no clinical grounding, no skills. Running them locally does not reproduce Sally AI. They are published so the reasoning layer can be studied in isolation.

Sally's behaviour comes from work that is not present in any base checkpoint: the preventive approach itself, the curated knowledge base that teaches it, the preference alignment that decides what a good answer looks like, and the safety boundaries that hold under pressure. The underlying transformer is the substrate, and an implementation choice for this release. It is named below because the adapters cannot load without it.

Developed by: a1c.io
Model type: Two-stage LoRA adapters (SFT then DPO), causal decoder, text generation
Language(s): English, Indonesian
License: Apache 2.0
Finetuned from model: Qwen/Qwen3-14B

Model Sources

Repository: https://huggingface.co/sallya1c/sally-1.0
Platform: https://console.a1c.io
App: https://a1c.io

Uses

Direct Use

Research, evaluation, and education in metabolic health, longevity, and glucose-aware nutrition. Loaded on top of the base checkpoint, the adapters answer domain questions directly with no additional scaffolding. See How to Get Started with the Model.

Downstream Use

The reasoning layer is intended to sit behind a system that supplies context. In production that system is Sally AI, which contributes the biomarker data, the source-cited grounding, and the skills surface. If you integrate these weights yourself, you are responsible for supplying that context, and for the safety enforcement described under Recommendations.

These adapters have no data connection, cite no sources, and expose no skills. They are not a self-hosted substitute for Sally AI.

Out-of-Scope Use

Sally is an analytical model, not a clinical instrument. It is not intended for:

diagnosis, medication dosing, or treatment decisions
clinical calculation or scoring, which belongs in purpose-built tools
unsupervised patient-facing deployment
any setting where a wrong answer carries clinical consequence without human review

The model is trained to decline and route to a clinician for type 1 diabetes, pregnancy, pediatric cases, eating-disorder presentations, and extended fasting.

Bias, Risks, and Limitations

Domain scope. Sally reasons within metabolic health, longevity, and nutrition. Outside that domain, behaviour falls back to the substrate with no particular tuning.
No data access and no retrieval. These weights carry no biomarker connection and cite no sources. Both are platform capabilities. Knowledge is fixed as of training, over a substrate with a January 2026 cutoff.
Judgment, not new facts. Training shapes how Sally reasons and what it recommends. It does not extend general medical knowledge, so factual claims deserve the same scepticism you would apply to the base checkpoint.
Population coverage. Training emphasises adult metabolic health. Guidance is not tuned for pediatric, pregnancy, or type 1 diabetes populations, which is why those cases are routed to a clinician rather than answered.
Confident tone. Sally is trained to state a position rather than hedge. That is the intended behaviour, and it means a wrong answer will also read as confident.

Recommendations

All medication, diagnostic, and treatment decisions belong with a licensed clinician. Sally is not medical advice.
Safety boundaries are trained in, not guaranteed. Enforce them in your application layer as well.
Keep a human in the loop for anything carrying clinical consequence.
Supply real context. Asked about a person's data without being given it, the model reasons from generalities.

Training Details

Training Data

a1c.io's own preventive health knowledge base, curated into instruction data, followed by a preference set defining what a good answer looks like in this domain.

The training signal is the framework itself, not biomarker data. Sally learns how to reason about metabolic health, and receives a person's numbers at inference time if at all. Both corpora are proprietary and not released.

Training Procedure

Two sequential LoRA stages over the base checkpoint:

Stage	Method	Purpose
1. SFT	LoRA r=16, alpha=32, 7 target modules	The analytical method and response format
2. DPO	LoRA r=16, alpha=32	Judgment, and steering away from generic diet-advice patterns

The adapter at the repository root is the one to load: stage 2 was initialised from stage 1, so the root adapter already contains the stage-1 update. sft-adapter/ is the intermediate stage-1 checkpoint, published for reference and ablation.

Do not load both. They are 0.9997 cosine-similar per tensor, so stacking them applies the stage-1 update roughly twice and degrades output quality substantially. Trained May 2026.

Evaluation

Testing Data, Factors & Metrics

Evaluation covers three factors: adherence to Sally's method, retention of general medical capability, and application of safety boundaries. Metrics are preference accuracy on a held-out set, a human-judged rubric for method fidelity, MMLU-medical for general capability, and refusal behaviour on safety cases spanning type 1 diabetes, pregnancy, pediatric, eating-disorder, and extended-fast presentations.

All of it was measured with a system prompt in context, on the unquantized adapters. Results for a prompt-free or quantized deployment are not established, and the safety cases in particular are pending re-measurement.

Results

Metric	Result
Response preference accuracy, held-out set	97.6%
Method fidelity, human-judged rubric (n=150)	94.0%
Safety boundary application	all test cases declined and routed to a clinician
MMLU-medical	80.8%, unchanged from the substrate

Two caveats that matter for anyone using these weights:

All figures were measured with a system prompt in context. These weights ship without one, so treat the numbers as an upper bound for a prompt-free deployment rather than a specification of it.
The safety figure has no published denominator. It covers five categories (type 1 diabetes, pregnancy, pediatric, eating disorder, extended fasting) and every case was declined, but the case count is not published and the result has not been re-measured on the prompt-free release. Do not read it as a guarantee.

Summary

Read the two ends together. General medical knowledge is preserved, so nothing was traded away, while preference accuracy and method fidelity reflect reasoning behaviour the substrate does not have on its own. What the training added is judgment, not trivia.

Technical Specifications

Model Architecture and Objective

LoRA adapters at rank 16, alpha 32, applied to the attention projections (q, k, v, o) and the MLP projections (gate, up, down). Stage 1 optimises a supervised language-modelling objective; stage 2 optimises a direct preference objective. Published as adapters only, so the base checkpoint must be downloaded separately.

Hardware

Inference needs whatever the base checkpoint needs, plus roughly 385MB for the adapters. For evaluation at scale, vLLM serves both adapters with --enable-lora --max-lora-rank 16. Merging the adapters into the base requires roughly 29GB of memory when done in Python, so use streaming merge tooling on smaller machines.

How to Get Started with the Model

pip install transformers peft accelerate torch huggingface_hub

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel
import torch

BASE = "Qwen/Qwen3-14B"
REPO = "sallya1c/sally-1.0"

tokenizer = AutoTokenizer.from_pretrained(REPO)

model = AutoModelForCausalLM.from_pretrained(
    BASE,
    torch_dtype=torch.bfloat16,
    device_map="auto",
)

# The adapter at the repository root is the one to load. It was initialised from
# sft-adapter and trained further, so it already contains the stage-1 update.
# Do not load both: stacking applies that update twice and degrades the model.
model = PeftModel.from_pretrained(model, REPO)
model.eval()

messages = [{"role": "user", "content": "Can I use oat milk in my coffee?"}]
text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
inputs = tokenizer(text, return_tensors="pt").to(model.device)

outputs = model.generate(
    **inputs,
    max_new_tokens=300,
    temperature=0.7,
    top_p=0.95,
    do_sample=True,
    repetition_penalty=1.05,
)
print(tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True))

Notes:

Reasoning tags. The substrate emits <think></think> blocks, often empty, before the answer. Strip them for display, or pass enable_thinking=False to the chat template.
Temperature. 0.7 is a good default. Lower toward 0.3 for determinism, raise toward 0.9 for variety.
Response length. Tunable at inference. State a target range when you need consistent length.
Stop sequences. <|im_end|>.

Citation

BibTeX

@software{sally_v1_2026,
  title = {Sally v1.0: A Specialized AI for Metabolic Health and Longevity},
  author = {a1c.io team},
  year = {2026},
  url = {https://huggingface.co/sallya1c/sally-1.0},
}

APA

a1c.io team. (2026). Sally v1.0: A specialized AI for metabolic health and longevity. https://huggingface.co/sallya1c/sally-1.0

Model Card Contact

Sally, Sally AI, and A1C Insights are products of a1c.io. This card covers the published weights, not the platform or the service.

Sally AI for developers · A1C Insights

Downloads last month: 5

Model tree for sallya1c/sally-1.0

Base model

Qwen/Qwen3-14B-Base

Finetuned

Qwen/Qwen3-14B

Adapter

(1168)

this model

Finetunes

1 model

sallya1c
/

sally-1.0