Zelyn Phase 1 architecture v3, with Zelyn's documents

Bodies 1 to 4 need about 133 developer-days, about 13 to 14 weeks of work for two developers. If work starts on Monday 2 November 2026, with Monday-to-Friday weeks and Tamil Nadu holidays, bodies 1 to 4 are ready for the pilot on Wednesday 24 February 2027 (week 17). The calendar is longer than the developer-days alone because some tasks must wait for others, the outside security test needs the finished system, and five holidays fall on weekdays. Every figure includes design, build, testing and documentation. We estimated each task for our two developers, working full time, and checked the figures against how fast they have delivered recent work. Each body is broken into the activities we would plan it by; open any body below to see them. Figures are rounded to half a day.

We will re-confirm these figures at the end of week 2, after we walk through the current code with its developer, and again after the first three development iterations.

About 64.5 developer-days, about 7 weeks of work. It is ready for acceptance on Monday 21 December 2026 (week 8) if work starts on 2 November. It follows Zelyn's build order: the WhatsApp direct version first, then a first piece of the clinician version on the same foundation.

The milestone is accepted (Gate 1) when it works on test data: a woman completes either intake on a real phone, a red flag routes correctly, both intakes attach to the same record for her, each keeping its source, the clinician view shows her answers, and consent and deletion behave as specified.

All three deployments are sized at all eleven levels Zelyn listed, with every item Zelyn named. India costs about $1,000 a month at 1,000 women and about $55,700 at 1 million, including Meta's WhatsApp charges. At 1 million, about $27,700 is Azure hosting and about $28,000 is Meta's charges. Voice is included in the sizing, though voice is not built in bodies 1 to 4. Prices are Azure list prices fetched on 27 October 2026 and Meta's rate card of 1 October 2026, with no discounts. The usage behind them is our assumption, listed below. When Zelyn sends its usage profile we re-run the same model within 5 working days.

Usage we assumed, per active woman:

• Active woman: used Zelyn at least once that month. 25% use it on a given day; the busiest hour carries 15% of the day; a session is about 5 minutes.
• WhatsApp: about 40 messages per woman a month, 20 in and 20 out; 6 of those sent are paid templates (reminders, Day 7, Day 21).
• Server work: about 200 server calls per woman a month.
• Data: about 50 KB of answers and 150 KB of audit records per woman a month. Message text kept 90 days. Logs kept 180 days in India, 90 in the US. Backups kept 14 days.
• AI safety check: 10 free-text messages per woman a month, about 500 tokens each.
• Voice (sizing only): 20% of women send 4 voice notes a month of 30 seconds, and hear 4 approved replies read aloud.
• Bandwidth and uptime: about 5 MB per woman a month; 99.9% uptime; at most 5 minutes of data lost; back up within 4 hours.

• Meta's part is short, but the templates must be drafted early. Zelyn's account is already verified. Meta decides on each message template within 24 hours, so templates are submitted as they are drafted in weeks 4 to 5. The WhatsApp provider's written confirmation has no official time, so it is asked for in week 1.
• Zelyn's WhatsApp number may need registering again with India storage before any real message. Meta sets the storage region only at registration (question 5 on the Questions tab).
• The Menopause Rating Scale licence is needed before its scoring is coded. The request goes out in week 1.
• Body 3 decides the fields Body 4 shows. In week 8, when Bodies 3 and 4 start side by side, both developers agree the fields the clinician version collects, before the dashboard is built on them.
• The privacy notice must be rewritten by counsel and translated before launch. The live notice still has a placeholder (point 25 below). Counsel is briefed in week 1. By week 6 Zelyn agrees the list of items she consents to, which we draft from our data inventory; the consent screens are built on it. Counsel's final wording and the translations have no official time and are needed by Gate 2.
• Two regulatory opinions and the clinic agreement are needed before real patients: who is responsible for clinic patients' data, and whether any part is a medical device.
• We add a Gate 2 before the clinician pilot: the independent penetration test, clinical sign-off per language, the two legal opinions and the restore and deletion drills. Indian security rules and Zelyn's own content approval need these before real patients.
• Zelyn's usage profile is needed in week 2 to finalise the infrastructure projections.

Every outside approval, with the time its owner officially states. Where the owner publishes no time, we say so and start it in week 1.

From Zelyn to us, at the start (about 3 days in Body 1): a code walkthrough by the developer who wrote it, the feature inventory, the card-selection rules, the safety rules and the existing tests, and access set-up.

From us to Zelyn, at every gate and at the end of each body of work: a recorded walkthrough, updated documentation and a handback review. Documentation is updated at every milestone, not at the end.

Handback when bodies 1 to 4 are complete, good enough for another team to continue: the repository, the infrastructure code, the runbooks, the evidence folder, the architecture decision records, every credential returned and rotated, and a 30-day warranty. Everything lives in Zelyn's GitHub and Zelyn's accounts from the first commit.

Main assumptions. Two full-time developers. Zelyn's inputs arrive on the dates in the proposal (content, clinical specification, the clinical reviewer, clinic agreement). Usage as listed on the Hosting cost tab until Zelyn's profile arrives. Bodies 5 and 6 are not built.

What we would change in Zelyn's documents.

• The AI safety check runs in South India, or on Azure AI Language in Central India. Microsoft does not offer Azure OpenAI in Central India on a pay-as-you-use basis, and its other options send messages outside India. Both choices keep her text in India.
• No totals cross a border in Phase 1. The Architecture of Record allows consented, de-identified totals to cross. Sponsor reporting is not in this scope, so we keep it switched off until counsel or a qualified expert approves the method.
• A few records are kept after she asks for deletion: her consent history, audit rows pointing to a blank marker, and a scrambled copy of her phone and email so she is never messaged again. Counsel to confirm; the privacy notice must say so.
• Her record is keyed by a Zelyn-generated ID. The phone, WhatsApp user ID, email and clinic patient number are linked to it with equal standing. The Architecture of Record makes the verified phone the spine; the roadmap makes the WhatsApp user ID first-class. We follow the roadmap and ask Zelyn to confirm (question 6).
• The Greene scale is proposed out; the Menopause Rating Scale only, once licensed.
• A Gate 2 is added before real patients (point 5 above).
• Check-ins to a family member's phone are built with the rest of Body 3, after the first milestone, with her separate consent for that person and a way to withdraw it at any time. A second person receiving her health messages, and shared or recycled phones, need that care.
• Voice notes before Body 5: if she sends one, the system asks her to type.

Main risks, each with what we do:

• Meta or the provider does not clear the health workflow: written confirmation in weeks 1 to 2; WhatsApp behind a switch; a web fallback with no health content in SMS; Zelyn owns the number.
• A worrying free-text message is missed: the fixed rules route; a named human reviewer in India, or an honest "not monitored in real time" line; the model check is never presented as a safety net until it is validated.
• Translation changes clinical meaning: AI drafts with context and a glossary; we check Tamil, outside verifiers check Kannada and Hindi, and a different party back-translates; a clinician signs each language.
• Outside approvals delay the pilot: all started in weeks 1 to 2; the pilot date is a range; scope cuts agreed in advance.
• A two-person team loses a person: Siva and Dharun kept up to date from week 1.
• Our recent hosting is on AWS; our Azure work is older: cloud-neutral design, Azure-specific items checked in week 1.

We have not estimated bodies 5 and 6 yet. Zelyn's roadmap says the requirements document for the expanded journey is to follow, and gives the app as an intended shape, so a figure now would be a guess. We will estimate both once the requirements are clear. Bodies 1 to 4 are built so these add to the foundation rather than change it: the app is one more screen on the same engine API, voice fills the same inputs she types into, and the record already has the fields they need.

Seven points are not settled by the roadmap or the Architecture of Record, or are settled differently in the two. Each has our recommendation, so a yes is enough:

The decisions Zelyn needs to make, and the questions for Zelyn's lawyer, are on the Decisions tab.

One engine behind a versioned API. The web app, WhatsApp, the future app and the clinic dashboard are only screens that call it. The engine holds Zelyn's existing rules unchanged. Around it we build:

• One record per woman, keyed by a Zelyn ID, with every identifier linked to it (answer 11).
• A shared symptom list that every intake writes to: the direct intake, the clinical intake, staff entry and check-ins. Each validated scale is mapped onto it. The direct intake uses part of it, and its answers pre-fill the matching questions at a clinic.
• Who entered each answer is recorded on every answer: her, a nurse, the doctor, a health worker, or a family member on her behalf.
• Consent as its own history per purpose, channel and language, storing the exact text she saw, checked on every request.
• Access enforced twice: in the API and in PostgreSQL row-level security, tested for every role and clinic. A doctor or nurse sees only women in an active care relationship. Sponsors see only totals.
• An audit trail written in the same step as every read or change of identifiable data.
• Country lock: India and the US have separate databases, backups and logs, with no link between them.
• Switches per channel, partner, market and language, kept in Zelyn's own PostgreSQL, plus an entitlement record and usage metering per partner.
• Referral codes in links and QR codes, which set the sponsor field at enrolment. No invitation codes.
• One connection point for AI models, swappable by configuration, with shadow mode.
• An add-only database: fields are only ever added, never removed or renamed, so earlier data stays readable.
• A conformance test that proves the web and WhatsApp give exactly the same cards, safety response and record.

Her Zelyn ID is created at sign-up and never derived from any identifier. Every identifier she shares is linked to it: email from the web, phone where she shares it, the WhatsApp user ID from her first message, and clinic patient numbers scoped to each clinic. Each identifier is stored encrypted, with a scrambled copy used only for matching.

On WhatsApp with only a username, the WhatsApp user ID is her key. She never has to share her number. When she later arrives at a clinic with only a phone number, we never merge on the number alone. A message to that number brings back her WhatsApp user ID: Meta includes it in every delivery update, even when the message was sent to a phone number (Meta's page). That becomes a suggested match, and clinic staff confirm it in a match queue. Two people are never merged without a person confirming.

When a red flag fires, the journey stops. She gets Zelyn's fixed safety wording as its own message, with a call button. Until she taps an acknowledgement, every message she sends gets the same safety message first, and no card, check-in or reminder goes out. The red-flag state is on her record, and the scheduler checks it before every send. The message points to 112 and the Tele-MANAS line 14416. (On the web and app in the US, the same screen points to 988.) Only the fixed rules decide this, never a model.

The WhatsApp form keeps only what must be done before she reaches the clinic: the essentials and the red-flag questions, about ten questions over two or three screens. The validated scale, menstrual history and anything long or free-text go to the clinic-branded browser form. It opens from a secure single-use link, saves each answer, and can be finished in the waiting room or by the nurse.

People from the projects we referenced are on the team. Siva built on Shoppyti, Valarchi and ECS; Dharun on e-Pass; Merlin and Hariharan built the projects listed against them.

• One record: one Zelyn ID per woman, with her web email, phone, WhatsApp user ID and clinic numbers all linked to it (answer 11). Web and WhatsApp link with a one-time code.
• No duplicates: a new identifier is checked against the scrambled identifiers already linked. A likely match is never merged automatically; a person confirms it. Shared and recycled phone numbers are in the acceptance tests.
• Interrupted journeys: each WhatsApp form screen is saved as she goes. If she stops, she resumes from the last saved screen. The conversation state is kept on the server, so a lost message or a closed 24-hour window does not lose her place.
• Rules logic intact: Zelyn's existing rules are moved behind the engine API unchanged. The conformance test runs the same cases through the web and WhatsApp and must give the same cards, safety response and record. A failing case blocks the change.

What we built before: Shoppyti, our own seller and buyer platform on WhatsApp and Instagram, on Meta's Cloud API: signed webhooks, OTP templates, fallback to approved templates when the 24-hour window closes, Meta error handling, retries with backoff and scheduled jobs. Shoppyti did not track whether each message was delivered and read, or handle STOP opt-outs. This plan adds both.

• Scheduling: sends run from a queue with retries and backoff. Outside the 24-hour window only approved utility templates go out.
• Opt-outs: keywords in each language, and in Roman script, stop sends at once and write a suppression entry that survives deletion.
• Delivery failures: every message stores its template, language, the consent it relied on, and its sent, delivered and read status from Meta. A failed message is retried, then shown in the clinic queue.
• Recovery: each webhook is stored once, signature-checked, and handled by jobs that are safe to run twice. Her place in the journey is kept on the server (answer 15).

What we built before: Valarchi, AI-assisted exam marking for Tamil Nadu schools, holding children's data under India's DPDP Act: verifiable consent, PostgreSQL row-level security with live tests, an append-only audit, no support access to personal data by default (emergency access only, audited), and retention with human-approved purge. The Tamil Nadu e-Gazette portal: an audit log with old and new values, user, IP address and browser for every change. Tamil Nadu e-Pass: about 35 million passes, every action audited, no direct database access. We have not built a clinical system before; this work comes from education, banking and government systems.

How we build it here: consent as an append-only history storing the exact text she saw, checked on every request; the audit written in the same step as each read; access enforced in the API and in PostgreSQL row-level security, tested per role and per clinic.

On the call we will show the consent, audit and access screens of Valarchi and Tamil Nadu e-Pass, on dummy data.

• The English master is the clinical text, written and owned by Zelyn.
• Velosyti translates every language using AI language models, given the context of each text: where it appears, who reads it, and a glossary of the words women actually use. This is inside the monthly fee.
• Velosyti's Tamil-speaking staff check the Tamil. Velosyti finds and arranges outside verifiers for Kannada and Hindi. Their fees are a third-party cost that Zelyn pays directly.
• Zelyn's named clinical reviewer signs off each language, Tamil included. It is then tested with eight to ten women in the clinic.
• Velosyti arranges the independent back-translation of each language through a different party, as the roadmap asks. Zelyn pays that party directly.
• Each language file has its own version and a named sign-off. The build fails on a missing string or a wrong placeholder. A language cannot switch on until every string is approved. Safety wording is never machine-translated when a message is sent.

• Regional storage: one subscription per environment and country. In each country one PostgreSQL Flexible Server with customer-managed keys and private endpoints, Container Apps for the API, web, worker and WhatsApp adapter, and Blob storage. India in Central India; US in its own region. No network link, copy or shared directory between countries. Azure Policy blocks any resource outside the allowed regions.
• Backups: point-in-time backups kept 14 days in the same country, with a copy in the paired region inside that country. Deletion is replayed from a deletion ledger kept outside the database after any restore. Restore is drilled before Gate 2.
• Logs: Log Analytics, kept 180 days in India and 90 days in the US, scrubbed of personal details. Microsoft Defender alerts on unusual reads.
• Support access: no standing access to personal data, for us or for Microsoft. Emergency access is time-limited, approved and audited, with its own runbook. Customer Lockbox makes Microsoft ask before its engineers can see data. Staff sign in with two-step login.
• Edge: Front Door with the web firewall, then the gateway, then the engine. Key Vault holds the keys. Everything is set up in Terraform in Zelyn's repository.

We translate every language with AI language models, given the context of each text. We check the Tamil ourselves. Yes, we will find the experts: we find and arrange outside verifiers for Kannada and Hindi, and Zelyn pays their fees directly. Every language, Tamil included, is then signed off by Zelyn's named clinical reviewer before it can switch on, after a test with eight to ten women in the clinic (answer 18).

Translators never receive any woman's data. They receive only Zelyn's content: the questions, cards, message templates and safety wording, with no names, numbers or answers. Her answers and messages are never sent to a translator or a translation service, and Phase 1 does not translate her messages live. The AI models used for the drafts run on Zelyn's own business account, and are given only this content text. The same applies to the verifiers Zelyn engages.

Agreed. The estimate is now about 133 developer-days, about 13 to 14 weeks of work. The first milestone is about 64.5 days, about 7 weeks of work. On the calendar that is 21 December 2026 for the first milestone and 24 February 2027 for the pilot, with Tamil Nadu holidays kept. We estimated each task for our two developers, working full time, and checked the figures against how fast they have delivered recent work. We will re-confirm the figures after the first three development iterations.

Outside approvals follow their owners' official times (answer 5). Meta's part is short: Zelyn's account is already verified and each template is decided within 24 hours. The questionnaire licence, the legal opinions, the clinic contract and the security test have no official time, so we start them in week 1. The earliest pilot is Wednesday 24 February 2027 (week 17), if work starts on 2 November 2026.

Everything open is listed in two places: the Questions for Zelyn tab (seven questions, each with our recommendation) and the Decisions tab (Zelyn's decisions and the questions for Zelyn's lawyer).

Confirmed. The Architecture of Record (slide 5) makes the verified phone the spine. The roadmap (body 1) makes the WhatsApp user ID first-class, because a woman may never share her number. We follow the roadmap: her record is keyed by a Zelyn ID and every identifier links to it with equal standing. We ask Zelyn to confirm.

The consent notice on Zelyn's live server (api-in.zelynhealth.com/api/consent/notice) still has the text "[COUNSEL TO PROVIDE]" where the legal wording should be. Women do not see it today: the server sends enabled: false, so the app skips that screen. The health-data consent shown before the questions has real text. Before launch, Zelyn's lawyer must write the notice, and it must be translated into all four languages.

The requirements are clear and detailed, and the order of work makes sense: one foundation, then WhatsApp, then the clinic. Zelyn's Architecture of Record is a sound design and we keep it.

• Most of the remaining work is content. The questions, cards, red-flag rules, journey paths and messages in each language are data that Zelyn's clinicians approve. The build waits on them more than on engineering.
• Two documents differ on one point: what her record is keyed on, the verified phone or the WhatsApp user ID (answer 24).
• One placeholder is live: the consent notice on Zelyn's server (answer 25).
• Seven open questions are on the Questions for Zelyn tab, each with our recommendation.

The design expects that. The questions, cards, rules and messages are content files with versions and named sign-offs, so most clinical changes are made by editing content, with no new code. New features go live behind switches and can be turned on step by step. Database changes only add fields, never remove them, so earlier data stays readable. A change to the scope is agreed in writing as a short change note; added scope adds time, not monthly cost.

We keep Zelyn's design. Each rule on its slides, and how we meet it:

Each point is also linked to its slide on the Architecture of Record tab. Where we differ from the design, it is listed in answer 7 with the reason.

We accept every one of them. How each is met: