Deals kept apart. Controls you can inspect. Your cloud.
Mergiva is built for GxP and designed to align with 21 CFR Part 11 and EU GMP Annex 11. It runs as one dedicated installation in your own Kubernetes, and keeps deals apart in independent layers.
Deals kept apart, layer by layer.
The useful question is not whether the code filters by deal. It is what happens when the code forgets. Independent layers answer that.
In a platform that holds many deals, one missing filter in application code could show one deal’s files to another deal’s team. Reviewing the code helps, but code changes every week. Mergiva keeps deals apart in layers that work independently of each other.
The database keeps every query inside its own tenant. By default, a user can open a deal only while on its deal team. Keys, storage paths and the identity check then limit what any mistake can reach.
Deal-team access
Team A onlyTeam B onlyVerified identity
RS256 tokenRS256 tokenRow-level security
tenant · deal Atenant · deal BStorage paths
/tenant/deal-a//tenant/deal-b/Keys, on request
KMS key AKMS key B
- Database: row-level security
- Every query is scoped to its tenant by the database, and to its deal whenever the request names one. Security is forced, so owning a table is no exemption, and the application’s database role cannot bypass it. A request that names no tenant returns nothing.
- Keys: a key per deal, on request
- A deal can be given its own AWS KMS key, created through the real AWS API, with rotation and a mandatory waiting period before destruction. Connector secrets are AES-256-GCM encrypted; one bound to a deal uses that deal’s key.
- Storage: deal-scoped paths
- Objects land under a path keyed by tenant and deal, so your storage permissions can be scoped deal by deal. Long-term records go to object lock in compliance mode, which has no privileged override.
- Identity: verified, not asserted
- Tokens are RS256 and checked against the published keys of the Keycloak you run. A service configured for production without strict verification refuses to start. A token that names no tenant, or a header that disagrees with the token, is rejected.
- Access: the deal team only
- By default, a user can open a deal, its files, waves and audit trail only while on its deal team. Administrators see every deal, and your installation decides which other roles do. Clean-team access ends automatically once the deal closes, every assignment ends when a deal is terminated, and each ending is recorded in the ledger.
Requests from users always run under row-level security. A narrowly scoped system role serves a few named background jobs.
What leaves your cloud, and what does not.
A regulated buyer needs to know exactly where data can go. Apart from the systems you connect, this is the list.
Your data stays in your cloud
Mergiva is installed into your own Kubernetes cluster. We do not operate a shared service, and we have no standing access to your deal data.
What AI classification sends
A classification request carries the file’s name, path and type, plus up to its first 4 KB for files on local or NAS sources. Microsoft Presidio redacts detected personal data first.
Where AI goes, and how you control it
By default the request goes to Anthropic’s Claude, under your own key. You can route it through your own AI gateway instead, and set the personal data guard to refuse any classification request that contains personal data. A call your settings cannot serve is refused, never sent somewhere else.
Secrets and signatures
Connector credentials and Slack and Teams webhook addresses are encrypted before storage. Signatures need a fresh login against your Keycloak, and the resulting token expires within 300 seconds.
Notifications go only where you point them: your mail relay, and the Slack or Microsoft Teams webhooks you configure.
Part 11 controls, and the mechanism behind each.
21 CFR Part 11 sets the conditions under which the FDA treats electronic records and signatures as trustworthy as paper ones. EU GMP Annex 11 covers the same ground for computerised systems used in GMP work in Europe. Software cannot meet either on its own. An installation meets them after your team validates it and runs it under your procedures.
What software can do is give each control a mechanism you can inspect, test and cite. Each control below names that mechanism, with the detail an assessor asks about first.
Tamper-evident ledger
§11.10(e) · Audit trail
Each entry carries the SHA-256 of the one before it, chained per deal. Database triggers reject update, delete and truncate. A verify routine names the first broken entry. An entry always names the person who really acted, and the public API can only read the ledger.
Good to know
130 of 147 state-changing routes write to it, and each of the other 17 carries a written reason why it is not a regulated record.
Electronic signatures
§11.50, §11.200 · Signatures
Who, when, what and the meaning of the signature are set on the server, never taken from the caller. Each signer logs in again; the token comes from your Keycloak and expires within 300 seconds.
Good to know
Waves and the gated stage changes are e-signed. Exception decisions are recorded with a written reason in the audit trail.
Two distinct signers
Segregation of duties
Two signatures from two different people, each identity taken from their own re-authentication. The creator of a wave cannot approve it. Enforced in the service and by a unique index in the database.
Good to know
Sixteen built-in roles. By design, changing a control goes through your change control.
Roles and deal teams
§11.10(d) · Access control
Sixteen roles in four tiers. By default, a user can open a deal only while on its deal team. Row-level security in the database keeps every query inside its own tenant, and the application’s database role cannot bypass it.
Good to know
Revocation takes effect at the gateway at once. Data services honour it within the token’s remaining life, at most five minutes. Removing someone from a deal team ends their access to that deal on their next request.
Retention and legal hold
§11.10(c) · Records
Object lock in compliance mode on Amazon S3 and MinIO, and each store’s own retention controls on Azure and Google Cloud, with a fifteen-year default. Per-file legal hold. Storage that cannot honour a policy is refused.
Good to know
Retention applies to the migrated copy in object storage, not to the source estate.
Executed with your QA
System validation
You receive the Part 11 and Annex 11 evidence maps, the control inventory, runbooks and the test artefacts your QA team needs to validate against your own infrastructure.
Good to know
Validation is executed with your QA team, on your infrastructure, using the evidence pack below.
EU GMP Annex 11 adds periodic audit-trail review and lifecycle documentation over the same ground. Compliance belongs to your validated installation, and these mechanisms are what your QA team validates.
A ledger you can re-verify.
Every entry records who acted, what they did, to which resource and from which address. Where they apply, it also records the state before and after, the reason and the e-signature.
Entry 1
prev hash = genesis
checksum over the entry
Entry 2
prev hash = entry 1
checksum includes it
Entry 3
prev hash = entry 2
checksum includes it
Entry n
prev hash = entry n−1
alter any earlier row and every later checksum breaks
verifyChain
Recomputes every checksum in order and returns INTACT, or TAMPERED with the first broken entry named.
130 / 147
State-changing routes that write to the ledger
88.4% on 26 September 2026. Each of the other 17 carries a written reason why it is not a regulated record.
Append-only
Enforced by the database
Update, delete and truncate are rejected by database triggers, and a verify routine names the first broken entry.
Zero
Unaudited routes allowed
A state-changing route that writes nothing to the ledger, without a written exemption, fails the build.
A hardened PostgreSQL ledger, with a second copy queued to object-lock storage off the database host. Coverage figures are from 26 September 2026.
Retention and legal hold.
Object lock in compliance mode on Amazon S3 and MinIO has no privileged override, which is the point of a long retention obligation. On Azure and Google Cloud, Mergiva uses each store’s own retention controls.
- Policies default to fifteen years, and one step applies them to a wave’s verified files.
- A legal hold is set per file, with a reason and an accountable user.
- Each storage adapter reports how strong its immutability is, and a policy the storage cannot honour is refused.
- Retention covers the migrated copy in object storage.
Validation is work we do with you.
Validation is an executed qualification in your environment, signed by your people. This is what your QA team receives to start, and we execute the validation with you.
Evidence maps
Requirement-by-requirement maps for 21 CFR Part 11 and clause-by-clause for EU GMP Annex 11.
Control inventory
Each control and the mechanism that implements it.
Test artefacts
The unit, integration and end-to-end runs behind each control, and the committed transfer proof.
Runbooks
Operating procedures for incidents, backup and restore.
Your cloud, your cluster, your data.
One dedicated installation per customer, in your own Kubernetes. There is no shared service, and your deal data never passes through us.
Mergiva is a set of services that runs in your own Kubernetes cluster, installed with one Helm chart. The control plane serves the web app and the APIs. The data plane does the work: it connects, scans, classifies and moves files. The evidence services keep the ledger, signatures, reports and retention.
It does not bundle its own database, Keycloak or storage. You run those, so backups, access and network policy follow the standards you already audit.
Your cloud account · your Kubernetes cluster
Mergiva, installed by one Helm chart
Control plane
Data plane
Evidence
You provide
Never bundled. Your backups, your Keycloak, your storage and your network policy stay yours.
One Helm chart
Installs every service into your Kubernetes cluster. In a test install on Kubernetes, every backend service started and passed its health checks.
Checked before it starts
Each service checks its settings before it starts. A development password, a test endpoint or a missing key stops it, and every problem is listed at once.
Fresh secrets
The setup command writes new random secrets for each installation, in a file only its owner can read.
Hardened sign-in
The setup command creates your Keycloak realm with no test accounts. An account locks after five failed attempts, and passwords need at least 12 characters and cannot repeat the last five.
Your branding
Product name, logo, colours and the words for deals and waves are set when your web app is built.
Reference infrastructure
Terraform for AWS, as a starting point for your platform team.
What leaves your cluster
Only what you configure. Deal data can go to three kinds of place, and each one is your choice.
Files
To the source and destination systems you connect. Reports and records go to the object storage you provide.
Notifications
To your mail relay, and to the Slack or Microsoft Teams webhooks you set up.
AI requests
To the model you choose, directly or through your own gateway. A classification request has detected personal data redacted first.
Found something? Tell us.
Write to contact@mergiva-ai.com. The same address is published in /.well-known/security.txt.
Start with one deal.
A pilot starts with the two systems you need to connect, and ends with evidence you can hand to an assessor.
- 1
Name the pair
Tell us the two systems you need to connect. We produce that pair’s evidence before the pilot starts.
- 2
Scan one estate
Run a Data Estate Scan in your own cluster. You get the PDF report and a classification your QA team can inspect.
- 3
Plan validation together
Evidence maps, the control inventory and test artefacts, executed with your QA team on your infrastructure.
- 4
Run the first wave
Two signatures, a verified transfer and a compliance report you can hand to an assessor.
Or write to contact@mergiva-ai.com.