Architecture crafted for
life's continuity.
A transparent account of the technology behind your digital life vault. We move past cold industrial jargon to provide a secure, human-centric bridge for your family.
System design
Where does my data actually live?
We use Amazon's top-tier data centres in Mumbai (ap-south-1), with AWS Hyderabad (ap-south-2) as our backup region. Our system is “serverless,” meaning no computer stays on for hackers to poke at.
100% AWS Lambda. Multi-region redundancy (ap-south-1, ap-south-2). Fresh execution context per request.
Region-locked silos
Where does each user's data go?
When you sign in, an Identity Directory checks your country and routes you to the right silo. Today only the India + GCC silo is live. Indian users sit there by default. GCC users sit there too, with explicit consent at signup. Each future silo stays isolated — data never crosses.
Edge: CloudFront + Route 53. Identity Directory routes by phone/email to region. No PII stored in directory. Today: India + GCC silo (ap-south-1, ap-south-2). Roadmap: US silo (us-east-1, us-west-2), SEA silo (ap-southeast-1, ap-southeast-3), dedicated GCC (me-central-1 when stable).
Why AWS Mumbai?
Local compliance and security.
AWS Mumbai provides the strongest data-centre footprint in India. Staying on Indian soil ensures your legacy follows local laws and remains available to your family without complications.
Multi-Region DR strategy. Failover endpoints in ap-south-2. Native Cognito localised phone support and FIPS 140-2 compliant cryptographic modules.
Authentication flow
Sign up and log in safely.
Registration: verified via Phone OTP and Email OTP. You set a security question and a 4-digit MPIN. Trusted use: daily access requires only your 4-digit MPIN. New device: triggers 2-factor security — phone OTP first, then your MPIN.
Multi-channel OTP verification. Credentials: salted, slow-hashed security answer and MPIN. Re-auth on new device triggers 2FA logic.
MPIN on shared devices
Why can't my family open this?
In shared-phone homes, fingerprints allow anyone enrolled to enter. A private 4-digit PIN keeps your vault private while kids play games or your spouse uses the phone.
4-digit MPIN stored as a salted, slow hash on the server. Server-side validation with a 3-strike lockout counter stored in DynamoDB. Lockout duration: 24 hours. Reinstall, device wipe, or device change does not reset.
Why a 4-digit PIN?
Is 4 digits really secure?
Yes — because the protection is the lockout, not the length. Three wrong tries and your vault locks for 24 hours. Even a thief with your phone gets only 3 guesses before the door slams shut. We chose 4 over 6 deliberately: longer PINs cause more forgotten codes, lockouts, and resets — and memory complexity is the real enemy of security in practice, not raw entropy.
4-digit search space: 10⁴ = 10,000. Brute-force mitigation: server-side counter, 3-strike lockout for 24 hours. Practical entropy with lockout exceeds raw entropy of unprotected 6-digit. Trade-off accepted: usability gain > marginal entropy gain.
Hard drive risk
What if someone steals a hard drive?
Data is AES-256 encrypted at rest. Stolen hardware contains only meaningless ciphertext. Master keys live in separate secure hardware modules, never on the same disk as the data.
S3 SSE-KMS and DynamoDB encryption. AES-256-GCM used for authenticated encryption. Bucket policies enforce encryption at-write.
Key management (KMS)
Who holds the keys?
Amazon's hardware security modules hold them. Soult staff never see them. Think of a hardware safe whose lock only recognises a key the system itself constructs — no human ever holds the physical key.
Envelope encryption via AWS KMS. Customer Master Key (CMK) stays in HSM. Data keys generated per envelope, encrypted under CMK, never exported in plaintext.
Field-level security
Double-lock security for your most sensitive fields.
For your secrets (Will IDs, policy numbers, account numbers), we add a second lock. Inside our database, those specific fields look like scrambled gibberish even to engineers with database access.
KMS Field-Level Encryption applied to high-sensitivity columns. Unauthorised table reads cannot expose high-sensitivity content without specific IAM rights.
Encryption in transit
Spy-proof Wi-Fi.
Data travels through a secure TLS tunnel. Anyone snooping on public airport or café Wi-Fi sees only encrypted gibberish — nothing about what you upload or read.
TLS 1.2+ minimum (TLS 1.3 preferred). API Gateway HTTPS enforcement. CloudFront signed URLs (15-minute expiration) for direct asset reads.
The “no-human” principle
Can Soult staff see my secrets?
No. We built a restricted access mechanism. Staff have no “decrypt” button for your vault. Your content is scrambled code to our engineers in normal operations.
Zero human kms:Decrypt permission for user vault keys in routine IAM policies. Least-privilege IAM across all roles. No individual holds “full access” credentials.
Two executor roles
Who can ever see my vault?
Regular Executor (typically a family member): has their own dashboard listing the users they manage. Can raise a death or medical incapacity flag. OTP verified at every step. Every step emails you AND every executor you named.
Emergency Executor (typically the spouse, only one allowed): no flag check needed. Can log in to your vault any time. While they are in, your vault becomes read-only for you. You get an email instantly.
The emergency role is for medical emergencies and time-critical situations. The regular role is for handover after death or long-term incapacity.
Strict RBAC. Two role classes: EXECUTOR_REGULAR (multiple allowed) and EXECUTOR_EMERGENCY (max 1, spouse only). Regular role gates on vault_accessible_flag = true; emergency role bypasses flag. Every state transition fires Amazon SES notifications to user and all named executors. Forced READ_ONLY state on user account when emergency executor is logged in.
Handover protocol
How does my family actually get access?
The named Regular Executor raises a flag from their dashboard — death or medical incapacity. Each step is OTP-verified. Every step emails you and all your other executors, so nothing happens behind your back. Soult phones the executor on the registered number to confirm identity. Government registries (CRS and KRA) are used as a cross-check, but treated as supporting evidence only — records often take months to update. Direct phone and email contact with the executor and family is the primary verification. Two internal Soult approvers must both sign off before access is granted. The executor then sees the entire vault in read-only mode.
Multi-step gate: (1) executor flag raise from dashboard with OTP, (2) outbound phone verification, (3) CRS/KRA cross-reference (advisory), (4) two-person internal approval, (5) vault_accessible_flag set to true. All transitions logged to append-only audit log. Notifications via Amazon SES to user + all executors at every step. Read-only enforcement at API layer; no write/delete endpoints exposed to executor session.
No sharing, by design
Can I share one document with my CA or spouse?
Not today. Your vault works like a private locker — only you have the key. There is no per-item sharing, no per-folder access for an accountant, no time-limited share link. The only way another person ever sees inside your vault is through the executor flow described above — and even then, they see everything in read-only mode. There is no per-item or per-folder granularity yet.
No collaboration mechanism implemented. Sole access paths: (1) authenticated owner session, (2) executor session post-verification. No share-link generation, no scoped tokens, no per-resource ACL. Roadmap consideration only — not built.
Reality check
What are the risks?
We protect against hackers, account takeover, and insider access. We cannot stop you from being physically forced to share your PIN. Soult is for organisation and family continuity — not protection from a coerced disclosure under duress.
Threat model excludes physical coercion. Mitigates: exfiltration, account takeover, insider access. Out of scope: PIN extraction under duress, device compromise post-unlock.
Indian soil
Where exactly does my data live?
Today, all user data sits in the India + GCC silo — Mumbai for live traffic, Hyderabad as the disaster recovery mirror. Indian users by default. GCC users with explicit consent at signup, since they share the same physical location. Future silos for the US, Southeast Asia, and a dedicated UAE region will be deployed as we expand. Each silo stays isolated — data of users from one region never crosses into another.
Active silo: ap-south-1 (Mumbai) primary, ap-south-2 (Hyderabad) DR. Live replication; failover automated. DPDP Act 2023 compliant. GCC users included in this silo with documented consent and standard contractual clauses on file.
Disaster recovery tiers
What happens at each level of failure?
Tier 1 — one server fails: invisible to users, AWS replaces in minutes.
Tier 2 — Mumbai region down: Hyderabad takes over within an hour. No data loss.
Tier 3 — both regions down at once: service stops. Operational recovery in 7–14 days. Full data integrity verified within 60 days.
Tier 4 — every Indian region destroyed: we cannot recover today. Cross-silo backup replication is on the roadmap as we add the US and SEA silos. Until then, manual user backup is the strongest mitigation.
Tier 1: AWS EC2 / Lambda self-healing. Tier 2: cross-AZ failover < 1hr. Tier 3: RTO 7–14d (operational), RPO up to 60d (full data integrity verified). Tier 4: not mitigated today; cross-silo replication into us-east-1 / ap-southeast-1 on roadmap.
The audit trail
Record of changes.
A complete footprint of every Create, Update, or Delete on your vault. You and your nominated notifiers will always know exactly what changes have occurred.
Append-only audit log. Tracks write operations (CUD). Read events excluded for user privacy and performance balance.
Data usage boundaries
No selling, no training, no surprises.
Your vault content is never used to train AI models or for marketing. When AI features are used in the app, the data for that session is processed in-context only — never retained for model improvement. Revenue is subscription-only. If we ever consider a new way of earning — any change at all — we will ask you first. Not notify. Not announce. Ask. And we will only ask if we genuinely believe it benefits you.
Data isolation. No vault content fed into AI/ML training pipelines. AI features process data in-context per session only — no retention for model improvement. Revenue model independent of vault content. Future monetisation changes gated on explicit per-user opt-in — not announce-and-proceed.
Privacy vs handover
The bridge choice.
Chat apps focus on absolute secrecy — if you lose a key, they can't help you. That is a failure for a life vault. We prioritise verified handover over total blindness. We keep staff out but maintain a human-verified path for family. Soult is a bridge to your legacy, not a digital dead end.
KMS-managed key recovery model, gated on verified death or incapacity events only. No staff-side decrypt during normal operations; recovery path requires the multi-step gate described in §11.
Roadmap
What is shipping next?
Near-term: one-click vault export (today users back up manually); US silo (N. Virginia, DR Oregon); SEA silo (Singapore, DR Jakarta); cross-silo backup replication so something always survives even if a whole region is lost.
Mid-term: dedicated GCC silo when AWS UAE region matures; SOC 2 Type II.
Always-on: ongoing audits, security hardening, infrastructure reviews.
Phase 1 (active): one-click encrypted export, US silo bring-up. Phase 2: SEA silo, cross-silo cold backup replication, WAF, SSL pinning on mobile clients. Phase 3: dedicated me-central-1 silo, SOC 2 Type II, hardened multi-region KMS.
Honest claims
Every marketing claim, checked. What is true today, what is planned, what is not built, what we do not use.
| Claim | Status | The practical truth |
|---|---|---|
| Staff-inaccessible vault | TRUE | IAM locks prevent humans from seeing content during normal ops. |
| Data residency in India | TRUE | All data stays strictly within India (Mumbai / Hyderabad). |
| ISO 27001 & ISO 9001 certified | TRUE | Independently audited security and quality management. 27001 PDF ↓ · 9001 PDF ↓ |
| AES-256 encryption | TRUE | All vault contents encrypted with industry-standard AES-256-GCM. |
| One-click vault export | PLANNED | Not built today. Users take manual backups. Coming in an upcoming release. |
| Per-item sharing | NOT BUILT | No sharing or collaboration today. Executor flow is the only access path. |
| Cross-silo backup | ROADMAP | Backup replication across silos comes when US/SEA silos deploy. |
| Recovery if both Indian regions fail | 7–14d / 60d | Operational recovery 7–14 days. Full data integrity verified within 60 days. |
| Account deletion | IMMEDIATE | 10-second confirmation, then permanent key destruction. |
| AI training on user data | NEVER | Vault content is never used for AI model training, even when AI features are used in-session. |
| Blockchain | NOT USED | Wrong tool for a private vault. We use audit logs instead. |
| Zero-knowledge architecture (full vault) | PLANNED 2026 | Today: KMS-managed envelope encryption with staff-inaccessible IAM. Full zero-knowledge across the vault is a roadmap item, not a current claim. |
Common questions
How do I delete my data?
Deletion is immediate and permanent. After a 10-second confirmation pause, we destroy your encryption key. Old backups become unreadable from that moment. Take a manual backup first if you want to keep anything — the one-click export feature is coming in an upcoming release.
What if Soult shuts down?
We open a 90-day sunset window. You download everything in plain readable formats. We will not sell your data, transfer your vault to a buyer without consent, or delete vaults during this window.
How are subscriptions billed?
Managed via Razorpay on the Soult website. No in-app purchases. This keeps billing separate from your vault device.
Erasure protocol details?
Immediate user-key revocation across primary, replica, and any backup storage. Stored ciphertext rendered globally unreadable. Sunset window: 90 days, mandatory; reminders weekly via Amazon SES; sale or transfer of vaults gated on per-user consent.
Why doesn't Soult use blockchain?
Blockchain is built for public verification on shared ledgers where parties do not trust each other — cryptocurrency, supply chains across rivals, public land records. Its strength is making tampering visible to the world.
Soult vaults are the opposite of public — they are private by design. The user is the only party with stake in the data. Tampering intent is low: it is the user's own data, kept for the user's own family.
For change tracking, we use audit logs (see section 14) — every Create, Update, Delete is recorded with timestamp and actor. Blockchain would add cost, complexity, and reduce privacy by exposing patterns to a public ledger — without solving any user problem.
Reconsidered if and when verified-public attestation becomes a real user requirement.
More on what Soult can and cannot do — read the Legal Validity page. For the executor protocol in detail, see Executor & Handover Flow.
Get Started Free →