Introducing GENRECORD: An Open Standard for Sharing Genealogical Source Records

Somewhere in a filing cabinet, on a volunteer’s laptop, or buried in a society’s proprietary database, there is a transcription of every headstone in a county cemetery. Someone spent hours walking those rows, brushing lichen off sandstone markers, squinting at half-legible dates, and typing it all into a spreadsheet.

That data exists. It is accurate. It is valuable. And almost no one outside that society can find it, use it, or build on it.

This is the problem GENRECORD is designed to solve.

What Is GENRECORD?

GENRECORD (GENealogical RECORDs) is an open, plain-text file format for packaging and sharing genealogical source records between societies, archives, and software.

A single .genrecord file carries two things: the metadata (what the collection is, where it came from, who created it, what license covers it) and the actual record data — names, dates, places, fields. Together in one file. Self-describing. Portable. Openable in any text editor on any computer made in the last forty years.

It is not GEDCOM. GEDCOM is for family trees — individuals, families, relationships. GENRECORD is for source records — transcriptions, indexes, abstracts. The two are complementary, not competing. A researcher might use GEDCOM to store their family tree and GENRECORD to share the cemetery transcription that proves a relationship.

The Problem It Solves

Genealogical societies do extraordinary work. Cemetery walks. Marriage index projects. Obituary abstracts. Census extractions. Bible record transcriptions. The accumulated labor of thousands of volunteers over decades represents an irreplaceable body of primary source material.

But that data is trapped.

It lives in proprietary platforms that may not exist in ten years. It lives in static HTML pages that search engines cannot index properly. It lives in spreadsheets emailed between officers when a membership chair retires. It lives in formats that no two societies use the same way, making aggregation nearly impossible.

There is no standard. So there is no interoperability. So there is no network effect. Every society is an island.

GENRECORD is a bridge.

What It Looks Like

A GENRECORD file is plain text. Here is a cemetery transcription:

##GENRECORD 1.0
#version: 1.0
#type: CEM
#title: Bexar County Cemetery Transcriptions
#society: San Antonio Genealogical and Historical Society
#society_url: https://txsaghs.org
#created: 2026-03-29
#license: CC0
#coverage.place: Bexar County, Texas, USA
#coverage.dates: 1850-1975
---
record_id,surname,given,gender,birth_date,death_date,cemetery,cemetery_place,section,lot,condition,notes
1,Stricklin,Walter Davis,M,20 Apr 1892,14 Mar 1962,City Cemetery,San Antonio TX,A,14,Legible,
2,,,,,1901,City Cemetery,San Antonio TX,,,Illegible,Stone heavily weathered

That is the entire format. A structured header block. A separator line. A column definition row. Data rows.

Notice row 2. No name. No birth date. An illegible marker from 1901. That row is valid GENRECORD. The format does not demand complete data — it demands honest data. A transcriber working from a damaged stone should not be blocked by a format that requires fields they cannot read.

The Design Principles

Plain text. Every decision in GENRECORD flows from this. Plain text is permanent. Plain text is free. Plain text works everywhere. A .genrecordfile opened in 2075 will look exactly like it looks today.

Self-describing. The header carries everything a consumer needs to understand the file before reading a single data row. Type, title, society, license, geographic scope, date range. No external manifest required.

One type per file. A cemetery file contains cemetery records. A marriage file contains marriage records. No ambiguity about what you are looking at.

Minimal required fields. Only record_id is universally required across all record types. Some types require one additional field where it is definitional — a census record requirescensus_year, for example. Everything else is recommended or optional. Volunteers should not fight the format.

CC0 public domain. No owner. No gatekeeper. No license fees. No permission required. Ever.

The Record Type Taxonomy

GENRECORD 1.0 defines 35 record types across seven categories:

Vital: Birth, Death, Burial, Cemetery, Marriage, Divorce

Legal: Census, Naturalization, Probate, Land/Deed, Court, Prison, Tax, Voter Registration, Immigration, Emigration

Military: Military records

Religious: Baptism, Confirmation, Congregation membership, Clergy/ordination, LDS proxy ordinance, Excommunication, Bar/Bat Mitzvah, Religious initiation

Education: School enrollment, College degree, Vocational certification, Teacher records

Newspaper: Obituary, Marriage announcement, Birth announcement

Compiled: Biography abstract, Family bible record, Funeral home record

Each type has a defined field schema — required fields, recommended fields, optional fields — documented in the full specification. Producers can add custom fields at any time using the x_ prefix convention.

For Developers

The format is designed to be trivially parseable. Split on the --- separator. Parse the header as key-value pairs. Parse the data block as CSV. Done. A functional GENRECORD parser can be written in any language in under fifty lines of code.

The field schemas are defined but not enforced at the format level — GENRECORD is a standard, not a validator. Validation tools are a natural next step for the community to build.

The full specification — including all 35 field schemas, controlled vocabularies, date and place conventions, file-naming conventions, and sample files — is available via the links below.

An Invitation

GENRECORD is not finished. It is a working draft published to start a conversation.

The religious record types for non-Christian traditions are explicitly marked as stubs, awaiting input from practitioners familiar with those traditions. There are certainly record types missing from the taxonomy. There are field definitions that will need refinement when someone tries to apply them to records I have never seen.

That is the point. A standard grows through use.

If you maintain a genealogical society’s records, this is for you. If you build genealogy software, this is for you. If you have ever wished you could pull a cemetery index from one society’s website into another society’s database without writing a custom import script, this is for you.

Read the specification. Try it on a real dataset. Tell me what is wrong.

How to Help

GENRECORD needs people more than it needs code right now.

If you run a genealogical society: Take one of your existing datasets — a cemetery index, a marriage register, a census extract — and try converting it to GENRECORD format. What fields are missing? What does not fit? That feedback is worth more than anything a developer can produce in isolation.

If you are a developer: Write a parser. Write a validator. Write an importer for Ancestry, FamilySearch, or your platform of choice. The format is simple enough that a working parser can be built in an afternoon. Submit it to the repository, and it becomes part of the ecosystem.

If you work with Jewish, Islamic, Sikh, or other non-Christian genealogical records, the BARMIT and INITIAT record types are stubs. They exist as placeholders because I do not know those records well enough to define them properly. You do. Open an issue on GitHub or reach out directly.

If you are an archivist or librarian: Tell me where GENRECORD fits — or conflicts — with EAD, Dublin Core, OAI-PMH, and the standards you already use. I would rather know now than after adoption.

If you just want to follow along, watch the repository on GitHub. Share this article with anyone who works in genealogy software or society administration. The standard lives or dies by whether the right people know it exists.

Specification and repository: github.com/GENRECORD/genrecord

Project home: genrecord.org

Charles W. Stricklin is Education Committee Chair at the San Antonio Genealogical and Historical Society and the developer of SocietyPress, an open-source membership management platform for genealogical and historical societies (still under development)