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 centers in Mumbai, with AWS Hyderabad as our backup fallback. 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."
Amazon Mumbai provides the highest standard of security 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 localized phone support and FIPS 140-2 compliance.
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 PIN.
Trusted Use: Daily access requires only your 4-digit PIN.
New Device: Triggers 2-Factor Security: Phone OTP first, then your PIN.
Multi-channel OTP verification. Credentials: salted, slow-hashed Security Answer and MPIN. Re-auth triggers 2FA logic.
MPIN & Shared Devices
"Why can't my family open this?"
In shared-phone homes, fingerprints allow anyone registered 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. ICICI Bank uses 4-digit PINs for the same reason: 6 digits cause too many forgotten PINs, lockouts, and resets. Memory complexity is the real enemy, not entropy.
4-digit search space: 10^4 = 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. Stolen hardware only contains meaningless characters. Master keys stay in separate secure hardware safes.
S3 SSE-KMS and DynamoDB encryption. AES-256-GCM utilized for authenticated encryption. Bucket policies enforce encryption.
Key Management (KMS)
"Who holds the keys?"
Amazon’s hardware holds them. Soult staff never see them. It's like a bank vault where the machine only recognizes your key.
Uses Envelope Encryption via AWS KMS. Customer Master Key (CMK) stays in HSM.
Field-Level Security
"Double-lock security."
Most data is already out there. For your secrets (Will/Policy IDs), we add a Double Lock. Inside our database, those specific fields look like scrambled gibberish.
KMS Field-Level Encryption. Unauthorized table reads cannot expose high-sensitivity content without specific IAM rights.
Encryption in Transit
"Spy-proof Wi-Fi."
Data travels through a secure tunnel. Hackers on public airport Wi-Fi cannot see what you upload or read.
TLS 1.2+ minimum. API Gateway HTTPS enforcement. CloudFront Signed URLs (15-min expiration).
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.
Zero Human kms:Decrypt permission. Least Privilege IAM policies. No person 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. We use government registries (CRS and KRA) as a cross-check, but treat them 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 bank 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. We cannot stop you from being physically forced to share your PIN. Soult is for organization and family continuity.
Threat model excludes physical coercion. Mitigates Exfiltration, Account Takeover, and Insider Access.
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 SCC 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."
Footprint of every Creation, Update, or Deletion. You and your notifiers will always know exactly what changes have occurred.
Append-only Audit Log. Tracks write operations (CUD). Read events excluded for user privacy performance balance.
Data Usage Boundaries
"No selling, no bots, no surprises."
Soult does not currently use AI in the app. Your data is never used for training or marketing. 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. Consent without user benefit is not enough.
Data isolation. No integration with AI/ML training pipelines. Revenue model independent of vault content. Future monetisation changes gated on explicit per-user opt-in - not announce-and-proceed.
Privacy vs Handover
Chat apps focus on absolute secrecy where they can't help if you lose a key. That's a **failure** for a life vault. We prioritize Verified Handover over total blindness.
"The Bridge choice."
We keep staff out but maintain a human-verified path for family. Soult is a bridge to your legacy, not a digital dead end.
Uses a KMS-Managed Key Recovery model for verified death/incapacity events only.
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. Phase 3: dedicated me-central-1 silo, SOC 2 Type II, hardened multi-region KMS.
Honest Claims
| 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. |
| AES-256 Encryption | TRUE | All vault contents encrypted with bank-grade AES-256. |
| One-Click Vault Export | PLANNED | Not built today. Users take manual backups. Coming in 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 | Architecturally impossible without full key compromise. |
| Blockchain | NOT USED | Wrong tool for a private vault. We use audit logs instead. |
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.
"Subscription payments?"
Managed via Razorpay on the Soult website. No in-app purchases. This keeps billing separate from your vault device.
Immediate user-key revocation across primary, replica, and any backup storage. Stored ciphertext rendered globally unreadable. Sunset window: 90 days, mandatory; reminders weekly via SES; sale or transfer of vaults gated on per-user consent.
Common Myths
Why doesn't Soult use blockchain?
Blockchain is built for public verification on shared ledgers where parties do not trust each other - cryptocurrency, supply chain across rivals, public land records. Its strength is making tampering visible to the world.
"The wrong tool for a private vault."
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.
Threat model: low-tampering, high-privacy. Append-only audit log delivers required integrity guarantees at constant cost. Distributed-ledger overhead (consensus, gas, public exposure of metadata patterns) introduces no marginal benefit for a single-tenant private vault. Reconsidered if and when verified-public attestation becomes a user requirement.