Small language models and routers
Classifiers, routers and extractors for a defined operational task. We evaluate compact models against the existing baseline, including response time, resource requirements and task quality.
Inside the lab Model engineering
Build the model the work calls for.
We train, refine and deploy models around the task they need to perform. That includes small language models, specialist routers and fine-tunes, with continued pretraining or from-scratch programs when the problem warrants the investment.
The work starts with the operating question: what must improve, inside which boundary, and what evidence will justify a change?
Discuss a model program
Model comparisonConceptual illustration
- 01Baseline
Establish the existing model’s performance on the task.
- 02Targeted change
Adapt the model against a defined training objective.
- 03Controlled evaluation
Compare both versions on the same held-out cases.
- 04Release decision
Record results, tradeoffs and the reviewer’s disposition.
Where we work
A deliberate choice of model, size and method.
We compare an existing model, retrieval, adaptation and training against the same operating requirement. Quality, response time, cost and data handling belong in that decision together.
Task-specific fine-tuning
Adapt an open-weight base to a focused workflow, using low-rank adaptation or broader fine-tuning as appropriate. The comparison determines whether the specialization earns its operating cost.
Dense and expert-routed architectures
Evaluate dense models and mixture-of-experts architectures against workload, hardware and serving constraints. Routing behavior and system complexity are part of the evaluation.
Pretraining programs
Continued pretraining and from-scratch model development begin with an explicit corpus, compute budget and evaluation plan. We scope these programs when adapting an existing base cannot meet the requirement.
The working method
Training sits inside a larger engineering discipline.
A candidate moves forward when the evidence supports the intended use. Each stage leaves a record that the next engineer, reviewer or operator can inspect.
- 01
Corpus
Record provenance, permitted use, exclusions and the data boundary before training. Public and synthetic corpora support lab experiments; client data requires an explicitly approved program and handling controls.
- 02
Evaluation design
Define the baseline, acceptance criteria and held-out cases before tuning. Separate development feedback from the final evaluation, and record task quality, failure behavior, latency and cost.
- 03
Training
Select the smallest intervention justified by the task. Low-rank adaptation, quantized fine-tuning, full fine-tuning and pretraining each carry different data, compute and operational requirements.
- 04
Evaluation
Run the baseline and candidate against the same held-out tasks under recorded conditions. Inspect results by category, including regressions and tradeoffs, before choosing what to keep.
- 05
Promotion
Separate training responsibility from release review. Record the reviewers, acceptance evidence, exceptions and decision so the basis for promotion stays available to the operating team.
- 06
Release
Bind the model or adapter, base version, configuration and evidence in a release manifest. A signature supports integrity and provenance checks; the evaluation packet supports review of the measured result.
The release evidence
Every artifact answers a different question.
Scientific review, operational approval and artifact integrity work together. Keeping their evidence distinct makes a release easier to evaluate, reproduce and operate.
- 01Model card
What the model is for
The intended task, base model, owner, operating conditions and known failure modes define where a candidate belongs.
- 02Dataset card
Where the data came from
Source provenance, permitted uses, selection criteria and exclusions make the training and evaluation populations reviewable.
- 03Evaluation report
How performance was measured
Held-out cases, baseline, rubric, harness version and run conditions explain the result and support reproduction where the evaluation data can be shared.
- 04Review record
Who made the release decision
Named training and review roles, acceptance criteria, exceptions and the promotion decision establish responsibility for the release.
- 05Release manifest
Which artifacts belong together
Digests identify the weights or adapter, base version, configuration and associated evidence so the deployed artifact can be matched to the reviewed one.
- 06Signature
Who signed the recorded artifacts
A signature authenticates the manifest and detects changes to its contents. The evaluation and review records carry the evidence for performance and approval.
Explore artifact integrity with our interactive signed-record verifier.
Inspect a synthetic receiptExternal reference points
Read the measurements at their source.
Public evaluations inform candidate selection. We follow their methods and results, then test the shortlist on the work the model will actually do.
Work with the lab
Bring the workflow. We will frame the model program.
Start with the task, the deployment boundary and the standard a release must meet. We will define the comparison, training approach and evidence your team needs to make the decision.