Rootfable Extensions for FamilySearch GEDCOM 7

Version 1 · Stable · Last updated: September 19, 2026 · Canonical URI: https://rootfable.app/spec/v1

This document defines the extension tags Rootfable writes into FamilySearch GEDCOM 7 files, and the archive layout those files are distributed in. It is published so that any program — not only ours — can read a Rootfable archive completely, and so that a file we wrote today is still legible when nobody is left to ask.

This specification is released into the public domain (CC0 1.0). Implement it, fork it, or absorb it into a future version of GEDCOM without asking us.

1. Scope and conformance

A Rootfable export is a conformant GEDCOM 7.0 file. Everything here is additive: the people, families, dates, places, notes and media links are standard structures that any GEDCOM 7 reader already understands. The extensions below carry only the facts baseline GEDCOM has no tag for.

GEDCOM 7 requires that a reader ignore extension structures it does not recognise, so a program with no knowledge of this document loses nothing but the extension payloads themselves. Every extension tag used in a file is declared in the header's SCHMA structure with the URI that identifies it — the tag spelling is a local nickname, the URI is the identity:

0 HEAD
1 GEDC
2 VERS 7.0
1 SOUR ROOTFABLE
2 NAME Rootfable
1 SCHMA
2 TAG _RF_AUTHOR https://rootfable.app/spec/v1#author
2 TAG _RF_DATE https://rootfable.app/spec/v1#date
2 TAG _RF_PROMPT https://rootfable.app/spec/v1#prompt
2 TAG _RF_TRANSCRIPT https://rootfable.app/spec/v1#transcript
2 TAG _WT https://rootfable.app/spec/v1#wikitree

A reader should match on the URI, not on the underscore spelling. A file that relabels _RF_AUTHOR to _CONTRIB while keeping the same URI means exactly the same thing.

2. Archive layout

Rootfable distributes a family as a single ZIP following the GEDZIP convention from GEDCOM 7:

family-archive.zip
├── gedcom.ged      the tree, GEDCOM 7.0, UTF-8
├── README.txt      plain-language explanation of the above
└── media/          every photo, document and video clip
    ├── I1-photo-1.jpg
    ├── I1-document-2.pdf
    ├── I4-clip-3.mp4
    └── I4-poster-4.jpg

Each media file is a top-level OBJE record whose FILE payload is the archive-relative path, with a FORM giving its media type. Paths are stored, never compressed, so a damaged archive can still be carved by hand. Media filenames encode the individual's xref and the media's role for human legibility only — the OBJE records are authoritative.

If a media file could not be retrieved when the archive was built, its OBJE record is still present and the missing path is listed in README.txt. A gap is recorded, never silently dropped.

3. Extension tags

_RF_AUTHOR

The family member who contributed the structure this appears under: the person who told the story, uploaded the photo, or recorded the clip. This is contribution provenance, not authorship of the underlying historical record, and not a SOUR citation — the person named here is typically alive and is the reason the material exists in the tree at all.

URI: https://rootfable.app/spec/v1#author
Payload: Text — a display name as entered.
Appears under: NOTE (a story), OBJE (a photo, document or clip).
Cardinality: {0:1}

1 NOTE Grandpa kept the ration book in his coat until 1961.
2 _RF_AUTHOR Mary Hamilton
2 _RF_DATE 2026-03-04

_RF_DATE

When the contribution was made — the moment the story was written down or the file uploaded. Distinct from the standard DATE of the event itself: a 1943 photograph added to the tree in 2026 has an event date of 1943 and an _RF_DATE of 2026.

URI: https://rootfable.app/spec/v1#date
Payload: Text — an ISO 8601 date or date-time. Not a GEDCOM DATE value; it needs no calendar escape and no approximation qualifiers.
Appears under: The same structures as _RF_AUTHOR (NOTE, OBJE), as its sibling at the same level — not nested beneath it.
Cardinality: {0:1}

_RF_PROMPT

The question a person was answering on camera. Rootfable can invite a member to record a short video reply to a prompt — “What do you want your great-grandchildren to know about you?” — and the answer is meaningless without the question. Preserving the prompt is what keeps a two-minute clip from becoming an orphaned monologue.

URI: https://rootfable.app/spec/v1#prompt
Payload: Text. May span lines via CONT.
Appears under: OBJE records whose media is a video clip.
Cardinality: {0:1}

_RF_TRANSCRIPT

The spoken words of a video clip, as text. Machine-generated and then corrected by a human, or typed from scratch. This is the part of a recording that survives format rot: codecs die, plain text does not.

URI: https://rootfable.app/spec/v1#transcript
Payload: Text. Line breaks are meaningful and are carried as CONT.
Appears under: OBJE records whose media is a video clip.
Cardinality: {0:1}

Rootfable also writes the transcript a second time as an ordinary NOTE prefixed Transcript:, so that a reader with no knowledge of this specification still shows a family the words. The duplication is deliberate. A reader that understands _RF_TRANSCRIPT should prefer it and may suppress the matching NOTE.

0 @O3@ OBJE
1 FILE media/I4-clip-3.mp4
2 FORM video/mp4
2 TITL Video clip, recorded 2026
1 _RF_PROMPT What do you want your great-grandchildren to know about you?
1 _RF_TRANSCRIPT I was born in the back bedroom of a house that isn't there
2 CONT anymore. My mother used to say...
1 NOTE Transcript: I was born in the back bedroom of a house that isn't there
2 CONT anymore. My mother used to say...
1 _RF_AUTHOR James Hamilton
1 _RF_DATE 2026-05-11

_WT

The individual's profile identifier on WikiTree, the collaborative single-tree genealogy project — the same person, as the wider world has catalogued them.

This tag is spelled without the _RF_ prefix the others carry, because it predates them: Rootfable's earlier exporter wrote _WT and its importer reads it, and files carrying it are already in people's hands. Renaming it for the sake of consistency would strand them, which is the exact failure this specification exists to prevent.

URI: https://rootfable.app/spec/v1#wikitree
Payload: Text — a WikiTree ID, e.g. Hamilton-3841. Resolves as https://www.wikitree.com/wiki/<id>.
Appears under: INDI.
Cardinality: {0:1}

The same identifier is also written as a standard GEDCOM 7 EXID, which is the baseline structure for “this record is also that record elsewhere”. A reader that knows nothing of this page still gets the link; the extension exists only so our own round-trip is exact. Prefer the EXID; the two always agree.

0 @I4@ INDI
1 NAME James /Hamilton/
1 EXID Hamilton-3841
2 TYPE https://www.wikitree.com/
1 _WT Hamilton-3841

4. Stability and versioning

Version 1 is stable. Within it, changes are additive only: new tags may be defined, but an existing tag's URI, payload type or meaning will not change, and no tag will be removed. A reader written against this page today will keep reading Rootfable archives correctly.

If a change were ever needed that breaks that promise, it would be published at a new URI (/spec/v2) and this page would remain in place, unchanged, for the files that already point at it. Dead links are how archives rot; we would rather host a page forever than break one.

5. Relationship to the GEDCOM standard

We did not invent a format. GEDCOM 7 is stewarded by FamilySearch, developed in the open at github.com/FamilySearch/GEDCOM, and it already solved the hard parts: a documented data model, real Unicode, media bundling, and — critically — a designed extension mechanism, which is the one this document uses.

Extensions defined this way are meant to be discoverable, and gedcom.io maintains public registries of extension tags and media types for that purpose. We intend to register the tags defined here and to mirror this document in a public repository so the definitions outlive our hosting.

If something here turns out to be generally useful — provenance for crowd-contributed material, prompts and transcripts for recorded testimony — the right home for it is the standard itself, proposed as an issue or pull request against the FamilySearch repository, not a private dialect. That is the outcome we would prefer.

6. Comments

Corrections, implementation questions, and requests for tags this does not yet cover: Edge Case Studios — edgecasestudios.ai.