Lama Karki Bansha - Family, Governance & Platform Master Guide
One living guide for family rules, genealogy, Community, Messenger, Family Tree, Life & Legacy, committees, Central governance, privacy, help and every main member-facing workflow.
Private family records and Community content must not be copied, recorded, photographed, scraped, reproduced, forwarded or shared outside authorised family use without explicit permission.
FIND A TOPIC QUICKLY
Go straight to the exact topic
Choose the topic below for public-tree privacy, Research Tree, newborn identity, access recovery or the physical Family ID Card.
1. Read this first - one guide for the whole platform
Lama Karki Bansha is a family-history, genealogy, governance and closed family-community platform. This Master Guide replaces the separate public Family Guide, member handbook and committee roadmap as the main member-facing reference.
The guide explains what each section is for, who may use it, how records are protected, how family trees are formed and changed, and how local and Central committees work.
Not every member sees every menu. The verified tree structure is public read-only, while richer profiles, Community, Committee, research and editing tools depend on verified identity, family relationship, invitation, committee role and exact work-area permission.
Never guess a name, date, relationship or historical fact. If something is not known, keep it Unknown / Researching until evidence and family review can support it.
Private family records and Community content must not be copied, recorded, photographed, scraped, reproduced, forwarded or shared outside authorised family use without explicit permission.
The Public Website explains the project, rules, privacy, help routes and fictional Demo Tree. The Original Verified Family Tree is also open for anyone to browse in read-only mode, but the public person view is limited to name, permitted profile photo and broad location only.
A separately labelled temporary Research Tree may be published so elders and relatives can inspect provisional family research. It can be rebuilt, retired or deleted, never issues a permanent Family ID, and never becomes verified genealogy automatically.
The Community remains the closed family social area for posts, photos, events, comments, connections and family communication. Community membership and genealogy edit authority remain separate.
The Committee Room is the governance workspace for one Tree Committee. It holds meetings, minutes, resolutions, research cases, evidence, tasks, recovery reviews and Central communications.
Tree Control and Central governance tools are limited workspaces for authorised managers, committee officers, Central representatives and Central Executive officeholders.
Anyone may browse the public read-only structure of an Original Verified Family Tree. A Lama Karki family member becomes a verified member only after identity and lineage verification, which unlocks the normal protected family profile layer.
A spouse, daughter-side descendant or other recognised family-connected relative may join the Community under the family rules, but Community membership does not automatically grant verified-member profile details or genealogy editing authority.
Approved elders, historians, researchers or project contributors may receive a limited special role where their work supports the family record.
An unrelated member of the public, a false identity, a false family claim, or a person seeking family data for outside use may be refused or kept pending.
Children can be represented in genealogy, while account and Community participation follow the rules appropriate to age and guardianship.
4. Roles, permissions and responsibility boundaries
A normal Community member can use only approved Community functions and cannot edit verified genealogy.
A verified Tree member can browse public verified structures like any visitor and receives the richer member-profile layer only for genealogy scopes where their identity/lineage membership is approved.
A Tree Committee member receives governance responsibilities for that exact tree; a committee role does not create unlimited system power.
A Tree manager/steward may receive controlled tools for reviews, roles or data work, but cannot silently rewrite verified family history.
Each verified Tree Committee may appoint one authorised Central representative. Ordinary Central representatives do not automatically receive Central Executive management powers.
One person may hold more than one role, but every action is checked against the role, tree scope and current verification state.
The Home page is the public starting point. It explains the purpose of the project, privacy model and how family branches can begin with verified information available today.
Family Tree opens the Original Verified Family Tree for public read-only exploration. Public visitors see only minimal person details; verified members see the normal family profile according to permission. Use the fictional Demo Tree to learn navigation and a published Research Tree to inspect provisional research; Research Trees remain temporary, removable and without permanent Family IDs.
Use Community for family social activity, Alerts for notifications/reviews, Messenger for private communication, and the Family menu for Committee, life events, verification, Family Card, Guide and Contact.
The Master Guide is the single current member-facing reference. Read the live website version because it is updated when rules or platform functions change.
7. Community - posts, media, comments and family feed
Community is a closed family social space, not the genealogy database and not a public social network.
Use the composer to share genuine family updates, photos, videos, audio, events and notices within the permissions shown.
Like, Comment and internal Share can be used where enabled. Internal Share is not permission to publish the post on public Facebook, WhatsApp or another outside service.
Use visibility controls such as Community or Connections when the screen offers them.
Use report/moderation controls for harassment, impersonation, doubtful content or misuse of family information.
9. Messenger - direct messages, groups, voice and video
Profile / Header→
Message request or accepted connection→
Conversation / Group→
Optional voice/video call
Open Messenger from the header shortcut or an allowed Community profile.
If you are not yet connected, the first direct message may arrive as a Message Request. Normal two-way conversation begins only after the receiving member accepts when required.
Group conversations should include accepted connections or authorised participants only. Choose a clear group name and purpose.
Text, photos, voice/audio and other allowed attachments can be sent inside the protected messaging area. Do not send government IDs, passwords or sensitive genealogy evidence through ordinary chat.
Audio/video calling depends on the connection, room permission, device support and the call controls shown by the platform.
Messenger is communication only: sending a message, joining a group or making a call never creates, changes or approves genealogy.
11. Verified Family Tree - public structure, protected profile details
The Original Verified Family Tree is official genealogy and may be browsed by anyone in read-only mode. Anonymous visitors never receive Add, Edit or Delete controls.
Public person view shows only name, a permitted profile photo and a safe broad location. In Nepal use village/town and district; abroad use city and country. Public visitors do not see birth year, full DOB, Family ID, phone, email, identity documents or precise home address.
A verified family member can browse the full verified tree and see the normal family profile, but DOB is reduced to birth year only. Full DOB remains behind an authorised permission layer; the exact automatic branch/relationship matrix must not be invented until formally locked.
A public Research Tree is a separate temporary workspace. It may contain real provisional research, but it never issues permanent Family IDs, can be removed, and never writes into the verified Family Tree automatically.
People at the same lineage depth share the same generation level. A later verified earlier ancestor can move every displayed generation while permanent Family IDs stay unchanged.
Use the tree search/control to navigate people inside a published verified tree. Public search results must stay within the same minimal public fields; richer search/profile fields require verified or authorised access.
Open a person card to focus the branch and then move to parents, spouse, children or Life & Legacy where permitted.
On smaller screens, use pan/drag, compact cards, generation controls or branch focus rather than trying to display the whole tree at once.
Use the Demo Tree first if you are unsure how tree navigation works. Demo data is fictional and isolated from real genealogy.
If the person you expect is missing, do not create a duplicate. Use the correct missing-person, join or research route.
13. Permanent Family ID and Family Card - overview
Permanent Family ID identifies the same genealogy person for life. It belongs to the person, not to an email address, device, card or generation number.
When a verified newborn is created, the system issues the permanent Family ID immediately after final birth verification. Where a parent has a linked active account, guardian management is recorded and the parent receives a notification containing the child’s Family ID and future claim guidance.
From age 16, the young person may start Claim My Existing Family Profile using the existing Family ID, exact DOB and a new personal contact route. This links access to the existing person; it must never create a duplicate genealogy person or second Family ID. At age 18 the account can become fully self-managed.
A physical Family ID card is optional, never mandatory. A verified person may request one for themselves and an active guardian may request one for a minor. Collection, post or authorised family-event handout may be offered. Losing or replacing the card never changes the permanent Family ID.
Government identity numbers, passwords, private phone/email, precise address and private genealogy are never printed on the card or exposed by the public QR verification result.
14. Life & Legacy - the person’s long-term family archive
Every recorded person may have a protected Life & Legacy page with portrait, relationships, biography, education, profession, service, achievements, migration/places, timeline, memories, photographs and source information where permitted.
Facts and memories should be distinguishable. A respectful memory does not automatically become a verified historical fact.
A spouse recorded as a person may have a complete Life & Legacy profile rather than appearing only as a name label.
Living people should confirm identity/relationship where practical. Deceased or historical people are verified through responsible evidence, family knowledge and committee review.
After a death is verified, the core historical profile is protected from ordinary editing. Inactivity alone never means a person is deceased.
Joining an existing Tree means linking your account to exactly one already-existing verified genealogy person record. The join process must not create you as a new person.
Use the recognised tree invitation, verification or family-help route and provide the lineage information needed to identify the correct existing person/branch.
Father, grandfather and great-grandfather details may help matching, but knowing those names does not authorise creation of a missing person.
Exactly one verified match can proceed to account linking. No match or multiple possible matches must stop for evidence/manual review.
When linked, the existing person and existing Family ID are reused; a second genealogy person or second Family ID must not be created.
Use the dedicated New Family Tree Application. A general Contact message and a generic Add Person screen do not create a new official tree.
The application begins with the Karki / कार्की eligibility gate, verified contact and identity verification. Government ID is private verification data.
Describe the research already collected: generations, approximate people, earliest supported ancestor, family places and evidence sources.
The current founding-readiness target is at least five researched generations where family history allows. Genuine historical limitations can be reviewed; nobody should invent missing generations.
Reviewers check whether the branch already belongs to an existing Tree. If it does, the correct result is connection to that branch rather than a duplicate new tree.
Passing application review does not create genealogy. It only allows the governance/committee process to continue.
17. Research readiness, evidence and the no-guessing rule
Research should record what is actually known today, including uncertainty and conflicting family memories.
Useful evidence can include written genealogy, family documents, photographs, death records, official records, inscriptions, named elder confirmations and other responsible sources.
Living people included in a founding or later genealogy case should confirm their identity/relationship where practical before final verification.
Deceased/historical people cannot confirm themselves, so evidence and committee review carry more weight.
Unknown is an acceptable value. It is safer to keep a field Unknown / Researching than to create a false certainty that future generations may trust.
After Central gives the committee-formation green signal, the applicant normally proposes 5-10 adults from the requested lineage. This creates governance capacity, not genealogy.
Every proposed committee member must be 18+, have an active account with verified contact, and be verified as belonging to the proposed lineage.
The local family chooses its own committee members and roles. Central verifies eligibility and process rather than selecting different local members.
Core roles can include Chairperson, Vice Chairperson, Secretary, Committee Admin, Genealogy & Research Officer, Verification Officer, Records Officer, Treasurer and Committee Member.
Once the required seats are verified, the Committee Room becomes active. The family tree still does not exist until separate Tree Activation is approved and executed.
Chairperson leads meetings, keeps the committee focused on its mandate and ensures important decisions are formally recorded.
Vice Chairperson supports the Chair and can act within the committee’s approved delegation when the Chair is unavailable.
Secretary manages agendas, minutes, notices, resolutions and the permanent meeting record.
Committee Admin manages the Committee Room workflow and access allowed by the role; this is not authority to rewrite genealogy.
Genealogy & Research Officer organises lineage research, evidence questions and unresolved historical cases.
Verification Officer checks identity/relationship/evidence steps assigned to the role and keeps verification separate from casual opinion.
Records Officer protects document quality, provenance, version history and archive discipline. Treasurer handles authorised financial records where the committee uses that role.
Committee Members participate in meetings, review evidence, vote on resolutions and represent the family responsibly.
20. Committee Room - meetings, minutes, resolutions and evidence
Each verified Tree Committee has its own private Committee Room for agendas, attendance, minutes, tasks, decisions, research, verification cases, reports and Central communication.
Important decisions should use a formal resolution with a permanent resolution ID and a clear record of what was decided and why.
Digital resolutions can be voted in-app where enabled. Signed/scanned physical meeting decisions can also be attached to the protected committee archive.
Genealogy decisions should link to the evidence or review case they authorise so future reviewers can understand the basis of the decision.
Visibility is role-based: committee-only, tree-member, Central or community-facing information must remain separated from sensitive evidence/private documents.
21. Central representation - one Tree, one authorised voice
Each verified Tree Committee may appoint one of its own verified committee members as its Central representative through a passed local resolution.
Central verifies eligibility and the appointment process; it does not substitute a different person for the family’s chosen nominee.
One verified Tree Committee equals one Central Council seat and one vote while its representative is active and eligible.
A Tree Committee may replace its representative through a new local resolution. Appointment history is preserved rather than overwritten.
The Central representative carries the tree’s authorised voice in Central governance but does not take over the local committee’s ordinary branch work.
The Central Council is formed from the active authorised representatives of verified Tree Committees.
The Central Executive is elected from eligible active Central representatives; ordinary Central representation and Executive office are different levels of responsibility.
The implemented election model uses representative-only nominations, nominee acceptance, one vote per active representative/tree, a two-thirds quorum and more than 50% of valid votes to win, with a top-two runoff when required.
Executive office terms are currently set to three years with a maximum of two consecutive terms in the same office.
Constitutional rules for notice windows, resignation, vacancy, suspension/removal for misconduct, appeals and exact removal thresholds must receive formal family/committee approval and must not be invented silently by software.
23. Official Tree Activation - when a real genealogy tree begins
Verified Committee Room→
Tree Activation resolution→
Central evidence + duplicate review→
Approved→
Final Activate→
Official Tree + founding ancestor
A verified Committee Room is still not a genealogy tree. The committee must first prepare the founding research and pass a dedicated Tree Activation resolution.
The activation request includes the passed resolution, founding lineage summary, evidence summary, researched generation count, approximate member count and the currently supported founding ancestor information.
Central review checks committee state, research readiness and strong possible-existing-root/duplicate matches. A strong match blocks activation until the identity or branch question is resolved.
Central approval alone still does not create the tree. A separate final activation action executes the approved decision and records exactly when and by whom the official tree was created.
Final activation creates the first verified tree, the current supported founding ancestor, the immutable Family ID, the Tree Control workspace and scoped roles for verified committee members. Repeating the action must not create a second tree.
24. Entering the founding family data after activation
After activation there is still no generic Add Person button for real genealogy. The first researched multi-generation family dataset must be entered through a controlled founding-lineage workflow.
The safe design is to stage the whole reviewed dataset first, validate people and relationships, detect possible duplicates, check cycles/conflicting parents and link every row to evidence/provenance before execution.
The Tree Committee must review the complete founding dataset and pass the required approval resolution; Central review may also be required for the first whole-tree execution.
Only final verified execution should create people, permanent Family IDs and relationships in one audited transaction. Partial failure must not leave half a family tree.
This controlled founding-entry workflow is the next build gate before real founding family data should be entered. Until it is ready, do not use another screen as a substitute.
Use Family → New Birth / In Memory and choose New Birth. A submission begins a protected review; it does not instantly add a verified person.
Complete fresh security verification when requested and choose the authorised verified tree. Identify the verified father and, where available, the recorded mother. Enter only confirmed baby details such as name, sex and full birth date.
Required close-family confirmations and committee approval occur while the case is pending.
Only final verification creates the genealogy person, issues the permanent Family ID, links the parent relationship and calculates the generation.
After verification, linked parent accounts become guardian managers where applicable and receive the child’s permanent Family ID. The child does not need an email/password at birth. From age 16 the child can claim the existing profile; from age 18 guardian account-management authority can end while the genealogy relationships remain unchanged.
Use the protected In Memory route and identify the existing family person. Do not create a second person just to record a death.
Enter the confirmed date of passing and an optional respectful note; provide the evidence or family confirmation required by the review process.
Account inactivity is never proof of death. The record remains living/status-unknown until the family process verifies the event.
After final verification, the person remains in genealogy and the core historical record is protected as In Memory. Death does not delete the person from family history.
27. Corrections, wrong ancestors, duplicates and missing people
Concern / correction→
Evidence→
Duplicate + relationship checks→
Committee/reviewer decision→
Audited correction / merge / research remains open
Wrong detail: submit a correction with evidence. The before/after value, reviewer decision and audit history must remain.
Wrong relationship or ancestor: open the protected lineage concern/research process. Do not drag or directly rewrite a verified tree.
A verified member may flag a suspected wrong ancestor within their own four verified father-line steps; wider structural concerns use the general research/committee route.
Possible duplicate: stop and compare identity, lineage, dates, places, parents/spouse/children and evidence. Names alone must never merge people.
Exceptional missing intermediate person: if a genuine missing father/brother/link cannot use the normal workflow, the Tree Committee/verification board must open a reason-specific evidence case.
Verified people are not normally deleted. Duplicate resolution uses controlled merge/reconciliation while preserving provenance and history.
28. Earlier ancestor extension and changing Generation 1
Adding an earlier/top ancestor is a special structural genealogy action, not an ordinary edit.
The case must identify the exact current verified attachment point and provide evidence for the proposed father/ancestor relationship.
After approval/execution, the newly verified earliest father-line ancestor becomes the current Generation 1 and descendant generation numbers recalculate automatically.
Permanent Family IDs, profiles, Life & Legacy content, photographs, memories, documents and audit history stay attached to the same people.
A proposed or unverified parent never renumbers the tree.
Separate Lama Karki branches may begin independently when their historical connection is not yet proven.
Later connection follows: possible connection → research → evidence → both affected Tree Committees review → Central review → duplicate/person verification → relationship approval → connect/merge → generation recalculation.
Names alone never justify a merge. A proven common ancestor and the exact relationship between the existing trees must be supported by evidence.
Original Tree IDs/provenance, old decisions, source history and permanent person IDs are preserved even after connection.
If evidence is incomplete or committees disagree, keep the trees separate and continue research rather than forcing a connection.
Tree Control appears only to accounts with tree-management authority; it is not a normal member menu.
Authorised tools may include Tree overview/status, join review, family knowledge/evidence cases, role management, status checks and controlled data operations.
Role changes and sensitive management actions are audited and should require fresh verification where the platform specifies it.
Inactivity/status checks must never automatically convert a living person to deceased.
Real genealogy import and founding data entry are controlled processes. A spreadsheet upload must never bypass duplicate checks, evidence review, committee approval or transaction safety.
31. Responsibility areas - Research, Verification, Records, Treasury and Central
Genealogy & Research work investigates lineage, sources, unresolved ancestors, tree connections and evidence quality.
Verification work checks identity, relationship and case-specific evidence without deciding from name similarity alone.
Records work protects document naming, provenance, version history, meeting records, archival quality and long-term retrievability.
Treasury work, where used, concerns authorised committee financial records and must remain separate from genealogy verification authority.
Central governance handles system-wide/cross-tree matters, Tree Activation review, authorised circulars and Central representative/executive processes. It does not replace ordinary local Tree Committee work.
32. Central circulars and organisation-wide notices
Authorised Central Executive officeholders may draft and publish organisation-wide circulars to verified Committee Rooms according to the governance permissions.
Each delivery is recorded so the organisation can know which Committee Room received the notice.
An active local committee member may acknowledge receipt for their Committee Room where enabled.
Delivery or acknowledgement is a communication/governance record, not permission for Central to take over the local committee’s normal daily work.
Ordinary Central representatives keep their representative/election role and do not automatically receive circular-management or Tree Activation management powers.
Family information is shown on a minimum-necessary basis. Public, verified-member and authorised-role views are separate layers, and the server must enforce those boundaries rather than merely hiding fields on screen.
Government identity documents, private evidence, exact residential addresses, phone numbers, email addresses, passwords, OTPs and login-security records are restricted information and must never be exposed simply because someone can browse genealogy.
For the exact public visibility rules of the Original Verified Family Tree, use Section 38. For the Temporary Research Tree and its separate privacy boundary, use Section 39.
Sensitive identity or evidence documents must use protected upload, approved verification or other controlled routes; do not post them in Community or send them through ordinary Messenger chat.
If information appears wrong, private or misused, use the appropriate correction, report, security or recovery route. Do not copy or redistribute protected family information outside its authorised purpose.
Use Contact/Help for account questions, Community help, Family Card requests, access problems, genealogy questions and other support. Choose the closest category so the request reaches the right team.
For a specific topic, go directly to the dedicated section: Public Verified Tree privacy - Section 38; Temporary Research Tree - Section 39; newborn and growing-up identity - Section 40; lost-access recovery - Section 41; physical Family Card - Section 42.
A serious lineage concern, wrong ancestor, disputed relationship or sensitive evidence issue should be raised through the protected concern/research route or private Family Record Team support, not through a public Community argument.
If the issue belongs to one family tree, the relevant Tree Committee or authorised records/research role should normally review it first. Central review is used only where the rules require escalation, a local conflict exists or the local committee cannot resolve the case.
When you are unsure which route applies, ask for help before creating another person, another tree or another account. The support process should guide you to the existing record whenever one already exists.
The same identity, privacy and genealogy-permission rules apply across the website, iPhone, Android and tablet. Changing device never creates extra rights.
On mobile, use the swipeable navigation and compact cards to reach Home, Tree, Community, Alerts and Family sections.
Large Tree views may use pan/drag, generation controls and branch focus on smaller screens.
Messenger and Alerts may deep-link to an exact private case only when your account is authorised for that case.
Push notifications require a registered device and enabled preference. Native privacy protections can vary by device and operating system.
37. Living document, revision history and staged-release note
This Master Guide is a living family document. When a member-facing rule, menu, workflow or governance decision changes, the website guide and archived master document should be updated together.
The live website guide is the current reading version. Printable PDF/DOCX copies are kept in the project Library for committee meetings, archives and controlled sharing, but the website does not need a public download button.
Some role-specific functions appear only after account, Tree, committee or Central permissions are active. If a menu described here is not visible, first check whether your role is eligible.
Controlled founding dataset and Temporary Public Research Tree foundations are implemented. Public verified-tree privacy, child identity/claim, account recovery and optional physical-card workflows are now in staged validation. The separate maternal-line automatic continuation rule remains intentionally unresolved.
Whenever governance is not yet formally approved, the platform should label it as pending rather than presenting a software default as a family decision.
38. Public Verified Family Tree - visibility and privacy
Anyone may browse the entire Original Verified Family Tree in read-only mode. Anonymous visitors never receive Add, Edit or Delete controls and cannot change verified genealogy.
The public person view shows only the person’s name, a profile photo that is approved for public display, and a safe broad location. In Nepal show village/town and district; outside Nepal show city and country.
The public view does not show birth year, full date of birth, permanent Family ID, phone, email, exact home/street address, government identity documents, private evidence, private notes or account-security information.
A verified family member can see the normal full family profile across the verified tree, but date of birth is shown as the birth year only. Full day/month/year is revealed only where a separate relationship-based or role-based authorisation permits it.
Public APIs must return only an explicit allow-list of safe fields. Public browsing does not create a public-edit right, bulk export right or genealogy ownership; correction suggestions use a separate controlled review route.
39. Temporary Research Tree - removable and without permanent Family ID
A Temporary Research Tree is a separate, clearly labelled UNVERIFIED family-research workspace. It is used while a family group checks names, relationships and evidence with elders and relatives before anything becomes official genealogy.
Its public read-only view follows the same minimal public boundary as the verified tree: name, permitted profile photo and safe broad location only. Birth year and extended profile details are not public.
Authorised researchers may add, correct, reorganise and review working people and relationships inside the Research Tree. Research people use temporary research identifiers only and never receive a permanent Family ID.
The Research Tree may be rebuilt, retired or deleted. Deleting it must never delete or alter an Original Verified Family Tree, verified person, permanent Family ID or independently approved evidence provenance.
When the family is confident, it submits the research for official verification. Duplicate, relationship, evidence and committee checks happen before approved people are matched to existing verified people or created in the Original Verified Tree. Permanent Family IDs are issued only through the verified process; the temporary Research Tree can then be archived or deleted.
40. Newborn registration, permanent Family ID and growing up
A verified parent or authorised guardian reports a newborn through the dedicated New Birth workflow. After the birth and relationship are verified, the child receives one permanent genealogy person record and one permanent Family ID for life.
The parent/guardian receives confirmation of the child’s permanent Family ID and may keep it safely for the child. The Family ID is an identity reference, not a password, and the newborn does not need an independent login account.
While the child is a minor, an approved guardian relationship controls the permitted profile-management actions. Guardian management never changes ownership of the child’s permanent genealogy identity.
From age 16, the young person may use Claim My Existing Family Profile. If the Family ID is known, the claim uses that ID, the exact date of birth, a new personal email/phone and the required identity checks. The process links access to the existing person; it must not create a duplicate genealogy person.
At age 18, the account can become fully self-managed and guardian account-management authority ends. If the person does not claim at 16 or 18, the genealogy record and Family ID remain safe and may be claimed later at any age through the approved identity process.
If the member still controls a verified email or phone, use normal self-service account recovery. If the old contact is lost but the permanent Family ID is known, use Family ID plus identity verification and a newly verified contact route.
If the Family ID, old email, phone and password are all lost, open a Full Identity Recovery Case. The purpose is to restore access to the same existing person and the same permanent Family ID, never to create a replacement identity.
High-risk recovery normally requires two independent approvals: the Verification Officer checks identity/relationship evidence and the Records Officer checks the existing person and historical record. A close relative may provide supporting confirmation but cannot restore the account alone.
A reviewer with a conflict of interest must recuse. Disputed identity, unresolved evidence, suspected fraud, lack of a functioning Tree Committee or a permitted appeal is escalated to Central/Security review according to the governance rules.
Approved full-loss recovery uses a security hold before final activation, verifies the new contact methods, revokes old sessions/credentials and records the decision in the audit history. The permanent person record, Family ID and genealogy position remain unchanged.
42. Optional physical Family ID Card - request, print and replacement
A physical Lama Karki Family ID Card is optional. The permanent Family ID exists whether or not a card is printed, and the card or QR must never function as a password or automatic login credential.
A verified adult may request their own physical card. An active authorised guardian may request a card for a minor they manage. Open Family Card, choose Request Physical Card, confirm the permitted card details and submit the request.
The Records Officer or another specifically authorised card administrator reviews the request before printing. Where the service is offered, the requester may choose an approved collection, postal or family-event handover method shown by the platform.
The physical card may show the person’s name, permanent Family ID, current generation where clear, card type and a safe verification QR. It must not print full DOB, government ID/passport/citizenship number, private phone/email, precise home address, private Tree ID or full genealogy.
If a card is lost, damaged or needs replacement, revoke or replace the card/QR record and issue another card through the controlled request process. The person’s permanent Family ID never changes. Any future fee or delivery charge must be shown only after an official policy is approved.
43. Founder's Message - why I am building Lama Karki Bansha
I began travelling abroad as a teenager to build a life, find good work and search for a better future. My journey took me through the Middle East, China, Hong Kong, Macau, Taiwan, Thailand and much of Europe. Today I live in Ireland with my family, but I still describe myself simply as a traveller - always searching for a better way.
Across countries and communities I saw the same problem: migration scatters families, elders pass away, old notebooks and photographs disappear, names and relationships become uncertain, and younger generations can lose the connection to their roots. I also met people trying to find relatives and lineage after those links had already become difficult to recover.
As a part-time developer I decided to build Lama Karki Bansha as more than a website or app. My intention is to create a long-term family record where responsibly verified information can remain understandable to our descendants even after a century, while future generations can continue recording their own story.
Trust is central to the project. I have tried to design the system so no single person can casually create, change or erase verified genealogy. Identity checks, evidence, committees, role boundaries, duplicate checks and audit history are there to make false or unsupported information difficult, visible and reviewable.
I ask every Lama Karki family, elder, relative, researcher, committee member and younger generation to help with truthful information, old records, photographs, family knowledge, respectful corrections and patient research. Every family can begin with the reliable information available today; as earlier ancestors and connections are verified, the record can grow without losing what was already preserved. My hope is that future Lama Karki generations can look back with pride and find their lineage clearly. - Sanjib Karki, Founder, Project Developer & Steward. "A traveller, always searching for a better way."
Use the verification route to join an existing Tree. If you have a completely new genuine branch, use the dedicated New Tree Application. If any genealogy detail is uncertain, do not guess - use Help/Contact or the protected research route.
