On August 24, 2026, we launched Thomson, our first proprietary large language model. Our CEO Steve Hasker explained to Artificial Lawyer what it means for legal professionals. This piece is for a different reader — the technology and infrastructure teams inside large organizations who want to know what’s under the hood, and what a model like this implies for how you think about AI in your own environment.
What Thomson actually is
Thomson isn’t trained from scratch, and it isn’t a thin fine-tune either. We start from a strong open-weight foundation model and apply continual learning; a structured program of mid-training and post-training that adds new capability while actively working to prevent the model from losing what it already knew. Our published technical report — the full methodology is available for download — documents this as a three-module pipeline covering knowledge integration, instruction tuning, and domain specialization, each producing a fully evaluated checkpoint before moving to the next.
The scale is deliberately modest. Development ran on a team of fewer than three dozen engineers and scientists, working on a compute cluster with no more than 368 B200 GPUs available at any point. After extensive experimentation with the base model, the final training run for Thomson-1.0-Large took three weeks of training time and cost under $450,000 in GPU time. Total development cost, including staff, infrastructure, and domain expert time, came in at approximately $40 million. That’s a fraction of the budget typically associated with frontier model development, and it’s the central point of the exercise. We set out to show that competitive performance doesn’t require frontier-scale compute if you have the proprietary data and domain expertise to make continual learning count.
Why continual learning, and not the alternatives
Two more familiar approaches exist, each with their limitations. Prompt engineering and retrieval-augmented generation leave the base model frozen and add context at inference time, which is cheap but bounded by whatever the underlying model already knows and how it reasons. Full pretraining from scratch removes that ceiling but at a cost most organizations can’t justify. Continual learning sits between them, and it comes with its own well-documented failure mode — fine-tuning on domain-specific data can cause catastrophic forgetting, where a model gains ground on the new domain by losing general capability, including instruction-following, which tends to erode first and matters most for downstream reliability.
We treated capability retention as a first-class training objective rather than an acceptable trade-off, combining rehearsal-based continual learning with data-centric curation; rephrasing, filtering, deduplicating, and mixture-calibrating training data through Bayesian optimization against our evaluation suite rather than simply adding more of it. The result, which we call a π-shaped improvement pattern, is a model that gains meaningfully in targeted domains while holding its general-purpose performance close to flat, rather than trading one for the other.
Where the benchmarks land, and where they don’t
We publish benchmark results so that others can compare Thomson with other models, not because they’re uniformly favorable, and we think that distinction matters more than any single score. At the time of release, Thomson performed competitively with the strongest frontier models on the market, including Claude Opus 4.8, and ahead of GPT-5.5, Claude Sonnet 5, and Gemini 3.1 Pro on a range of legal-domain and general-domain benchmarks. It posted the top score of any model tested on PrBench Legal Hard, and it led on instruction-following and long-context evaluations.
Thomson doesn’t lead everywhere. Coding and general reasoning benchmarks currently favor the larger frontier models, and we say so in the technical report. What we think is more informative than any individual benchmark result is the factuality gap — when Thomson works over our proprietary content through our own tools, its citations hold up under verification at a meaningfully higher rate (0.83) than leading frontier models given open web access (0.65–0.68), on a task where completeness alone was close to level across all three. Frontier models given access to the same Thomson Reuters tools reach a similar level (0.81–0.82), and Thomson gains far more from those tools than any other model does; with web search alone, it trails the pack. The lesson is that trusted content, purpose-built tools, and a model trained to use them together close the gap between a model that sounds right and one that can be checked. That is the foundation of what we call Fiduciary-Grade AI™.
Our training data is a curated selection. Using our own evaluations as the selection signal, we worked with a data-curation partner to identify roughly the most relevant 10% of the proprietary content we exported for training, and we started there.
The infrastructure underneath
The part of this that’s most relevant to your role is probably not the model weights. It’s the serving infrastructure, and we designed it around the same sovereignty principles that shaped the model itself: control over training and model choices, control over the data and tools involved, and control over where and how inference actually runs.
Our inference platform runs on Kubernetes, with a routing, authorization, and rate-limiting layer implemented in Rust, and vLLM as the inference backend. It operates across 11 independent clusters spread over 4 geographies and 2 cloud providers, with routing and inference kept in separate cluster types so that a failure in one has a contained blast radius rather than a cascading one. Since April 2026, this system has processed more than 1.7 trillion tokens across approximately 220 million requests at a 99.9% success rate, with self-hosting saving close to 20% versus third-party inference for comparable workloads.
The design choice most worth calling out for a data governance conversation is mesh routing enforcement. Requests that are latency-tolerant can be routed to available capacity in another region. Requests that carry data residency requirements cannot: the routing mesh doesn’t connect back to disallowed geographies at all, which means a misconfiguration can’t silently violate a residency boundary, because the network path to do so simply doesn’t exist. For organizations working across GDPR, sector-specific data residency rules, or internal data handling policies that vary by jurisdiction, that’s an architectural guarantee, not a policy one.
Our technical report goes further into methodology than we can here — the training pipeline, the evaluation protocol, and the infrastructure decisions behind all of it. We built Thomson to show what’s achievable with proprietary data and a modest, well-run compute budget. We’re publishing the details because we think the argument is more convincing as a blueprint than as a claim.
What sovereignty looks like beyond our own deployment
We built our own training and inference stack because we didn’t want dependency on a single vendor’s roadmap or pricing to be the constraint on what we could build next. We think a version of that argument applies to any organization sitting on a meaningful proprietary data asset — regulated data your teams can’t move off-premises, institutional knowledge you don’t want absorbed into a shared model’s training set, or simply the operational need to know exactly where inference happens and under whose control.
We don’t currently offer Thomson as a standalone, generally available model outside our own products. We are in early conversations with a number of organizations about what a dedicated, self-hosted instance would look like: a version of Thomson deployed inside an environment you control, continuously updated from our side in one direction only, with your own proprietary data and document repositories added on top without that data ever leaving your infrastructure or feeding back into our training set. If that’s a conversation worth having for your organization, we’d like to hear from you.
.png){kind=logo}
