Overview

An open-weight model is a two-to-four-gigabyte artifact that will answer questions about your most sensitive material, offline, with no one watching. Two things have to be true of it. It has to be good at your job, which general-purpose checkpoints are not, and it has to do only what it appears to do. Wanyeki Technologies LLC offers both halves as services: fine-tuning for mobile, and evaluation for backdoors, whether planted deliberately or absorbed by accident from training data.

Honest scope. No evaluation can prove a model contains no backdoor. What we deliver is evidence: a documented, reproducible search across the classes below, with the coverage and the gaps stated, so your accreditation package rests on what was actually tested.

Fine-tuning for mobile

We adapt Gemma-class models, the same family SecureEdge runs, to a specific user community and vocabulary while keeping them small enough for an iPhone. Typical targets are the workflows the app already ships: SITREP drafting from voice, structured extraction from field reports, entity and grid-reference pulling, unit-specific translation, and dictation cleanup that preserves call signs and acronyms exactly.

Method. Parameter-efficient fine-tuning (LoRA and quantization-aware training) on your data, on infrastructure you control or in an isolated environment we operate for the engagement, with the data never leaving that boundary.
Format. Delivered as a LiteRT-LM bundle with a signed manifest, ready for MDM push or the SecureEdge catalog, and validated on the exact device classes you deploy.
Measurement. Every fine-tune ships with a before-and-after report on your task set, plus the full evaluation suite below, because fine-tuning is itself the most common way an unintended behavior gets in.
Licensing. Derivatives of Gemma carry the Gemma Terms of Use through to you. Where a customer cannot accept those terms we work from Apache 2.0 base models instead.

Model evaluations

We evaluate models before they are trusted with controlled data. That includes models we fine-tuned, models you fine-tuned, and third-party checkpoints you are considering. The evaluation runs against the mobile artifact that will actually be deployed, not only the source weights, because conversion and quantization can change behavior.

Backdoors come in two flavors and we look for both. Intentional ones are planted by an adversary in the training data, the fine-tuning process, or the supply chain. Unintentional ones are learned by accident: a spurious correlation in the data, a memorized document, a context in which the model reliably misbehaves. From the operator's side they look the same, and the same search finds them.

What we test for

Class	What it looks like	How we search
Fixed-trigger backdoors	A specific token, phrase, code word, or formatting pattern in the prompt flips the model into a hidden behavior: a different answer, a leaked instruction, a disabled refusal.	Trigger search over the tokenizer vocabulary and over structured candidates (call signs, dates, grid references, markup), differential testing against a reference checkpoint, and activation comparison on matched prompt pairs.
Behavioral and contextual backdoors	No literal trigger. The model behaves normally until context lines up: a date, a claimed role or unit, a language, a document type, a long-enough conversation.	Scenario sweeps that vary one contextual variable at a time, held-out role-play and doctrine prompts, and drift measurement across conversation length and system-prompt variants.
Image-borne triggers	For vision-capable models, a pixel pattern, patch, watermark, or steganographic payload in an image changes the text the model produces about it, or about anything else in the session.	Patch and perturbation sweeps over clean images, screenshot and document classes matched to your workflows, cross-checks between OCR text and model description, and multi-image sessions.
Data-poisoning artifacts	Unintended behaviors absorbed from training or fine-tuning data: memorized secrets, biased outputs on specific entities, instruction-hierarchy failures where user text overrides the system prompt.	Canary and membership probes, entity-conditioned output comparison, prompt-injection suites across the exact workflows you deploy, and refusal-consistency checks.
Supply-chain integrity	The weights you run are not the weights that were evaluated, or the conversion to the mobile format changed behavior.	Hash and signature of every artifact, evaluation of the converted .litertlm bundle itself rather than only the source checkpoint, and reproducible harness runs you can re-execute.

Each class is run against a matched control model where one exists, so a finding is a measured difference rather than an impression. Findings are graded by trigger specificity, effect size, and how plausibly the trigger appears in your operating environment.

Evaluations you specify

Most engagements add evaluations particular to the buyer. Examples we have built or scoped:

Refusal and safety behavior on your own red-team prompt set, including in languages your users speak.
Accuracy and hallucination rate on your document corpus, with citations checked against source.
Consistency under the exact system prompts and workflows deployed in the app.
Behavior under prompt injection carried inside imported documents and images.
Performance envelope on target devices: tokens per second, time to first token, memory headroom, thermal behavior.
Regression suites that run on every new model version so a catalog update cannot silently change behavior.

Deliverables

Evaluation report. Method, coverage, findings with reproduction steps, and the explicit list of what was not tested. Written to drop into an SSP or accreditation package.
Reproducible harness. The prompts, images, scripts, and reference outputs, so your own team can re-run the evaluation on the next version without us.
Signed bundle. The evaluated artifact with its manifest signed by a key you hold, its hash recorded in the report, ready for MDM delivery.
Model register entry. Provenance, license, version, hash, and approval date in the format SecureEdge's per-model license register expects.

How to engage

Engagements are scoped per model and per workflow set, usually two to six weeks. Data and weights stay inside a boundary you approve; for many customers that is their own environment with our tooling brought in. Write to babs@wanyekitech.com with the model, the workflows, and the device classes involved, and we will come back with a scope. For how models are provisioned and verified inside the app, see the security overview.