We have nothing to hide.
Here is everything.
This page does not contain marketing claims. It contains architectural facts — specific, verifiable, and stated precisely because precision is what genuine transparency looks like.
Every statement on this page can be verified by reading the source code. For Own-model clients, that source code belongs to you.
The foundational truth of our architecture.
Muladhara products — Sattva and KAI — are offline-first by architecture. Your data is generated on your device, stored on your device, and encrypted by a key that exists only on your device.
There is no pipeline between your app and our servers for operational data. No API call that sends your client records to us. No background sync that copies your financial data to our database. These things do not exist — not because we chose not to build them, but because the entire architecture was designed without them.
This is the distinction between privacy by promise and privacy by architecture. Promises can be broken. Architectures cannot.
Encryption key management — zero-knowledge.
When you set a PIN in Sattva, the app derives an encryption key using PBKDF2-SHA256 — a cryptographic key derivation function. This process happens entirely on your device. The PIN is not stored. The key is not transmitted. The derivation salt is stored locally on your device only.
What this means in practice: Muladhara does not generate your encryption key. Muladhara does not store your encryption key. Muladhara cannot derive your encryption key even with full knowledge of the algorithm, because the input (your PIN) was never shared with us.
PIN (user's device) → PBKDF2-SHA256 (100,000 iterations, random salt) → Encryption Key → AES-GCM
This derivation occurs on-device. At no point does the PIN, intermediate values, or derived key leave the device.
The consequence: if you forget your PIN, we cannot recover your encrypted data. This is not a limitation — it is the proof. If we could recover it, that would mean we had access to your key. We do not.
Backup encryption — sealed, not just locked.
When you export a Sattva backup, the file is encrypted with AES-GCM (Advanced Encryption Standard — Galois/Counter Mode) — the same standard used by financial institutions and defence systems. The encryption key is the one derived from your PIN (see above).
If someone obtains your backup file — through any means — they receive an encrypted binary that is computationally indistinguishable from random noise without the correct key. There is no "forgot password" function that bypasses this. There is no master key that Muladhara holds. The file is mathematically sealed.
For users without a PIN: backup export generates a one-time random encryption password that you must save separately. This password is shown once and never stored anywhere.
AI features — anonymised by design, not by promise.
Sattva's AI features are built on a pseudonymisation architecture. When you use an AI feature — session note analysis, client insight, dashboard summary — the content is tagged to a randomly generated anonymous session identifier, not to your client's name, account, or any identifiable credential.
The AI provider receives: content + anonymous ID. The AI provider does not receive: your client's name, your account details, or anything that could identify who the content belongs to. The mapping between the anonymous ID and the real person exists only in the app on your device — never transmitted.
What AI receives
- Content you choose to analyse
- Anonymous session ID
- The task instruction (summarise, analyse, etc.)
What AI never receives
- Client name or identity
- Your account credentials
- Any information traceable to a real person
You configure your own AI provider. Muladhara does not know which provider you use, does not see your API key, and has zero visibility into your AI transactions. If you use the Sattva-managed AI option (where Sattva calls the AI on your behalf using metered tokens), the same pseudonymisation applies — Muladhara's systems see the anonymous ID, not your client.
The responsibility for the AI provider's terms of service rests with you, as the user who configured and chose that provider. We designed the system to minimise data exposure at every possible layer.
WhatsApp integration — exactly what it is, and what it is not.
Sattva's WhatsApp feature is built on wa.me/ deep links. When you tap a WhatsApp button in the app, the app constructs a URL in this format: https://wa.me/[phone]?text=[pre-filled message] and opens it.
Your device's WhatsApp application opens with the message pre-filled. You review and send it. That is the complete technical interaction.
This is the safest possible WhatsApp integration — it uses no API, stores no credentials, and involves Muladhara in no part of the message flow. It is the technical equivalent of you manually opening WhatsApp and typing a message, with the convenience of pre-filled text.
Device security — PIN, biometric, and lockout protection.
Optional PIN lock with configurable inactivity timeout (5 / 15 / 30 / 60 minutes, or never). PIN is 4 digits. Failed attempts trigger escalating lockout: 5 wrong attempts → 30 seconds → 5 minutes → 30 minutes. Brute force of a 4-digit PIN under this model would require decades.
On Android: biometric unlock (fingerprint or face recognition) available as a second unlock method — requires PIN to be set first. Uses the device's native biometric API, not a third-party library. Muladhara does not receive biometric data in any form.
PIN hash is stored using PBKDF2-SHA256. The raw PIN is never stored anywhere. Even with full access to the device's storage, extracting the PIN from the stored hash is computationally infeasible.
What Muladhara cannot do.
These are not policies. Policies can change. These are architectural constraints — built into the system, not written above it.
"Promises can be broken. Architectures cannot."
Every constraint above is enforced by the code, not by our commitment to uphold it. For Own-model clients, you can verify this in the source code we deliver.
HIPAA, GDPR, and DPDP — honest positioning.
Muladhara does not make compliance claims we cannot substantiate. Here is precisely what we are.
HIPAA — Aligned, by architecture.
HIPAA's core requirement is that Protected Health Information (PHI) is handled securely. Sattva's offline-first, device-local, encrypted architecture means PHI never leaves the device to Muladhara's servers — which places our model significantly closer to HIPAA's intent than most cloud-based software.
The distinction that matters: HIPAA-certified status requires formal paperwork — Business Associate Agreements (BAAs) with all third-party data processors, audit trails, and incident response documentation. These are administrative requirements, not architectural ones. Our architecture already satisfies the technical controls.
Enterprise healthcare clients requiring a formal BAA are welcome to contact us. Given that Muladhara does not process your PHI on our servers, the BAA scope is narrow and straightforward to execute. Contact us at contact@muladharaholistictechnology.com.
GDPR — Aligned, with precision.
GDPR's core principles — data minimisation, purpose limitation, privacy by design — are reflected in Sattva and KAI's architecture. We collect the minimum necessary data. We process it only for the stated purpose. Privacy is built in, not added on.
This website collects only what is submitted through the contact form. No tracking cookies are set. No analytics scripts run. EU visitors have the same rights as all other users: request access, correction, or deletion of submitted data by emailing us.
DPDP Act (India) — Architecturally compliant.
India's Digital Personal Data Protection Act requires that personal data be processed with explicit consent, for defined purposes, and with appropriate security measures. Our offline-first model means personal data in the apps never reaches Muladhara's processing systems. The website collects contact form submissions with explicit consent at point of submission.
Enterprise online model — your server, your control.
When Muladhara builds an online SaaS product for an enterprise client, we build the server — the infrastructure, the application, the database, the security configuration — and then deliver it completely.
After handover, the enterprise hosts the platform on their own infrastructure, under their own domain, with their own credentials. Muladhara holds no access, no backdoor, no administrative credentials to the delivered system.
Muladhara's role after delivery: evolution partner. When the client wants new features, better performance, or adaptation to new requirements — we are available. But the day-to-day operation, the data, and the infrastructure are entirely under the client's control.
For enterprise procurement teams.
We understand that enterprise security reviews require documentation, not just architecture descriptions. Here is what we can provide: