The Engine Isn't the Car

The Question Worth Answering Honestly

Every so often, someone reads that FarmakoMed positions itself as a European, privacy-first healthcare platform, then notices that the AI running on the device is Google's Gemma, and asks a perfectly fair question:

"If you care about European digital sovereignty, why are you running an American AI model?"

It's a good question. It deserves a real answer rather than a defensive one, because the instinct behind it, don't let critical infrastructure quietly become someone else's, is exactly the right instinct. It's the same instinct that made us build the app local-first in the first place. The disagreement, if there is one, isn't about the goal. It's about where the sovereignty actually lives.

Our answer is that the question, as usually phrased, quietly assumes something that isn't true: that the identity of a piece of software is determined by the origin of its components. It isn't. A product is defined by its architecture, how the pieces are chosen, isolated, integrated, and made replaceable, far more than by the passport of any single piece. Gemma is a component. A good one, chosen on technical merit, and one we've already replaced once and will replace again. The architecture around it is the thing we actually own, and the thing that determines whether FarmakoMed is sovereign in any sense worth the word.

This essay is an attempt to explain that distinction properly, not as a slogan, but as an engineering position with real trade-offs. A note on approach first: everything here about FarmakoMed's architecture is drawn from the project's own architecture decision records, cited where the claim is specific. Where we're offering opinion rather than documenting a decision, we've tried to say so.

Nobody Buys a Bosch Car

Start with the analogy that gives this essay its title, because it's more precise than it first appears.

A modern BMW is not, in any meaningful sense, built entirely by BMW. Bosch supplies sensors, injectors, and control units. ZF supplies transmissions. Continental supplies electronics, braking systems, and tyres. Somewhere between a few hundred and a few thousand suppliers contribute parts to a single vehicle, and a large fraction of the physical content of the car was manufactured by a company whose name never appears on the badge.

And yet nobody walks into a showroom to buy "a Bosch car." Nobody describes their vehicle by its largest component supplier. The reason is not marketing and not habit. It's that everyone intuitively understands where the engineering value of a car actually sits. It sits in the integration: the decision about which transmission to pair with which engine, how the chassis distributes load, how the braking system talks to the traction control, how thousands of independently-sourced parts are made to behave as one coherent, safe, warrantable system. Bosch makes an excellent sensor. It does not make that car. BMW does.

Software is no different, and healthcare software least of all. FarmakoMed chooses components the way a good automaker chooses suppliers: on technical merit, for the specific job, with a clear-eyed understanding that today's best supplier may not be tomorrow's. Then it builds the part it actually owns, the architecture that integrates those components, isolates them from one another, and keeps every one of them replaceable. That architecture is the product. Gemma is a part.

Saying "FarmakoMed uses an American model, therefore it's an American product" makes exactly the same category error as "BMW uses Bosch sensors, therefore it's a Bosch car." The premise is true. The conclusion doesn't follow, because it mistakes a component for the system.

Two Kinds of Decisions

The cleanest way we've found to think about this is to separate two categories of engineering decision that are constantly, and expensively, confused.

Component decisions are choices about which specific thing to use right now: this model, this database, this identity provider, this object store. They are made against today's constraints, today's benchmarks, today's licensing, today's hardware, and they should be expected to change, because those constraints change. A component decision has a shelf life. Treating it as permanent is how you end up with software that can't move.

Architectural decisions are choices about structure: where the boundaries are, what talks to what, what each part is allowed to assume about the others. A good architectural decision is designed to survive component changes. Its whole job is to make sure that when a component decision is revisited, and it will be, the revision is a configuration change rather than a rewrite.

The failure mode in most software is not making a bad component decision. It's letting a component decision quietly harden into an architectural one, until the specific vendor is load-bearing and the code assumes it everywhere. That's how a database library ends up welded into business logic, how an auth SDK ends up in three hundred call sites, how a specific model's quirks end up baked into the shape of every feature that touches it.

Applied to AI, the discipline is simple to state and harder to hold: the application must never be able to tell which model answered. Feature code asks for a medication to be recognised from a photograph, or for text to be extracted from a scanned document. It hands that request to an internal boundary and receives a structured result. It does not know, and must not care, whether the answer came from Gemma, from a successor model, or from a future European model that doesn't exist yet. The moment feature code knows the model's name, the model has stopped being a component and started becoming architecture, and that's the exact mistake the abstraction exists to prevent.

Here is the same idea as a picture. On the left, the model is load-bearing: it's referenced directly throughout the app, so replacing it means touching everything. On the right, the shape FarmakoMed actually uses, every feature depends on a stable internal boundary, and the model plugs into that boundary. Replacing it is a swap, not a surgery.

What Technological Sovereignty Actually Means

The word "sovereignty" invites a geographic reading, a map, a border, a contest between one region and another. We think that reading is a distraction, and occasionally a harmful one, because it turns an engineering property into a flag-waving exercise and lets teams believe they've achieved sovereignty when all they've done is move a server.

Here's the definition we actually work from:

Notice what that definition does not mention: nationality. It says nothing about which country a component came from, and everything about whether you can move when you need to. Sovereignty, defined this way, is a property of the architecture, specifically, of how many of your critical capabilities have exactly one possible provider and no exit. It is measured not by where your dependencies are headquartered but by what happens to you when one of them raises its price, changes its terms, degrades its service, or disappears.

This is not a definition we reverse-engineered to justify a model choice. FarmakoMed's sovereignty record opens by rejecting the shallow version outright: achieving European digital sovereignty, it states, "requires more than storing files in a European region." The same record does something that a purely geographic framing would never permit. It explicitly declines to ban non-European providers, stating that "US hyperscalers are not excluded, but require strong technical and contractual evidence of EU data residency and processing boundaries," while committing to "evaluate European cloud providers first." That is sovereignty defined as leverage and portability, not as a purity test about where a supplier is incorporated.

And crucially, this principle is applied uniformly, not selectively to AI. The same architecture treats every external relationship as provisional:

Read the AI model question through that lens and it stops being special. "Why use an American model?" is the same class of question as "why use S3-compatible storage?" or "why use OIDC?" The answer in every case is identical: because it's a strong component for the job, and because the architecture is built so that the choice is never final.

Where the Computation Happens Beats Who Wrote the Model

There's a second reason the "American model" framing misfires, and for a healthcare app it may be the more important one. It concerns a distinction the framing collapses: the difference between who trained a model and who operates it on your data.

FarmakoMed runs Gemma on the device. The model, the same .litertlm artifact on both Android and iOS, is downloaded once and then executes locally, on the phone's own CPU, GPU, or NPU, through an on-device runtime. When you photograph a medication box, the inference happens in your hand. It does not travel to Google. Google receives no inference request, processes no patient data, sees no photograph, and operates no part of the running system. The model's weights were trained by Google; the computation on your medical information is performed by your phone, under FarmakoMed's control, with no network round trip.

This is worth stating plainly because it inverts the usual intuition about provenance:

Contrast the two shapes honestly. A cloud AI service, regardless of where its provider is headquartered, regardless of how European its data centre, requires that your medical information be transmitted off the device to a remote server to be processed. That transmission is the risk. It creates a copy you don't control, a processing step you can't audit, a log that may or may not exist, and a trust relationship you can't verify from the outside. A cloud model hosted three kilometres away, operated by a company from your own country, still requires you to send it your data. An on-device model trained on another continent never asks you to send anything.

So which is more "sovereign" for the patient, the model with the locally-agreeable passport that you must mail your medical photographs to, or the foreign-trained model that runs entirely inside a device you're holding and never phones home? Posed that way, the geographic framing collapses. The meaningful boundary isn't the model's origin. It's the edge of your device.

This is not an incidental property of FarmakoMed; it's a documented rule. The architecture requires that "no personal health data leaves the device" for AI processing, and classifies AI inference as an optional service that "must never become an architectural dependency" of the core product. That is what lets the model be treated as a swappable part in the first place: because nothing sovereign is being handed to it. It runs on our side of the boundary, on the user's hardware, or it doesn't run at all.

The Abstraction Underneath

None of the above is rhetorical comfort. It's only true if the code is actually built so the model can move, and this is the part that separates an architectural claim from a marketing one, because you can check it.

FarmakoMed keeps a model registry behind its AI runtime: the active model is one profile among a set the system knows how to load, verify, and swap. Above that sits a single owner of AI runtime state, an AI Runtime Manager that every feature talks to instead of talking to a model. Features call into that boundary and await a result; they never reference a model by name, and they never assume the runtime is even available. Availability is resolved per feature, so a device that can't run local AI still runs everything else, and an AI failure degrades to "temporarily unavailable" without touching a single healthcare workflow.

The proof that this is real, and not scaffolding drawn on a diagram, is that we've already used it. The model FarmakoMed ships today is not the model it shipped first. An earlier candidate was retired in favour of the current one after real-device reliability testing, with an automatic migration path for any user already carrying the older profile. Because the registry and the runtime boundary existed, that change was a swap, not a rewrite of every feature that touches AI. A migration that a coupled architecture would have priced as a project, an abstracted one priced as a configuration change.

Honesty requires naming the limits of this, because "swappable" is not the same as "any model drops in for free." The model plugs into a specific on-device runtime and a specific packaged format; a replacement has to be available in a form that runtime can execute, quantized to fit real mobile memory, and licensed for commercial use. Those are genuine constraints, and they mean the set of drop-in replacements at any given moment is smaller than the set of models that exist on paper. What the abstraction guarantees is not that every model is interchangeable tomorrow. It's that when a suitable replacement exists, adopting it is a bounded change at one boundary rather than an unbounded change across the whole app. That's the difference between a dependency you can manage and one that manages you.

Decisions That Reinforce Each Other

The model abstraction isn't a clever trick bolted onto an otherwise conventional app. It's one expression of a set of principles that were chosen together and that hold each other up. Pull any one out and the others get weaker; kept together, they compound.

Local-first by design. The app is fully functional without the cloud; the cloud enhances but never replaces it. That's what makes on-device AI a natural fit rather than a bolt-on, the device is already the centre of gravity, so running inference there is continuous with everything else.

Privacy by architecture. Sensitive medical content is encrypted before it leaves a trusted device, and the backend is built to operate with the minimum knowledge required. Privacy here is a structural property, not a policy promise, an entire class of risk is removed by making the data physically absent from places that can't be trusted to hold it.

Zero-knowledge cloud. When you do opt into cloud backup and sync, the patient is the cryptographic boundary: a key hierarchy rooted in a patient master key means the backend stores encrypted payloads and wrapped keys but never usable plaintext. The server coordinates your data without being able to read it.

Cloud portability and open standards. The infrastructure is deliberately "cloud-portable, not cloud-dependent", managed but standards-based building blocks (PostgreSQL, S3-compatible storage, OCI containers, OpenTelemetry, OIDC) chosen specifically so the operator can move. Provider evaluation even weights "open standards and portability" as a top criterion, second only to sovereignty itself.

Replaceable infrastructure and European hosting. Where the cloud does hold data, it's committed to EU residency and EU processing, but expressed as a portable requirement satisfiable by more than one provider, not as a lock-in to a specific one.

Seen together, these decisions describe a single posture: keep the sovereign things, the patient's data, the integration, the ability to move, on your side of every boundary, and treat everything on the other side of those boundaries as a component you're renting for now. The AI model is simply the most visible tenant of that arrangement, which is why it draws the question. It is not the exception to the architecture. It's a demonstration of it.

Choosing the Next Model

If the model is a component, then choosing it is an ordinary, recurring engineering exercise rather than a one-time act of allegiance, and FarmakoMed intends to keep doing it. New on-device models arrive constantly; the runtime boundary exists precisely so that adopting a better one is a bounded change. So the interesting question isn't "which model forever," it's "what does a good model decision optimise for." Roughly, in no strict order:

European models belong on that list, and should absolutely be evaluated as they mature, Mistral's open models, the OpenEuroLLM effort, and whatever comes after them. If a European, openly-licensed, on-device-capable model meets the healthcare bar as well as or better than the incumbent, adopting it would be an easy decision and a welcome one. But, and this is the whole point of the essay, that would be a component decision, made on merit, executed through the same boundary that every model swap goes through. It would not be the moment FarmakoMed "becomes sovereign," because the sovereignty was never located in the model. It was in the architecture that made the model swappable in the first place.

Conclusion

So: why does FarmakoMed use an American model while championing European digital sovereignty? Because those two things were never in tension. Sovereignty, understood as an engineering property rather than a geography, is about resilience, portability, and keeping the patient's data and the integration on your own side of every boundary. The model is a component chosen on merit and held at arm's length by design, behind a runtime boundary, in a registry, on the user's own device, already replaced once and replaceable again. The nationality of the company that trained those weights is close to the least architecturally significant fact about the system.

Nobody buys a Bosch car. Nobody should call FarmakoMed a Google product. In both cases the reason is the same: the value, and the identity, live in the architecture that integrates the components, not in any component, however visible. The badge on the front is earned by the engineering that makes everything behind it work as one system, and by the discipline that keeps every part of it replaceable.

One Last Thought

Technology changes quickly. Architectures should not. The goal of FarmakoMed was never to build around today's best AI model. It was to build a healthcare platform that can still evolve ten years from now, whichever companies happen to lead in AI, cloud, or hardware by then. Components will come and go; several already have. What has to survive all of them is the structure that lets the product keep moving.

The engine may change. The car should continue the journey.