Events & facts

The events of a life — born, married, died — and the standing facts about a person — an occupation, a residence — are recorded as structures nested inside an individual or family record. These recipes go from the vital events to attributes, custom events, the detail you attach to any of them, and the 7.0-only way to say an event didn’t happen.

New to reading GEDCOM lines? Skim How GEDCOM works first — every recipe shows the underlying lines, but the app writes them for you as you type.

Record a birth

The structure. A birth is a BIRT event nested under the person, with a DATE and PLAC beneath it:

0 @I1@ INDI
1 NAME Jane /Smith/
1 BIRT
2 DATE 12 MAR 1832
2 PLAC Boston, Massachusetts, USA

The BIRT line carries no value of its own — the date and place that describe the birth nest one level deeper. The detail tags (DATE, PLAC, and the rest) come from a shared event-detail block, so you write them the same way under any event; see Add detail to any event.

In the app. With the person’s record open, add a line beneath the INDI and let autocomplete offer BIRT — it lists only the tags valid directly under a person. Add DATE and PLAC beneath it the same way; the date editor helps you enter a valid date, and autocomplete proposes place parts. To create the person and their birth family in one move, use Add relative first, then add the birth.

Across versions. BIRT is identical in 5.5, 5.5.1, and 7.0 — its place in the individual-event structure never changed. Two version details worth knowing:

In all three versions, BIRT may carry a bare Y value (1 BIRT Y) to assert the birth happened when you have no date or place to give. With a DATE or PLAC present you leave the value empty.
In 5.5 and 5.5.1, BIRT may also carry a FAMC pointer (the family the person was born into); 7.0 keeps FAMC on BIRT too. This links the event to the birth family, distinct from the person’s own FAMC link.

Validation notes. A DATE under a birth must parse as a GEDCOM date — the checker flags a date it can’t read (see Dates & places). BIRT appears at most once per person in practice, though the grammar doesn’t forbid repeats; a second birth usually means you want a custom event or an alternate-date note instead.

See also: Add detail to any event · Dates & places · Relationships.

Record a death, burial, and cremation

The structure. Death, burial, and cremation are three separate events. They commonly appear together:

0 @I1@ INDI
1 NAME Jane /Smith/
1 DEAT
2 DATE 4 NOV 1901
2 PLAC Boston, Massachusetts, USA
2 CAUS Pneumonia
1 BURI
2 DATE 7 NOV 1901
2 PLAC Mount Auburn Cemetery, Cambridge, Massachusetts, USA

For cremation, use CREM in place of (or alongside) BURI — same shape, same detail block. The cause of death goes in CAUS under the death event, not the burial.

In the app. Add DEAT, BURI, or CREM as lines beneath the person; autocomplete offers each. CAUS, DATE, PLAC, and AGE are all available beneath the event — they’re part of the shared event detail covered below.

Across versions. All three tags exist in 5.5, 5.5.1, and 7.0 and are written identically. The one real difference is the bare-Y assertion: in 5.5, DEAT, BURI, and CREM may all carry [Y|<NULL>], so 1 DEAT Y (“died, date unknown”) is valid. In 5.5.1, only DEAT keeps the Y payload — BURI and CREM take no value. In 7.0, the Y payload is restored across the board: DEAT, BURI, and CREM may all carry [Y|<NULL>] again. To assert no death is recorded a different way — see Record that an event did NOT happen.

Validation notes. Putting a value on a tag that takes none (1 BURI 7 NOV 1901 instead of nesting the date) is flagged — the date belongs in a DATE child. CAUS is valid under any of these events in every version; it’s part of the event detail. To confirm what may nest under a tag in your file’s version, click the tag and choose Show in Specification to open the spec viewer.

Record a baptism or christening

The structure. GEDCOM separates the infant rite (CHR, christening) from BAPM (baptism — a general baptism event, distinct from the Latter-day Saint ordinance BAPL). Pick the tag that matches the event:

1 CHR
2 DATE 20 MAR 1832
2 PLAC Old North Church, Boston, Massachusetts, USA

Related tags in the same family: BAPM (baptism), CHRA (adult christening), CONF (confirmation), FCOM (first communion), BLES (blessing), BARM/BASM (bar/bas mitzvah), ORDN (ordination). All take the same event-detail block beneath them.

In the app. Add the rite’s tag as a line beneath the person; autocomplete lists the religious-event tags valid for your version. Not sure which tag fits? Open the spec viewer — each tag’s entry says what it’s for.

Across versions. CHR and BAPM exist in all three versions. The differences are in the bare-Y assertion and in adult christening:

5.5 allows the [Y|<NULL>] value on CHR, BAPM, BARM, BASM, BLES, CHRA, CONF, FCOM, and ORDN, so 1 CHR Y asserts a christening with no date.
5.5.1 keeps the Y payload on CHR (grouped with BIRT) but drops it from BAPM and the rest of this religious group — those take no value; record what you know with DATE/PLAC children.
7.0 allows [Y|<NULL>] on CHR, BAPM, and the rest of this group, and each may also carry a free-text TYPE describing the specific variety of the event.

Validation notes. CHRA is a separate tag from CHR — using CHR for an adult christening isn’t wrong, but CHRA is more precise where the version supports it. 1 CHR Y is valid in all three versions, but 1 BAPM Y is flagged in 5.5.1 (which dropped that payload from BAPM) while remaining valid in 5.5 and 7.0.

See also: Record a custom event or fact · The spec viewer.

Record occupation, residence, and other attributes

Goal. Record a standing fact about a person — what they did, where they lived — as opposed to a dated event. GEDCOM calls these attributes, and they look almost like events but carry their value on the tag line itself.

The structure. An attribute puts its content on the tag line, then nests the same event detail beneath it:

0 @I1@ INDI
1 NAME Jane /Smith/
1 OCCU Schoolteacher
2 DATE FROM 1855 TO 1870
2 PLAC Boston, Massachusetts, USA
1 RESI
2 DATE 1860
2 PLAC 14 Beacon Street, Boston, Massachusetts, USA

OCCU Schoolteacher reads “occupation: schoolteacher”. The standard attributes include OCCU (occupation), RESI (residence), EDUC (education), RELI (religion), TITL (title), NATI (nationality), CAST (caste), DSCR (physical description), NCHI (number of children), NMR (number of marriages), PROP (property), IDNO (an id number; a TYPE says what kind — required in 7.0), and SSN.

In the app. Add the attribute’s tag beneath the person; autocomplete offers them and you type the value directly on the line. Because attributes often span a period rather than a single day, a DATE like FROM 1855 TO 1870 is common — the date editor supports date ranges.

Across versions. The attribute list is stable across 5.5, 5.5.1, and 7.0, with one notable shift in RESI:

In 5.5 and 5.5.1, RESI carries no value — you record the residence entirely through its DATE, PLAC, and ADDR children, so the tag line is just 1 RESI.
In 7.0, RESI gained a text payload, so 1 RESI 14 Beacon Street is valid (though nesting a PLAC is still the structured way).
RESI is an individual attribute in all three versions. It is also a family attribute (a couple’s shared residence under a FAM) in 5.5.1 and 7.0 — but not in 5.5, whose family structure has no RESI.

Validation notes. In 7.0, IDNO requires a TYPE child (it says what kind of number it is) and an IDNO without one is flagged; in 5.5 and 5.5.1 the spec recommends a TYPE but lists it as optional, so the app doesn’t flag its absence. Putting a value on a 5.5/5.5.1 RESI (1 RESI Boston) is flagged as an unexpected payload; move it to a PLAC or upgrade the file to 7.0. Don’t confuse an attribute with an event: an occupation that spanned years is an attribute (OCCU), not a dated event.

Record a custom event or fact (EVEN with TYPE)

Goal. Record something the standard has no dedicated tag for — a land lease, a naturalization detail, a hobby — without inventing a custom tag. GEDCOM provides two generic carriers: a generic event (EVEN) and, from 5.5.1 on, a generic attribute/fact (FACT). A subordinate TYPE classifies which kind it is.

The structure (5.5.1 and 7.0). Use EVEN for something that happened on a date, and FACT for a standing characteristic:

1 EVEN Land transaction
2 TYPE Land lease
2 DATE 2 OCT 1837
2 PLAC Boston, Massachusetts, USA
1 FACT Woodworking
2 TYPE Hobby

EVEN describes the event through TYPE plus the usual DATE/PLAC. The short descriptor on the EVEN line (Land transaction) is optional in 5.5.1 but required in 7.0, so including it — as shown — keeps the example valid in both; either way the TYPE is still required. FACT puts the fact’s content on the tag line (FACT Woodworking) with TYPE naming the category.

The structure (5.5). Version 5.5 has no FACT tag — the generic EVEN is the only path, and you use it for both events and facts:

1 EVEN
2 TYPE Hobby
2 NOTE Woodworking

In the app. Add an EVEN (or, in a 5.5.1/7.0 file, FACT) line beneath the person; autocomplete offers TYPE as a child and you describe the event or fact there. The autocomplete list is version-aware — FACT is offered only in 5.5.1 and 7.0 files.

Across versions.

5.5 — EVEN only. There is no generic-attribute tag; classify everything through EVEN + TYPE.
5.5.1 — introduced FACT (with a required TYPE) as the generic attribute, sitting alongside EVEN. The spec itself draws the line: an EVEN is something dated, a FACT is a standing characteristic.
7.0 — keeps both. FACT still requires a TYPE; the generic individual EVEN requires a TYPE too, and a family EVEN requires one as well.

Converting a 5.5.1/7.0 file down to 5.5 drops each FACT — 5.5 has no generic-attribute tag — and reports every dropped fact so nothing vanishes silently (best-effort). To carry that data down, record it as a generic EVEN (or a note) before you convert.

Validation notes. A FACT without a TYPE is flagged in both 5.5.1 and 7.0 — the spec requires the classifier, and it’s what makes the generic tag meaningful. The generic EVEN requires a TYPE only in 7.0; in 5.5.1 a TYPE under EVEN is recommended but optional, so a bare EVEN isn’t flagged there. A FACT tag in a 5.5 file is flagged as not valid in that version; use EVEN there.

Add detail to any event (date, place, age, cause, agency, notes, sources)

Goal. Learn the shared event-detail block once and attach it under any event or attribute — birth, death, occupation, a generic EVEN, anything.

The structure. The same set of detail tags nests beneath every event:

1 DEAT
2 DATE 4 NOV 1901
2 PLAC Boston, Massachusetts, USA
2 AGE 69y
2 CAUS Pneumonia
2 AGNC Massachusetts Board of Health
2 NOTE Recorded in the city register.
2 SOUR @S1@
3 PAGE Vol. 12, p. 88

DATE — when it happened (Dates & places)
PLAC — where (Dates & places)
AGE — the subject’s age at the event (individual events; in 5.5, family events too)
CAUS — the cause
AGNC — the responsible agency or authority
RELI — religious affiliation for the event
ADDR — a mailing address for the event’s place
NOTE — free text (Notes)
SOUR — a source citation (Sources & citations)

In the app. With the cursor under an event, autocomplete offers exactly these detail tags. AGE opens beneath individual events (a birth, death, baptism); PLAC and DATE get dedicated editors.

Across versions. The block is similar everywhere but not identical — this is the most version-sensitive part of event detail:

5.5 — EVENT_DETAIL holds TYPE, DATE, PLAC, ADDR, AGE, AGNC, CAUS, SOUR, and multimedia. AGE lives directly in the detail block here.
5.5.1 — reorganised: the shared EVENT_DETAIL adds RELI and RESN (restriction), while AGE moves up to wrap the event (so it’s available on individual events, not under family events). Each of TYPE/DATE/PLAC/ADDR/AGNC/RELI/CAUS appears at most once; NOTE, SOUR, and multimedia may repeat.
7.0 — TYPE moves out of the detail block onto each event tag itself; the detail block gains PHON, EMAIL, FAX, WWW, SDATE (a sort date), associations, and a UID. AGE (with an optional PHRASE) wraps individual events as in 5.5.1.

In short: DATE, PLAC, CAUS, AGNC, NOTE, SOUR work everywhere; RELI in the detail block and AGE on individual events are 5.5.1-and-later. The contact tags reach the event through the address structure: PHON is available in all three versions, EMAIL/FAX/WWW from 5.5.1 on; 7.0 simply lists all four (plus SDATE and UID) directly in the event-detail block.

Validation notes. Each single-occurrence detail tag (DATE, PLAC, CAUS, AGNC, …) appears at most once per event — a second DATE under one event is flagged; record an alternate date as a separate event or a note. A RELI under an event in a 5.5 file is flagged (it’s not in 5.5’s event detail). In 7.0, a TYPE nested under the event detail (rather than on the event tag) is the wrong shape — the app places it correctly as you type.

See also: Dates & places · Notes · Sources & citations.

Record that an event did NOT happen

Goal. Assert that a specific event did not occur — for example, that a person never married — rather than simply leaving it out. The absence of a MARR could mean “didn’t happen” or “not yet researched”; the NO structure says the former, on the record.

The structure (7.0 only). A NO line names the event type that didn’t happen, optionally bounded by a date period:

0 @I1@ INDI
1 NAME Jane /Smith/
1 NO MARR
2 DATE TO 1901
2 NOTE Census and parish records through 1901 show no marriage.
2 SOUR @S1@

NO MARR means “no marriage occurred”. The optional DATE is a date period — TO 1901, FROM 1855 TO 1870 — limiting the assertion to that span; without it, the claim is “never happened”. You may add NOTE and SOUR to support it, but they must not narrow what didn’t happen.

In the app. In a 7.0 file, add a NO line beneath the record and let autocomplete offer the event type as its value (it draws from the same event enumeration). NO is offered only in 7.0 files; the spec viewer entry explains the structure and its date-period rule.

Across versions. This is a 7.0-only structure. 5.5 and 5.5.1 have no NO tag — there is no standard way to assert non-occurrence in those versions. Record the same information in a note (“No marriage found in records through 1901”) if you must stay on an older version. Converting a 7.0 file down to 5.5 or 5.5.1 cannot preserve NO as structured data — the converter drops it on a best-effort basis and warns; consider capturing the assertion as a note before converting.

Validation notes. A NO line in a 5.5 or 5.5.1 file is flagged — the tag isn’t valid there. In 7.0, the NO payload must be an event type that would itself be legal on that record (you can’t write NO XYZ for an event that couldn’t occur there), and the only substructure that may restrict the assertion is DATE — a note or source attached to a NO may discuss it but not limit it.

See also: Notes · Converting GEDCOM versions · Validation.

Next: the dates and places those events happened — Dates & places →.