Appearance
Feature set
🔵 Research. Candidate capabilities and the MVP cut.
⚠ THIS PAGE IS THE R1 CUT RATIONALE. IT IS NOT THE FIELD REGISTRY.
The authoritative field set is prototype/consumer/biodata-core.js in the Claude Design project, and the decisions governing it are Consumer decisions. Design rounds 7, 8 and 9 added the kundli group, religion, caste, mama, soyare, bloodGroup, placeOfBirth and the opening block, and this page deliberately does not restate them.
Restating a field list in a second place is how it drifts. Read this page for why a capability made or missed the R1 cut; read the registry for what the fields are.
The five that make the product
Roughly thirty capabilities were proposed. These five are the ones a PDF cannot answer at any price, and each closes a numbered problem from Problem analysis.
| # | Capability | Closes |
|---|---|---|
| 1 | Living card — create once, edit forever; every shared link reflects the change | static file · stale photographs · corrections |
| 2 | Controlled sharing — open / requested / private tiers, per-recipient approval, revoke, expire | no control after sending |
| 3 | Interest without registration — view freely, OTP only at intent, then chat | phone numbers exposed on the page; a signup wall killing the loop |
| 4 | Proposal status — open · discussing · closed · finalised, honoured by every existing link | calls continuing after the match is fixed |
| 5 | Deliberate sharing — rich WhatsApp preview, QR, and a create-CTA at the right moment | distribution |
⚠ Capability 3 carries the sharpest principle in the source material:
"Don't authenticate curiosity. Authenticate intent."
That is the same rule CLAUDE.md already enforces for the vendor card, where a signup wall in front of a scanned card is called a defect, not a design choice.
Progressive disclosure — the core mechanic
| Tier | Visible to | Contains |
|---|---|---|
| Open | anyone with the link | first name, age, city, education, profession, one photograph |
| Requested | recipient asks, creator approves | full name, family details, more photographs, community details |
| Private | never public | exact date of birth, contact number, income, address |
The point is not that everything is hidden. It is that the creator sets the boundary and can move it per recipient, which is precisely the control a forwarded file destroys.
Photo protection is part of capability 2, not a later hardening pass. Open-tier photographs are served as a small cropped variant (MEDIA_VARIANTS already models this), full resolution is released only on approval, media URLs are short-lived and signed, and shared photographs carry a per-viewer watermark. Screenshot prevention is impossible on mobile web, which is the recipient surface, so the control is resolution gating plus attribution rather than prevention. See Privacy and security.
⚠ Default to closed. The free tier's default disclosure is a safety decision, not a packaging decision — see Privacy and security.
Deferred, deliberately
Family mode and shared review · proposal inbox · request-more-information · one-time family links · compatibility snapshot · profile-health scoring · AI-assisted writing · AI photo selection · video and voice introductions · full meeting coordination · multi-language profile content (as distinct from UI).
Three deserve a note now rather than later:
- Meeting availability was one of the original seven problems, and the five-capability MVP does not close it. A single "preferred times for a call or visit" field is far cheaper than a scheduling system and would close it without pulling calendar coordination into scope. Recommend including this one.
- AI-assisted writing must never invent personal facts. An embellished biodata is a misrepresentation risk where families make decisions on it. Draft-and-approve only, never silent generation. It is also a data-processing decision with a named processor and a retention rule.
- Family mode is a consent problem before it is a convenience. See Privacy and security.
The retirement experience is a feature, not an error page
A closed proposal must not 404. It should state that the proposal is closed, thank the viewer, and offer them the option to create their own.
This is the one moment where a create-CTA reaches a viewer whose intent is unambiguous, and per Growth it is one of the few places the CTA meets a genuinely creator-eligible person rather than a relative. It converts the product's success state into its best acquisition surface.
One-per-account
The owner's rule: one QRSETU account may hold one active Marriage Biodata.
⚠ There is precedent for this shape in the schema already — setu_cards.workspace_id is not null unique, i.e. exactly one card per owner, enforced by a column constraint rather than by application logic. The same pattern applies cleanly here. Detail and the owner-versus-subject model are in Architecture.