Letterweave-1.0-E2B

Letterweave-1.0-E2B is an English email-purpose decision model published by Groktopus. Given an email subject and body, it returns seven independent presence/absence judgments. Multiple purposes may apply to the same email; an empty label set is also valid.

This release contains a LoRA adapter and a learned Clef joint decision head for Google Gemma 4 E2B, trained through Unsloth. It requires the pinned base model below; it is not a complete merged language model or a general chat assistant. Load it with Unsloth's FastDecisionModel, rather than a generic text-generation pipeline. Standard Hub inference-provider compatibility, GGUF conversion, CPU inference, and other backends have not been qualified.

Version: 1.0. License: Apache 2.0. Training data: Letterweave-0.1.0, a separately MIT-licensed synthetic email corpus. The released model uses raw checkpoint probabilities; no deployment acceptance threshold is calibrated for real mail.

Labeling unit and mixed-purpose messages

Labels are message-level, not thread-level. Each dataset row represents one email message, and the model judges the supplied subject and body. It does not combine the purposes of every message in a conversation or determine the conversation's workflow state.

The seven purpose decisions are independent: multiple labels, or none, can apply to one message. Judge the current sender's adopted purpose. Historical quoted requests do not automatically become current requests; a forward can carry a purpose when the sender adopts or relays it. Greetings, signatures, incidental links and routine footers do not establish an additional purpose by themselves.

Schematic message	Intended purpose labels illustrated
A payment receipt together with a shipping-status update	transactions/records and alerts/updates
A concrete invitation with only a routine newsletter subscription footer	scheduling/invitations; the footer alone does not establish newsletters/publications
An editorial newsletter that also contains a substantive, concrete event invitation	newsletters/publications and scheduling/invitations

These examples explain the labeling policy, not guaranteed model predictions or additional benchmark results. Labels describe observable communicative purposes, rather than every topic mentioned in the message.

The seven purposes

Label	What it describes
correspondence	Substantive interpersonal exchange, beyond greetings, signatures or routine mechanics.
transactions/records	A discrete exchange, account record or commitment; an offer is not a receipt.
alerts/updates	An event-triggered operational change, including completed-payment confirmation.
newsletters/publications	Recurring or curated editorial publication, rather than an account notice alone.
promotions/outreach	Substantive persuasive outreach, pitch or solicitation.
community/discussions	Group discussion or participation; bulk distribution alone is insufficient.
scheduling/invitations	A current concrete invitation, scheduling, rescheduling or cancellation purpose.

For example, a completed-payment confirmation may be both transactions/records and alerts/updates. A group discussion can also contain substantive correspondence. Labels describe the current sender's adopted purpose: obsolete quoted invitations should not automatically become current invitations. Missing context is not evidence that a purpose is absent.

The exact versioned questions are in questions.json, with ID-to-label mapping in label-map.json and the source rubric in taxonomy.json. Use those questions to reproduce the measured contract. Question wording, candidate descriptions and grouping are part of the model's evaluated interface.

Intended use and limits

Use this model for experimentation with email categorization, local purpose tagging, and private shadow evaluation. It judges the supplied subject/body, not a complete mailbox or conversational workflow. It does not determine whether a message requires action, whether someone owes a reply, or whether a thread should be archived. It sends no email and changes no mailbox labels.

Emails are untrusted input, not instructions to execute. Keep side effects, authorization, overrides and fallback behavior in application code. The model can add an incorrect label, miss a purpose or assign unjustified probability. Do not use this pilot as a sole basis for consequential automated decisions.

English synthetic messages are the measured domain. Real inboxes, other languages, attachments, long threads, privacy-sensitive content and adversarial messages have not been independently qualified. Although the adapter accepts custom questions, performance on other questions is not established.

How it was made

The model starts from unsloth/gemma-4-E2B-it-unsloth-bnb-4bit at revision 0ae102ac289cc3f17500a607ad817849778b8ba7, derived from google/gemma-4-E2B-it. A fresh deterministically initialized decision head and rank-16 LoRA were trained on Letterweave's seven binary purpose judgments. No earlier task-specific checkpoint was reused. Base weights are dynamic 4-bit BitsAndBytes quantized; computation uses BF16. The added head and adapter have their own saved tensor precision.

Training used 573 emails, with 143 validation emails and 139 test emails. Existing family-based membership was preserved, with no family crossing splits. The seven labels produce 4,011 training judgments and 973 held-out test judgments. Model state contains only subject/body. Record identifiers, split/family metadata, scenario intent and teacher rationale are not model inputs.

Letterweave is synthetic and machine-labeled, not human gold. Its 855 retained records come from 821 families. Source generation was observed under Luna and Sol model aliases, with Sol review evidence for every retained record; raw provider model-version strings are preserved in the dataset. The source generator and immutable release are at magnus919/letterweave. Teacher agreement, schema verification and family separation do not establish real-inbox correctness or eliminate correlated factual themes.

Training setting	Value
Hardware	One NVIDIA GeForce RTX 5070 Ti, 16 GB, with another GPU service co-resident
Sequence budget	2,048 tokens; largest complete corpus input 1,613 tokens
Optimizer	8-bit AdamW
LoRA rank / alpha / dropout	16 / 16 / 0
Batch size / gradient accumulation	1 / 4
Steps / seed	240 / 3407
Encoder / head learning rate	0.0002 / 0.0001
Warmup / schedule / weight decay	10 steps / cosine / 0.01
Checkpoint selection	Final checkpoint only; no early stopping or test-driven selection
Trainer runtime	455.36 seconds — approximately 7m 35s, excluding setup and evaluation
Peak process GPU allocation / reservation	8.65 / 8.79 GiB, excluding other processes
Residency	All model parameters on CUDA, including 768 MiB input embeddings

All records and all seven questions passed input qualification without skipping or truncation. An initial attempt ended before scoring after a host GPU/driver failure; the completed attempt restarted from the untouched base with the same recipe. It produced the final checkpoint reported here.

A scalar temperature was fitted on validation for separate probability analysis. It was not folded into this released raw checkpoint, and it does not change binary argmax decisions. The default example treats a probability strictly above 0.5 as present, with an exact tie absent. That is an evaluation rule, not a calibrated automatic-label policy for an inbox.

RTX 5070 Ti benchmark and Jev comparison

Both systems evaluated the same 139 test emails / 973 binary judgments, with identical subject/body state, seven Noul instructions, true/false criteria, ordering and a strict > 0.5 presence rule. Jev used pinned jev-1.13.0, with no task-specific examples, prompt tuning or threshold fitting. Native input rendering differs. Jev outputs were used only for evaluation, never as training targets.

These scores measure agreement with synthetic Letterweave labels, not independently adjudicated inbox accuracy.

Measure	Letterweave-1.0-E2B	Jev 1.13
Macro per-label F1	93.42%	91.96%
Micro precision	90.25%	87.35%
Micro recall	97.71%	98.17%
Micro F1	93.83%	92.44%
Exact complete label-set agreement	112/139 — 80.58%	105/139 — 75.54%
Binary teacher agreement	945/973 — 97.12%	938/973 — 96.40%
False additions / missed labels	23 / 5	31 / 4
Observed median latency	117.44 ms	158.08 ms
Observed p95 latency	122.18 ms	190.42 ms

Timing boundaries differ. Local timing covers one warm, pretokenized seven-question call, including collation, device transfer, model forward and result transfer; it excludes tokenization, HTTP/network and service queues. The first email is excluded, leaving 138 observations. Jev timing covers HTTPS through parsed JSON, including TLS/network, for 139 observations. Requests were sequential. These are measured configurations, not a controlled intrinsic model-speed comparison or a production capacity test.

Paired exact-set results: both matched on 92 emails; only Letterweave matched on 20; only Jev matched on 13; neither matched on 14. An exploratory 2,000-draw bootstrap over 133 test families estimated Letterweave-minus-Jev differences:

• Macro F1: +1.46 percentage points, 95% interval −2.46 to +5.68.
• Exact-set agreement: +5.04 percentage points, 95% interval −2.90 to +13.67.

Both intervals include zero. The observed quality difference is inconclusive at this sample size; the results do not establish general superiority over Jev. One seed, selected synthetic scenarios, small label supports, residual theme dependence and unknown pretraining overlap limit interpretation.

A fixed train-only TF-IDF logistic baseline achieved 74.72% macro F1 and 59.71% exact-set agreement. See evaluation/results.json for all per-label results and paired measurements. Letterweave's largest error concentration was alerts/updates: 10 false additions and one missed label; newsletter recall was 9/11.

Load and classify

The tested environment used Python 3.11, Unsloth/Unsloth Zoo 2026.10.3, PyTorch 2.14.0+cu130, Transformers 5.17.0, BitsAndBytes 0.50.2 and PEFT 0.21.2. requirements.txt records the core tested package versions. Install a CUDA-compatible PyTorch build and Unsloth according to their platform instructions; the requirement list is not a universal installer or a CPU-support claim.

Download this repository locally; then use its complete checkpoint and trusted questions:

import json
import unsloth  # import before transformers
import torch
from pathlib import Path
from huggingface_hub import snapshot_download
from unsloth import FastDecisionModel

checkpoint = Path(snapshot_download("Groktopus/Letterweave-1.0-E2B"))
model, tokenizer = FastDecisionModel.from_pretrained(
    str(checkpoint),
    max_seq_length=2048,
    load_in_4bit=True,
    dtype=torch.bfloat16,
    offload_embedding=False,
)
FastDecisionModel.for_inference(model)
questions = json.loads((checkpoint / "questions.json").read_text())
label_map = json.loads((checkpoint / "label-map.json").read_text())
state = {
    "subject": "Payment receipt",
    "body": "Your payment is complete. This receipt confirms the purchase.",
}
# Production callers should enforce the evaluated input budget;
# see inference.py for a complete token-budget check.
answers = FastDecisionModel.predict(model, tokenizer, state, questions)
probabilities = {label: answers[qid]["noul"] for label, qid in label_map.items()}
labels = [label for label, p in probabilities.items() if p > 0.5]
print({"labels": labels, "probabilities": probabilities})

The loader downloads the pinned base weights when they are not already cached. inference.py supplies a subject/body JSON CLI, validates the complete input budget before inference, and returns all seven raw probabilities. The repository's smoke test checks that this exact interface runs; the receipt example is illustrative, not a new quality benchmark. Reworded questions and longer inputs require new evaluation. No automatic mailbox integration is included.

Export verification, licensing and attribution

Reloading the saved checkpoint preserved all 973 binary decisions and the exact-set score. Raw probabilities differed by up to 0.002258 (about 0.23 percentage points); 11 judgments exceeded the strict 0.001 tolerance, so strict probability identity did not pass. Decisions and probability parity are reported separately in training.json.

Google Gemma 4 and this model release are Apache 2.0 licensed. Retain LICENSE, NOTICE and applicable upstream attribution when redistributing. This is an independent Groktopus modification and is not endorsed by Google or Unsloth. Training data has its own MIT license; source provenance and its limitations are documented in the linked dataset card.

Before enabling real-email labeling, evaluate a prediction-blind, independently labeled inbox sample under this seven-purpose rubric, measure false additions and missed labels, and test a private shadow adapter with conservative fallbacks. The public pilot does not establish production calibration, privacy compliance or safe automatic actions.