Record verification – stop believing every certificate...

---

Tamil Ancestry Research | Family Tree Guide

---

In this article:

1. What “record verification” actually means (not what families pretend it means)
2. The brutal truth: official documents contradict each other all the time
3. Ranking evidence: which records usually win, and when they don’t
4. Conflict handling: dates, names, places that don’t line up
5. How to tag confidence and sources properly in TamizhConnect
6. When to trust memory over paper (and when to ignore both)
7. A practical verification workflow for one messy person profile

---

1. What “record verification” actually means (not what families pretend it means)

Most families do zero verification. They just:

• grab whichever document looks fancy,
• assume it’s correct,
• and overwrite everything else with it.

Real record verification is:

For each claim (name, date, place, relationship), you ask:
“What evidence do we have, how strong is it, and do other sources support or contradict it?”

Key points:

• Verification is per fact, not “this document is true / false”.
• A record can be strong for one field and garbage for others.
• Verification is an ongoing process; you refine as new evidence appears.

If you’re not doing this, you’re not building history. You’re just collecting stationery.

---

2. The brutal truth: official documents contradict each other all the time

Here’s what you already know but don’t want to admit:

• Birth certificate says 1952-04-10,
• School record says born 1954,
• Passport DOB is 1955-01-01 (for age/eligibility/comedy reasons),
• Voter list age in 1995 implies 1950-ish,
• Grandmother says “He was born around harvest time, year after big flood” – which doesn’t match any of those dates exactly.

Same for:

• Names:
  • R. Muthusamy, Muthu Samy, Muthuswamy, M. Ramasamy, all for the same person.
• Places:
  • Birthplace: Trichy vs Lalgudi vs vague “near Trichy”.
• Relationships:
  • One record lists an uncle as father for convenience, or vice versa.

If you blindly “fix” everything to match one document (often the newest or flashiest), you:

• lose the trail of how and why the data shifted,
• and make it impossible to check anything later.

Verification means you accept that conflict is normal and build a system around it.

---

3. Ranking evidence: which records usually win, and when they don’t

There is no perfect hierarchy, but some general rules work most of the time.

3.1. For date of birth

Rough priority (strongest → weakest), with caveats:

1. Birth / baptism / early hospital record
   • Created closest to the event.
   • Usually the least “strategic” (no exam or job at stake yet).
2. School admission register (earliest one)
   • Often parents’ convenient lie, but at least consistent across schooling.
3. Government ID created early (old NIC, ration card, etc.)
   • Can still be fudged, but harder to change later.
4. Passport, license, later IDs
   • Frequently adjusted for age, eligibility, or convenience.
5. Voter lists (ages)
   • Barely more than guesses sometimes; good for approximate year only.
6. Oral memory
   • Great for festivals/season/year, terrible for exact dates after decades.

Rule:

• If birth cert and school record clash:
  • treat birth cert + early medical/naming record as primary,
  • school date becomes a used-for-education artefact.
• If no birth cert exists, you’re stuck with approximate ranges:
  • settle on a year range instead of a fake exact day.

3.2. For names

Priority depends on context:

• Legal / identity name:
  • passport, national ID, school certificates, degree certificates.
• Everyday / family name:
  • how the person signed, how they introduced themselves, what appears in letters.
• Traditional / birth name:
  • naming ceremony record, early temple/church entry.

TamizhConnect should allow:

• multiple verified variants,
• with different roles:
  • "legal", "everyday", "traditional", "nickname".

No single document gets to define someone’s name forever.

3.3. For places

Birthplace conflict example:

• Hospital record: city hospital.
• Family: “birthplace is the ooru village near that city”.
• ID: just city name.

Solution:

• record actual event place (hospital) in a precise field,
• record “native place” separately,
• don’t merge them into one mythical location.

---

4. Conflict handling: dates, names, places that don’t line up

You can’t magically “solve” every conflict. You can, however, stop hiding them.

4.1. For dates: store ranges and alternate candidates

If you have:

• Age 30 in 1980 (death cert) → ~1950
• School record: DOB 1949-06-15
• Passport: 1950-01-01

Don’t be an idiot and pick your favourite.

In TamizhConnect:

• birthDateCandidates:
  • 1949-06-15 (source: school, conf: medium)
  • 1950-01-01 (source: passport, conf: low)
• birthYearRange: 1949–1951 (derived, conf: medium)

Canonical display:

• show something like c. 1950 with a note:
  • “Exact date contested; see sources”.

4.2. For names: keep original spellings + normalized forms

Never throw away the spelling as written.

Store per person:

• nameAsWritten[]:
  • "R. MUTUSAMI" (SSLC cert, 1974)
  • "R. MUTHUSAMY" (Aadhaar)
  • "Muthusamy R" (passport)
• nameNormalized: "R. Muthusamy" (your chosen standard form)

If someone later finds a new record with Muthuswamy, you can still match it.

4.3. For places: separate event place and origin/native place

Example:

• birthPlace: "Govt Hospital, Trichy"
• nativeVillage: "Village X, Lalgudi taluk, Trichy district"
• currentAddressHistory[]: e-roll and ration card addresses.

When relatives say “He is from Lalgudi”, they usually mean nativeVillage, not birth hospital.

4.4. For relationships: don’t overrule unless you’re sure

Sometimes you’ll see:

• “Father’s name” on a certificate that doesn’t match known father (uncle standing in, adoption, second marriage drama, etc.).

Don’t instantly “correct” the tree.

Instead:

• record exactly what the document says:
  • “Certificate lists father as Y; family insists biological father is X; reason: adoption / step-father / convenience.”
• attach both as linked roles in the person profile:
  • bioFather, legalGuardian, stepFather, etc.

Truth is often messy. Your data model has to handle that.

---

5. How to tag confidence and sources properly in TamizhConnect

If you’re not tracking where something came from and how sure you are, you’re building on fog.

5.1. Every fact needs:

For each claim (e.g., “Born 1952-04-10 in Village X”), store:

• factType: "birth", "marriage", "death", "residence", etc.
• value (date, place, relationship, name, etc.)
• sourceId[]: all documents and testimonies that support this fact
• confidence: "high" | "medium" | "low"
• lastReviewedBy and lastReviewedDate (if you’re disciplined)

Short rules:

• High:
  • multiple independent sources agree,
  • or one extremely strong source (e.g., official birth record + consistent school record).
• Medium:
  • plausible, but conflict or guesswork involved.
• Low:
  • one weak or unclear source, or big contradictions unresolved.

5.2. Store per-source statements, not just “this doc proves everything”

For each source:

• list specific statements you’re extracting:
  • “This cert shows his DOB as 1952-04-10.”
  • “This voter list shows him living at address Y in 1995.”
• tie each statement to one or more facts.

This way, you can later say:

• “We believed X because of sources A, B, C. Source D contradicts it; we downgraded confidence.”

5.3. Don’t overwrite; version

When you change your mind:

• do not erase old values silently;
• instead:
  • keep previous value as supersededFact or oldCandidate;
  • add a note:
    • “Replaced by new evidence from death cert / school record / court file.”

If someone asks “Why did DOB change?”, you can answer.

---

6. When to trust memory over paper (and when to ignore both)

Paper is not automatically superior to memory. Both can be wrong.

6.1. Trust memory when:

• elders are very specific about:
  • a festival, season, historical event tied to a birth/marriage/death,
  • and documents clearly show bureaucratic “adjustments” (e.g., school lowering age for exam).

Example:

• Thatha says, “He was born the Deepavali night when the big flood cut off the bridge, one year before Independence.”
• School record says DOB 1947-01-01 (lazy default).

You can:

• treat the year as solid (1946 or 1947),
• mark the exact day as uncertain,
• note both the oral story and the fake school date.

6.2. Ignore memory when:

• it contradicts multiple independent documents without any plausible explanation.
  • e.g., “He never left the village” vs passport, visas and 20 years of e-rolls in Gulf/Chennai.
• it’s obviously pride/shame-driven:
  • shaving years off for marriage,
  • pretending someone wasn’t from a particular caste/ooru,
  • denying a relationship (step child, adopted child) that’s documented everywhere.

In TamizhConnect:

• store the memory as oral source with low confidence:
  • “Family claims X; evidence suggests Y; reason for conflict appears to be shame/pride/legal issue.”

6.3. Ignore both when:

• you have no relevant documents,
• and memory is confused or contradictory across relatives.

Then your honest answer is:

• unknown or approxRange,
• plus a note:
  • “Multiple conflicting memories; no surviving documents; leaving this unresolved.”

Better to admit ignorance than invent a fake precision.

---

7. A practical verification workflow for one messy person profile

Enough theory. Here’s how you verify one person’s record properly.

Step 1 – Collect all sources touching this person

List:

• birth/baptism certs,
• school records,
• ID cards (NIC/Aadhaar/driver’s license),
• passport/visa,
• e-roll entries,
• patta/land documents,
• temple records,
• oral interviews.

No judgement yet. Just collect.

Step 2 – For each source, write down only explicit statements

Example for a school record:

• “Name: R. MUTHUSAMY”
• “DOB: 1950-06-10”
• “Father’s name: Ramasamy”
• “Village: X”

For an e-roll:

• “Name: R MUTHUSAMI”
• “Relation name: Ramasamy”
• “Age: 45 in 1995”
• “Address: house 12A, Village X”

Don’t read extra meaning into it. Just write what’s actually there.

Step 3 – Group facts by type and compare

Group:

• All DOB statements together.
• All father-name statements.
• All place-of-birth/residence statements.
• All name variants.

See where they agree and where they don’t.

Step 4 – Assign provisional “winner” and confidence

For each fact type:

• Choose a canonical working value (DOB, name, place) based on:
  • proximity to event,
  • number of sources,
  • nature of each document.
• Assign confidence.

Example:

• Birth:
  • Working DOB: 1950-06-10 (from early school record)
  • Range: 1949–1951 (considering e-roll age)
  • Confidence: "medium"
• Father’s name:
  • Working: "Ramasamy"
  • Confidence: "high" (consistent across all docs).

Step 5 – Record conflicts, don’t hide them

For each disagreement:

• store alternative candidates with lower confidence:
  • birthDateCandidates includes both 1950-06-10 and 1951-01-01 (passport).
• add notes:
  • “Passport date likely chosen for convenience; conflicts with earlier record.”

Step 6 – Update the TamizhConnect profile with linked evidence

In the person profile:

• set working values (canonical name, approx DOB, places),
• attach fact objects with:
  • source links,
  • confidence,
  • notes.

Now anyone (including future you) can see:

• what’s known,
• what’s shaky,
• where the claims came from.

Step 7 – Revisit when new evidence appears

Later, if someone finds:

• a proper birth certificate,
• a church/temple record,
• a court document,

you:

• add a new fact from the new source,
• re-rank evidence,
• possibly change the working DOB,
• leave the previous hypothesis visible as superseded.

No drama. Just versioning.

---

If you treat record verification as a box-tick (“we have certificates, therefore everything is true”), your genealogy will be fragile garbage: one new document and half the story collapses.

If you:

• admit that documents conflict,
• rank evidence instead of worshipping it,
• keep original spellings and alternate dates,
• and tag confidence honestly,

TamizhConnect becomes what it should be:

a living, self-correcting model of your family’s past – rooted in evidence, open about uncertainty, and strong enough to survive new discoveries instead of falling apart every time reality disagrees with an old myth.

For more information about managing name variants, see our guide on handling multiple name variants. To learn about collecting family history from elders, read our guide on collecting family history.