Jengu

Our principles

How we build Jengu. When a tough decision lands on our desk — between expedient and durable, between convenient and safe — these are the rules that decide it.

How to read this

Each principle is a value we won't trade away. They're not abstract: every feature we offer, every default we ship, every limit we acknowledge is a consequence of one or more of these.

The principles are presented in parallel — none is the trump card over the others. In practice they reinforce each other: trust through visibility and privacy by construction together produce "you can see we did the right thing because we couldn't have done otherwise"; open source in mind, customer sovereignty, and honest limits together produce "the customer is never locked in or talked down to".

1. Trust through visibility

Healthcare buyers do not trust SaaS vendors who say "trust us". They trust what they can see for themselves.

The platform is built on the assumption that every important state — what is configured, who accessed what, which AI processed which transcript, when raw data was opened, what consent was given — must be visible to the customer in a form they can audit. Trust is not a property of the relationship; it is a property of the artefacts.

Concretely this means configuration lives in a git repo the customer can read; access events are FHIR AuditEvent resources the customer can query; AI processing is logged with kind and outcome; raw-data access is a deliberate, audited path; consent state is recorded and reviewable. When the compliance officer asks "show me", there is something to show — and they did not have to take the vendor's word for any of it.

2. Open source in mind; charging for service, not code

The customer can run the platform themselves if they want to. The vendor competes on quality of operation, not on control of code.

The platform's code is open (MIT-licensed) and a customer can self-host on their own infrastructure with a documented docker compose up (deploy/self-host/, docs/arc42-007-deployment/self-hosting.md). This is a deliberate posture: it removes vendor lock-in as a strategic risk for the customer, and it forces the vendor to earn revenue on managed quality rather than on captive code.

The line between what's open and what isn't is explicit. Open: the platform code itself, the module repos (lab, jengu-visits), the EE zone, the build workflows that produce the published container images, and the tools used to manage the on-site appliances Jengu installs at each customer site — those appliance images ship inside the cloud release, not as separate downloads, so a self-hosting customer operates their own fleet from their own cloud with no vendor-only tooling in the loop. Not open: the vendor's operational competence — release orchestration and deploy pipelines beyond build, monitoring and SLO automation, the certified per-zone profile bundles for jurisdictions outside zone-ee, support, and the SLA / regulator-facing obligations of the managed service. The self-hosting deployment doc draws that line in detail.

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.

3. Customer sovereignty

The customer keeps ownership of what is theirs — data, configuration, consent, on-site hardware — and can leave with it.

Sovereignty is not a feature; it is a property of the architecture. Each tenant's clinical content lives in its own dedicated data store with no cross-tenant entanglement; export is at the whole-store granularity — the customer takes their data out the way it was kept, not unpacked 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.

4. Resilience over convenience

Resilience is a first-class citizen in the architecture — while recognising that the platform is still a helping tool. The customer's clinical operation remains responsible for its own critical processes; the platform's job is to stay as useful as possible through disruption, not to take that responsibility on.

The platform reverses the usual SaaS prioritisation: the edge is sufficient for crisis operation, the cloud is better for everyday operation, and disconnection downgrades convenience without removing the clinical usefulness clinicians rely 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.

5. Privacy by construction

Privacy guarantees written as policies are easy to break. Privacy guarantees written as architecture are not.

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.

Concretely: the fields that make clinical data identifiable (patient names, identifiers, free-text notes, recording transcripts) are encrypted in a way platform operators cannot decrypt; raw clinical text reaches AI components only through a sealed boundary; anonymisation runs inline so downstream features cannot receive raw text by accident; tenants are isolated by separate data stores per tenant, not by rules that filter shared tables; compute is stateless so no in-memory cache crosses tenants; the platform operator is structurally locked out of customer clinical content. Each of these is a thing the platform's design prevents, not a thing the platform's policies forbid.

Backed by continuous testing. What used to be a design intent is now verified on every code change. The fields that make clinical data identifiable — patient names, the identifiers that link to a real person, free-text notes, recording transcripts — are encrypted before they reach storage, with keys scoped per tenant. Platform operators have no path to read those keys. When a tenant is deleted, its keys are destroyed — without the key, the encrypted data is mathematically unreadable forever. 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.

Honest limits we still live with. A few pieces aren't at the same standard yet, and we name them rather than hide them. Patient name search uses a one-way transformation rather than full encryption, so clinicians can still find a patient by name without the platform decrypting names. Raw audio deletion is plumbed but the cloud-side enforcement waits on a feature from the recording platform we use. And the on-site appliance's data cleanup currently runs on age rather than on confirmed cloud-sync — in exotic network conditions an older file could be deleted before its copy reaches the cloud.

The detailed status of each claim and each limit lives on the platform status page — where every claim links to the automated test that pins it.

6. We don't reinvent what already works

Jengu's value is the clinical compliance layer on top of well-chosen components — not the components themselves.

Audio capture, real-time communication, FHIR storage, durable workflows, transcription, large language models, commodity edge hardware: these are mature, battle-tested components from open-source projects and external providers. Building bespoke versions would add attack surface, ongoing engineering cost, and certification burden without clinical benefit.

The platform integrates LiveKit for audio, Medplum for FHIR storage, Temporal for durable workflows, multiple LLM providers behind a routing layer, and Pi-class hardware for edges. Each substrate is chosen because it is already trusted in regulated environments elsewhere; the platform's job is to compose them under the clinical and EU-regulatory constraints the substrate authors did not have to consider. The discipline is to know where to stop building.

A component only earns a place under Jengu if it survives the principles above. We won't bring in a substrate that requires locking the customer in (principle 3), that needs to be trusted rather than verified (principle 1), that can't be made to keep clinical data encrypted on the way to storage (principle 5), or that doesn't have an EU-residency path we can certify (principle 8). "It works" isn't enough on its own — a component that works but forces us to compromise on a principle is the wrong component. When the best-in-class option fails this filter, we either keep looking, sponsor the gap (open-source contributions), or build the narrow piece ourselves rather than weaken the substrate stack.

7. Honest limits

Every feature comes with limits. The platform names them explicitly rather than burying them.

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 in this documentation has a "Limits and trade-offs" section that names what the platform does not deliver, and why. Anonymisation is a layer, not a guarantee. Cross-zone analytics are deliberately limited. Cross-tenant queries do not exist. Raw audio retention is short by design. The edge runs the same modules as cloud today. Non-consenting customers see slower improvements. 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.

8. EU-first

The platform is designed for the EU regulatory environment from day one, not adapted from a US/global product after the fact.

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.

These are the values. The features page describes what we actually deliver to your healthcare organisation — and where the honest limits sit on each one.

Platform features →