An AI harness is the software and configuration that organise how a model is used. It can determine what information reaches the model, what task it is asked to perform, which tools it can use and what happens to its output. In healthcare, those decisions can matter as much as the model's general capabilities.
The term appears in the evaluation accompanying Tandem Sovereign Health. Its use should prompt a practical question: is the evidence about the underlying model in isolation, or about a particular model working within a configured product?
The architecture below is an explanation of possible system components. It is not a disclosure of Tandem's proprietary implementation or a claim that every clinical AI product contains all of them.
A model is not the whole application
A model supplies a capability for interpreting and generating information. A clinical application additionally needs to decide which user is asking, which encounter is relevant and what the requested output is allowed to contain.
It may need to retrieve an approved protocol, apply a template, preserve speaker attribution or prevent an unapproved document from being sent. Those requirements cannot be inferred from the model's name.
A useful analogy is a clinical instrument within a procedure. Knowing the instrument matters, but it does not describe the complete process, the operator or the conditions under which the result is interpreted. The analogy is about system boundaries, not a claim that a language model behaves like a validated physical measurement device.
Six components that can change the experience
| Possible component | What it contributes | What still needs testing |
|---|---|---|
| Task instructions | Defines the requested job and limits | Whether the model follows them in difficult cases |
| Context preparation | Selects and organises relevant information | Whether selection loses chronology or uncertainty |
| Retrieval | Supplies external sources or local documents | Relevance, currency and support for the final claim |
| Output structure | Organises text or machine-readable fields | Whether valid formatting conceals incorrect meaning |
| Checks | Tests selected constraints or inconsistencies | Coverage, false reassurance and shared errors |
| Tool and permission controls | Restricts what can happen outside the answer | Correct authorisation, destination and completion |
A product may use ordinary software for some components and models for others. Adding more stages is not automatically an improvement. Every additional transformation creates something to maintain and another boundary to test.
The same model, two different tasks
Consider this original fictional transcript extract: "The patient wonders whether the earlier episode was an allergy. The clinician says this is not established and agrees to obtain the previous discharge letter."
A weak task specification asks the model to "write a complete clinical note" without explaining how to handle uncertainty. A more explicit specification requires attribution, distinguishes suspected from confirmed conditions and prohibits filling missing fields with assumed negative findings.
An appropriate draft would retain the uncertainty and the agreed information-gathering step. A draft stating "confirmed allergy; previous records reviewed" would introduce two unsupported changes.
These are hypothetical outputs used to explain the design problem, not measured performance from running a model. Better instructions may help, but their apparent clarity does not prove that the model will follow them consistently. The complete configuration must be tested against examples that could reveal the failure.
Context preparation can solve a problem or create one
The model cannot use information that has been discarded before the request reaches it. A context pipeline that compresses several encounters into one paragraph might remove the date distinguishing a historical treatment from a current plan.
Conversely, sending the entire record is not necessarily the answer. It can introduce irrelevant material, increase processing and make contradictions harder to inspect. The aim is sufficient, relevant context with visible limits.
A proposed context specification should distinguish the original source, its date, its author or speaker and its status. The HL7 FHIR Provenance resource provides a technical way to represent aspects of information lineage. Such a record helps establish origins; it does not prove that the clinical statement was correct.
For a buyer, the important demonstration is whether the system can show why a consequential fact appeared, rather than merely display a long context window as a feature.
Retrieval adds evidence, not automatic truth
Retrieval can place relevant material beside the question. The next stage still needs to use it appropriately.
Suppose a synthetic teaching request includes an approved local protocol and an older superseded version. A useful system should not simply choose the paragraph with the strongest wording. It needs to recognise which document applies and make that choice inspectable.
iatroX's published methodology describes retrieval, ranking, source linking and checks around clinical-reference answers. That is an example of explaining processes beyond a model name, not proof that a referenced answer is always correct.
The reader's test remains specific: does the cited passage support this claim in this setting? A harness can make that test easier to perform, but cannot replace it with a badge saying the answer was grounded.
Structured output and clinical meaning are different
A system may require fields such as presenting problem, assessment and plan. Conventional software can verify that those fields exist and that a date has a valid format.
It cannot conclude from that alone that the assessment occurred on that date or that the patient agreed the plan. A technically valid object can contain an invented clinical event.
This is why numerical and structural checks should be described narrowly. Checking a calculation is valuable when its inputs and formula are established. It does not validate the selection of those inputs or the clinical suitability of the calculation.
The strongest design uses different checks for different questions rather than treating one successful formatting test as evidence about medical correctness.
Permissions belong outside a persuasive conversation
A model may recommend sending a letter, but permission to send it should be enforced by the surrounding system. External text should not be able to expand that authority simply by containing an instruction.
The NCSC's discussion of prompt injection explains why untrusted material can influence language-model behaviour and why the consequences need to be constrained. A stronger prompt is not a guarantee that the problem has disappeared.
In a proposed clinical workflow, the harness might allow draft preparation while requiring an authenticated person to approve the exact content and destination. The receiving system would then provide confirmation of what happened.
That is a design example. It should not be attributed to a particular vendor without documentation showing that the control exists and works in the deployed configuration.
Open weights change the maintenance question
Operating an open-weight model can give a supplier more control over versions, adaptation and hosting. It also creates responsibility for serving reliability, security and the model's behaviour after changes.
Heidi's 30 September 2026 technical account describes adapting an open-weight base for its Evidence product. That is distinct from training a foundation model from the beginning.
For an organisation evaluating a product, neither "our own model" nor "frontier API" settles the question. Ask which configured system was tested and how the supplier maintains the result when prompts, retrieval sources or model versions change.
The evidence should identify the complete configuration
A reproducible evaluation record should identify the model version, relevant instructions, retrieval configuration, templates, generation settings and checks. Proprietary detail may require controlled disclosure, but the evidence should still make clear what was evaluated.
The same model used with another harness may behave differently. The same harness attached to a replacement model may also need fresh testing. Better performance on a general benchmark does not demonstrate that a local template or approval workflow remains reliable.
The useful procurement question is therefore: "What evidence supports the configuration we will use, and which changes would invalidate that evidence?" That moves the discussion beyond an impressive model name to the product on which clinical work depends.
Frequently asked questions
Is an AI harness another name for a system prompt?
A prompt can be one component. The broader term can also include context preparation, retrieval, tool use, checking, output handling and evaluation infrastructure.
Does adding a checking model guarantee safer outputs?
No. A checker can share the original system's incorrect assumptions or lack the evidence needed to detect them. Its contribution needs its own evaluation.
Do open weights make the entire clinical product reproducible?
Not automatically. Application logic, sources, configuration, licences and infrastructure may remain separate. Reproducing the model is not the same as reproducing the workflow.