OpenEvidence presents Osler, Sackett and Snow as production offerings, with Darwin in a research preview. The Anthropic partnership adds a disclosed technology relationship, but does not identify the architecture behind every named product. As reviewed on 23 September 2026, a complete product-by-product account cannot be established from the sources examined here.
The distinction is between a product name, an underlying language model and the wider application that retrieves information and delivers an answer. OpenEvidence's 3 September 2026 model-family announcement establishes its public product names. It should not be read as a full technical specification.
This article updates the technical discussion first published on 7 September 2026. It retains the original distinctions between generation, retrieval, research coordination and application access, while adding what the later partnership can and cannot establish.
The name in the menu is only one part of the answer
A product label helps a user choose a service. It does not, by itself, state the model's parameter count, training procedure, provider or deployment configuration. Even an explicitly named language model may be surrounded by an application that controls source selection, tools, permissions and checks.
There are therefore several legitimate versions of the question "What model does OpenEvidence use?" A clinician may be asking which answering mode to select. A researcher may need the exact configuration tested in a paper. A developer may be asking which interface can be called programmatically and which changes will be visible.
Those questions should not be answered with the same sentence. A user-facing name can remain stable while some underlying component changes. Conversely, a common underlying model can support quite different workflows when the evidence, instructions and tools differ. These are general architectural possibilities, not disclosures about OpenEvidence's proprietary implementation.
Readers choosing between answering modes can use iatroX's dedicated Osler, Sackett and Snow chooser. The purpose here is to identify the evidence needed for technical claims, rather than repeat that product-selection discussion.
A conceptual breakdown of a clinical AI application
The following framework is general. It is not a reconstruction of OpenEvidence's infrastructure.
| Layer | What it contributes | What a technical disclosure would need to identify |
|---|---|---|
| Language generation | Produces text from the information available to the model | The relevant generating model, version and adaptation, where disclosed |
| Evidence retrieval | Locates external information for the question | Searchable collections, retrieval configuration and handling of unavailable material |
| Source selection and ranking | Determines which retrieved information receives priority | Relevance criteria, jurisdiction handling and treatment of conflicting sources |
| Research coordination | Organises searches, follow-up tasks and synthesis | The sequence of operations and the tools available for the task |
| Application and permissions | Controls the interface, user access and output delivery | Supported account types, functions, interfaces and permitted uses |
A new content agreement belongs primarily to the evidence-access question. A new research mode concerns the way work is organised. Neither automatically supplies the generating model's identity.
Similarly, a system that coordinates several searches does not necessarily use a different trained model for each search. The number of visible stages, product names or agents cannot be converted into a count of independent underlying language models without supporting documentation.
What the public descriptions establish
The following matrix reflects the public material reviewed on 23 September 2026. "Not established here" means that those sources do not settle the point; it is not a claim that the information is unavailable in every private contract or technical discussion.
| Technical question | What the reviewed material establishes | What remains unresolved in this review |
|---|---|---|
| Which production names are used? | Osler, Sackett and Snow are the public production names in the September 2026 release | The exact generating architecture behind each name |
| Is Darwin in the same access category? | The release describes a research preview | The terms and configuration of a particular research arrangement |
| Are research evaluation details discussed? | The original 7 September review identified technical evaluation information in indexed launch material | Full reproduction of that evaluation from the accessible material |
| Is programmatic research access mentioned? | The original review identified discussion of an endpoint available to research partners | A general self-service developer offering and its contractual conditions |
| Are exact base models and parameter counts established? | They are not established by the release and passages examined for this article | Component identities, sizes and any sharing across products |
| Is there a documented one-to-one mapping between names and underlying models? | The sources establish distinct offerings | Whether each product corresponds to a wholly separate language model |
| Is retrieval identical across modes? | The public offerings describe different intended behaviours | A complete mode-by-mode specification of retrieval, ranking and source handling |
The distinction between an unknown and a negative finding is essential. "The reviewed release does not identify this component" is a defensible statement. "The company never identifies its components" would require a much wider investigation.
What does the Anthropic partnership establish about OpenEvidence's technology?
Reuters reported on 22 September 2026 that Anthropic supplies back-end technology for the regional initiative. That establishes a relationship and a stated role, not a complete architecture.
The useful question is the scope of the disclosure. Does a statement name a provider, an exact model, a particular product, a geographical service or every request passing through the platform? These are different levels of specificity.
| Disclosure question | Position as reviewed on 23 September 2026 |
|---|---|
| Is there a publicly reported technology relationship? | Yes, the partnership reporting establishes one |
| Does that alone identify a particular Claude version? | No exact version is established by the material reviewed here |
| Does it identify the components behind Osler, Sackett and Snow separately? | No product-by-product mapping is established here |
| Does it specify what runs behind Darwin research access? | Not in the partnership account examined here |
| Does it disclose routing, fallbacks, prompts or retrieval configuration? | Those details are not established by this account |
A disclosure can be meaningful without being exhaustive. The error would be to use a meaningful but limited statement as the missing evidence for several much broader conclusions.
The main partnership explainer covers the announcement and access questions. The companion article on specialist medical platforms considers the strategic interpretation. Neither should replace a product-specific technical statement.
Does this identify the technology behind every OpenEvidence model?
No. A named relationship does not create a one-to-one map between a provider and every application mode, research preview or historical version.
Several arrangements would be logically compatible with a limited partnership statement. A provider could support one service, several operations within a service, or a wider application configuration. Other components could perform retrieval, filtering or coordination. These are possibilities that illustrate why inference is unsafe; none is presented as OpenEvidence's actual design.
The same restraint applies over time. A statement made for a new deployment should not be projected backwards onto an earlier benchmark unless the evaluated configuration is explicitly connected to it. Nor should it be projected forwards onto every later update.
This matters for fair evaluation. A benchmark result is about the system tested under the described conditions. It is not evidence that every product carrying the same corporate brand has the same strengths, weaknesses or technical dependencies.
Read evaluation details as evaluation details
The original 7 September 2026 article noted that publicly indexed technical launch material referred to a research-partner endpoint and named baseline configurations used in comparisons. Those details concern evaluation. They should not be silently promoted into a production architecture disclosure.
A comparator is the system against which another system is assessed. Its presence in a table does not establish that it powers the product being tested. Likewise, a research endpoint does not automatically describe an ordinary user's web session, an enterprise integration or a mobile application.
A careful technical reading asks which product version was tested, how the inputs were prepared, what tools were enabled, what the evaluation measured and how refusals or failures were handled. It also asks whether changes in sources or retrieval could affect the result without changing the visible product name.
Benchmark accuracy, clinician preference, citation support and diagnostic performance are different outcomes. A score should retain its original outcome label, population and test conditions. It should not be translated into a general claim of clinical validation.
Retrieving a paper does not mean training on it
Training changes model parameters. Retrieval makes external information available for a particular task. The two can coexist, but observing retrieval does not establish that the retrieved document was used during training.
Lewis and colleagues' 2020 retrieval-augmented generation paper describes combining a parametric model with retrieved external information. That provides the relevant conceptual distinction, not a specification of OpenEvidence's system.
Consider a fictional example involving a newly published guideline. An application could retrieve the document and provide relevant passages to the model while it constructs an answer. The application could therefore use recent information without updating the model's parameters on that document. Whether it actually does so requires product-specific evidence.
A content licence is a separate question again. An agreement may permit access, display, retrieval or other specified uses. Its existence does not disclose every permitted use, prove that material was used for training or establish how the product handles source updates.
What developers should ask before building around a model name
Imagine a hospital team exploring an evidence-briefing service for internal review. The useful procurement question is not whether an observer can guess a hidden model from its writing style. It is whether the team can understand and manage the dependencies of the proposed service.
The team should establish whether an integration exposes a stable identifier, documents material changes and specifies supported inputs and failure responses. It should ask which prompts, sources and outputs can be retained for an authorised audit, and what contractual permissions cover the intended workflow.
A commercial interface, a research endpoint and an integration offered by an unrelated third party are distinct forms of access. Ordinary account ownership does not answer the rights question. Nor does a successful experimental call establish supported production use.
The evaluation should preserve the evidence context as well as the visible answer. When an answer changes, an investigator may need to distinguish a source revision, retrieval change, altered instruction or generating-model update. This is a proposed evaluation practice, not a claim about OpenEvidence's current logging functions.
What information would make the answer clearer?
The most useful addition would be product-specific documentation that states exactly what it covers. A technical statement could identify the service, release period, relevant model or provider where disclosed, available tools and important limits on what the statement describes.
For reproducibility, the minimum useful disclosure is often different from a complete release of proprietary infrastructure. A stable version identifier, documented evaluation configuration and clear explanation of material changes could help readers interpret results without exposing every implementation detail.
For institutions, source permissions, operational continuity and change management may matter as much as model identity. Knowing a provider's name does not establish that a particular content collection is licensed for the proposed use or that an integration has the necessary support arrangements.
For clinicians, a clear explanation of source selection and uncertainty can be immediately valuable. It should still be understood as a design description whose performance needs checking, not as a substitute for evidence about the outputs.
Apply the same questions to iatroX
This article is published by iatroX and includes iatroX's own methodology in the comparison. The same standard of precision applies to its technical claims.
As checked on 23 September 2026, iatroX's methodology describes retrieval, ranking, citation grounding, output checking and uncertainty handling. It also explicitly says that the page does not publish vendor names, model names, infrastructure or database-level implementation details.
That description explains intended processes. It does not justify inventing an account of iatroX's providers, assuming every response is correct or treating a method as a completed comparative evaluation. A useful workflow still has to demonstrate usefulness in the circumstances in which it is used.
The useful answer depends on who is asking
For a clinician, inspectable sources, relevance and reasonable checking effort may matter more than a hidden model's name. For a researcher, the priority is a sufficiently precise description of the tested configuration. For a developer, supported interfaces, permissions and change management become central.
The scenario-based conclusion is therefore different for each reader. Choose an answering mode by the clinical task; interpret a study by its documented configuration; and build an integration only around verified access and operational commitments. A named model family and a partnership announcement are useful starting points, but neither completes all three enquiries.
Frequently asked questions
Does OpenEvidence use its own AI models?
OpenEvidence presents Osler, Sackett, Snow and Darwin as its model family in its September 2026 materials. That branding does not establish that every component was trained from scratch by OpenEvidence or identify the exact underlying architecture.
Are Osler, Sackett and Snow separate underlying LLMs?
The reviewed September 2026 material establishes distinct offerings, not a documented one-to-one mapping to separate underlying language models. The Anthropic partnership does not resolve that architectural question without a product-specific technical disclosure.
Does an OpenEvidence account include developer API access?
Ordinary application access should not be assumed to include programmatic rights or credentials. The research-partner endpoint discussed in the original September review is a different category from a generally available developer subscription.