Our principles

Everything that matters has to be something the customer can look at for themselves: how the system is configured, who opened which record, which AI handled which recording, when anyone reached raw material, what the patient agreed to. Trust is not something we ask for; it is something the records either support or do not.

In practice: the configuration is a repository the customer can read. Access to records is written down in a standard, queryable form. AI processing is logged with what it did and how it turned out. Reaching raw material is a deliberate act that leaves a trace. Consent is recorded and can be reviewed. When a compliance officer says "show me", there is something to show — and they never had to take our word for it.

The platform is built under a licence that lets a customer run it themselves, on their own machines, from documented instructions. That is deliberate. It removes being locked in as a risk the customer has to plan around, and it forces us to earn our money on how well we run the thing rather than on holding the code.

Where this stands today. The repositories are still private. Publishing them is intended but not scheduled, and nothing here should be read as saying the code is already available — see 7. Honest limits. It is nonetheless built as if it were public: freely licensable, with nothing in it that only works for us, and no customer data anywhere in the code. That constraint holds today, which is what makes publishing a decision rather than a project.

The line: the system is public, running the system is the business

The system is what the platform is and how it is built. Running the system is what the vendor sells. When a new case is ambiguous, that question settles it — not an inventory of artifacts, which is always one unforeseen case behind.

The system — intended to be open: the platform code, the module repos (lab, jengu-visits), the EE zone, the build workflows that produce the published container images, the edge image and its build, and fleet management — enrolling, monitoring and upgrading appliances. Appliance images ship inside the cloud release rather than as separate downloads, so a customer running their own cloud operates their own fleet from it, with no vendor-only tooling in the loop. Also the method: this arc42 documentation, the development conventions, the skills generated from them, and the status site. How the thing is built is not a trade secret; it is the clearest evidence that it is built well.

Running the system — the vendor's operational competence, and not open: release orchestration and deploy pipelines beyond build — which version goes out when, through which checks, across which customers — the monitoring behind it, the certified profiles for countries beyond the first, support, and the service and regulatory commitments we sign up to.

The distinction is between the capability and the service. A self-hoster gets fleet management because it ships in the release they run. What they do not get is the vendor deciding, watching and answering for a rollout across an estate — that is the managed service, and it is judgement and accountability rather than software.

The customer's own — a third category that is neither: an organisation's configuration lives in a repository that organisation owns. It is not ours to publish or to withhold.

The vendor's value is in running the platform well — meeting the SLA the customer wants, certifying under the regulator they answer to, integrating with the partners they need, supporting clinicians when something goes wrong, and delivering improvements at a pace a single self-hosted organisation cannot match. A customer who chooses to self-host receives the same code, but takes on the operational, maintenance, certification, and improvement cost the vendor would otherwise carry. Both positions are valid; the vendor does not subsidise self-hosting and does not penalise it.

Ownership is not a feature we added; it is how the thing is built. Each customer's clinical records live in a data store of their own, with nothing of theirs tangled into anyone else's. Taking the data out means taking that whole store — the customer leaves with their records in the shape they were kept in, not extracted from a shared table. The configuration repository can live under the customer's organisation, with the platform connecting through a token the customer issues and can revoke. The customer decides whether to enable the anonymised-data-use programme; declining is a valid permanent state. The customer owns the on-site hardware — the edge, a small appliance Jengu installs at your site that keeps clinical work running when the network is down. The platform manages its lifecycle but does not hold the devices hostage.

At every layer, the customer can leave with what is theirs and revoke what they have granted. The platform's strategic interest is to make this leaving so straightforward that no customer ever feels they have to plan for it.

Most software of this kind puts the cloud first and treats the local copy as a fallback; this is the other way round. The appliance on site is enough to work through a crisis, the cloud is better for an ordinary day, and losing the connection costs convenience without costing the clinical work clinicians depend on. The customer owns business-continuity planning; the platform aims to remain one of the systems still working when others have failed, not to claim to be the system that promises everything. "We help you keep going" is the honest framing — not "we keep you going".

Concretely the edge runs on commodity, low-power hardware; spares are kept on the shelf; meshing and patient-carried tokens extend reach when networks fail; data minimisation keeps the offline footprint bounded; reconciliation drains accumulated data when connectivity returns. The platform accepts hardware operations and offline-mode complexity in exchange for being a tool clinicians can count on through a difficult day.

The platform prefers structural guarantees: things that cannot happen because the design does not allow them, not things that should not happen because there is a rule. When a regulator asks "could one customer see another's data?", the answer is "the architecture does not allow it" — not "we have policies against it". The strength of the answer comes from the structure, not from the operator's word.

In practice: the parts of a record that identify a person — names, identifiers, free-text notes, recording transcripts — are encrypted in a way we cannot undo. Clinical text reaches any AI only across a sealed boundary, with identifying detail removed on the way, so nothing downstream can receive raw text by accident. Customers are kept apart by having separate stores, not by rules that filter a shared one. Nothing is held in memory between requests, so nothing can leak from one customer to the next. And we, operating the platform, cannot reach inside a customer's clinical records at all. Each of those is something the design prevents, not something a policy forbids.

Checked on every change. What was once an intention is now verified automatically whenever the code changes. Identifying fields are encrypted before they are ever stored, with keys belonging to one customer alone, and we have no way to read those keys. When a customer is deleted the keys are destroyed — and without the key the encrypted data cannot be read by anyone, ever, including us. Which fields the platform treats as sensitive is published on the sensitive-fields catalogue, and the test that fails the build if any sensitive field stops being encrypted runs on every push.

Limits we still live with. Three pieces are not yet at that standard, and we would rather name them than let you find them. Searching for a patient by name uses a one-way scramble rather than full encryption, so a clinician can still find someone without us decrypting any names. Deleting raw audio is built but the cloud side of it waits on a feature from the recording software we use. And the on-site appliance clears old files by age rather than by confirming the copy arrived — so under unusual network conditions a file could go before its copy is safely away.

Which claims are proven, and by what, is on the features page, where each one links to the test that holds it up.

Capturing audio, carrying a live conversation, storing records in FHIR, running long processes that survive a restart, turning speech into text, large language models, small commodity computers: all of these already exist, are mature, and are used in anger by other people. Building our own versions of them would add ways to be attacked, work to maintain forever, and more to certify — without a single clinical benefit.

So the platform uses established components for each of those, chosen because each is already trusted somewhere regulated. Our work is to compose them under the clinical and European rules their authors never had to think about. The discipline is knowing where to stop building.

A component earns its place only by surviving the principles above. We will not take something that locks the customer in (principle 3), that has to be trusted rather than checked (principle 1), that cannot keep clinical data encrypted on its way to storage (principle 5), or that has no route to keeping European data in Europe that we could certify (principle 8). "It works" is not enough on its own: a component that works but costs us a principle is the wrong component. When the best thing available fails that test we keep looking, fund the missing piece in the open, or build that narrow part ourselves.

A regulator, a procurement team, or a clinician evaluating the platform should be able to read what the platform doesn't do as easily as what it does — and trust that the document matches reality. Hidden limits are technical debt against the customer relationship; they are paid back at the worst possible moment.

Every feature page here has a "Limits and trade-offs" section naming what the platform does not do, and why. Anonymisation is a layer, not a guarantee. Cross-zone analytics are deliberately limited. No query can reach across two customers. Raw audio is kept only briefly, on purpose. The on-site appliance runs the same features as the cloud today. Customers who decline the data-use programme see improvements arrive more slowly. None of these are unfinished work hidden behind language; they are deliberate choices, named so the customer can weigh them. Every feature page on this site carries its own "Limits and trade-offs" section.

Compliance zones default to EU jurisdictions and their sub-divisions; clinical terminology and personal-data formats are EU-relevant; FHIR national profiles target EU member-state authorities; data residency, AI provider preferences, and audit retention are configured per zone within EU-aware defaults. Hardware supply chains favour European distribution; language support starts from EU member-state languages; regulatory framing assumes GDPR, the EU MDR, and the local realities of EU healthcare regulation.

This is a strategic posture, not a marketing claim. Adapting an EU-first product to non-EU markets later is straightforward; retrofitting EU compliance onto a non-EU product is the kind of integration project that takes years and never quite finishes. The platform makes the EU choice early so it does not have to be made painfully later.