Relationships

People connect through family records. A FAM ties a couple and their children together entirely with pointers, and each person points back at the families they belong to. These recipes start with the couple-and-children skeleton and work up to adoption, multiple parents, and named associations.

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.

Create a family and link a couple

The structure. A family is a FAM record. The two partners are HUSB and WIFE pointers, and each individual points back at the family with a FAMS (“family as spouse”) line:

0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@

0 @I1@ INDI
1 NAME John /Smith/
1 FAMS @F1@

0 @I2@ INDI
1 NAME Jane /Doe/
1 FAMS @F1@

The link is bidirectional: the FAM names its partners, and each partner names the FAM. No names live in the family record — just pointers.

In the app. The easy path is Add relative — select a person, add a Spouse, and Linea Codex creates the new individual, the FAM record, and both sides of the HUSB/WIFE ↔ FAMS link in one step, then moves the selection to the new spouse. To build it by hand, use Add Record (in the Edit menu, or the split button in the toolbar) and choose FAM – Family, then add HUSB/WIFE pointer lines; autocomplete offers them and the reference picker helps you point at the right individual.

Across versions. The FAM skeleton — HUSB, WIFE, CHIL, with FAMS/FAMC on the individuals — is the same in 5.5, 5.5.1, and 7.0. What differs is what HUSB and WIFE mean:

5.5 / 5.5.1 describe the family record as assuming “the HUSB/father is male and WIFE/mother is female.” The tags carry a gender implication in those versions’ wording.
7.0 explicitly reframes HUSB and WIFE as layout roles, not genders. The spec says the record “may also be used for cultural parallels… including nuclear families, marriage, cohabitation, fostering, adoption, and so on, regardless of the gender of the partners,” and that sex or gender “should not be inferred based on the partner that the HUSB or WIFE structure points to.” For an unmarried or same-sex couple, you still use HUSB and WIFE as the two partner slots — they are just positions in the record. (7.0 also lets a FAM carry PHRASE under HUSB/WIFE/CHIL and adds an <<ASSOCIATION_STRUCTURE>> to the record for partners beyond two.)

So the lines you write are identical; only the interpretation widens in 7.0. Recording a same-sex or unmarried couple is well-formed in every version — older versions simply phrase the roles as gendered.

Validation notes. A FAM may have at most one HUSB and one WIFE (a person in more than one union gets more than one FAM). The checker watches the bidirectional invariant: a FAM whose HUSB/WIFE points at an individual that does not carry the matching FAMS back-pointer is flagged as a broken link — in 7.0 the symmetry is a stated rule. Linea Codex keeps both sides in sync when you use Add relative; when you wire pointers by hand, add the back-pointer too.

Record marriage, divorce, and other couple events

The structure. Couple events nest inside the FAM record. The most common is MARR; a matching Y asserts the event happened even when you have no date:

0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 MARR
2 DATE 14 JUN 1898
2 PLAC Boston, Massachusetts, USA
1 DIV
2 DATE 1905

A bare 1 MARR Y means “they married” with no further detail; 1 MARR with a DATE/PLAC beneath it records the particulars.

In the app. With the FAM record open, add the event line and let autocomplete offer the family-event tags valid for your version, then nest DATE and PLAC beneath. The date editor helps with the DATE, and place handling is covered in Dates & places. To see exactly what may nest under a given event, open the spec viewer.

Across versions. The core couple events — ANUL (annulment), CENS (census), DIV (divorce), DIVF (divorce filed), ENGA (engagement), MARB (banns), MARC (contract), MARL (license), MARR (marriage), MARS (settlement), and a generic EVEN — exist in all three versions. The wrinkle is RESI (residence):

5.5 has no family RESI at all — RESI exists only as an individual attribute under INDI, not as a family event under FAM.
5.5.1 added RESI as a family event under FAM (alongside the individual-attribute use).
7.0 reclassifies the family RESI as a family attribute (it takes a text payload), not an event. The tag is still valid on a FAM, but it’s modelled differently. Converting a 5.5.1 family RESI to 7.0 reshapes it to the attribute form; converting it down to 5.5, which has no family RESI, is lossy — both are best-effort.

In 7.0 each of these events may also carry a free-text TYPE to subclassify it (e.g. 2 TYPE Common law under MARR).

Validation notes. A couple event under FAM is valid; the same tag misplaced under an INDI is flagged (marriage is a property of the family, not one person). MARR Y with the literal Y asserts the event; any other value on the MARR line is rejected. Per-partner ages at the event go in the HUSB/WIFE + AGE detail beneath the event, which the inspector surfaces as “Husband’s age at marriage” / “Wife’s age at marriage.”

Add children to a family

The structure. Each child is a CHIL pointer in the FAM, and each child points back with FAMC (“family as child”):

0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 CHIL @I3@
1 CHIL @I4@

0 @I3@ INDI
1 NAME Anne /Smith/
1 FAMC @F1@

Like the couple link, this is bidirectional — FAM.CHIL and INDI.FAMC are two halves of the same edge. The preferred order of CHIL pointers is chronological by birth.

In the app. Select a parent and use Add relative → Son or Daughter; Linea Codex creates the child, adds the CHIL pointer to the existing family (or creates the family if needed), writes the FAMC back-pointer, and pre-fills the child’s SEX to match the label you chose. To add an existing person as a child by hand, add a CHIL line to the FAM and the matching FAMC to the individual.

Across versions. The CHIL/FAMC pairing is identical in 5.5, 5.5.1, and 7.0. The details you can attach to the child link differ, and that’s the next few recipes — the pedigree type of the link (PEDI) and its status (STAT). In 7.0 the FAMC link sits directly on the INDI record and may carry PEDI, STAT, NOTE, and (for PEDI/STAT) a PHRASE; 5.5 and 5.5.1 model the same link through a CHILD_TO_FAMILY_LINK substructure, with 5.5.1 adding STAT.

Validation notes. As with the couple link, a CHIL whose target lacks the matching FAMC (or vice versa) is a broken edge and is flagged. 7.0 recommends against two CHIL lines pointing at the same individual in one family (it implies a nonsensical birth order). Source citations about how a child relationship began belong under the child’s BIRT, CHR, or ADOP event rather than on the FAM or INDI record — see the adoption recipe.

Record an adoption

The structure. Adoption is recorded in two complementary places. On the child, an ADOP event points (via FAMC) at the adopting family and says which parent adopted; on the child-to-family link, a PEDI adopted marks the relationship type. A worked 5.5.1 example:

0 @I3@ INDI
1 NAME Anne /Smith/
1 ADOP
2 DATE 1906
2 FAMC @F1@
3 ADOP BOTH
1 FAMC @F1@
2 PEDI adopted

The ADOP event’s FAMC has its own ADOP role line — HUSB, WIFE, or BOTH — naming which partner in the family adopted the child. The separate FAMC (the lineage link) carries PEDI adopted.

In the app. Add an ADOP event to the child in the editor; autocomplete offers the FAMC pointer and the ADOP role beneath it, and the reference picker points FAMC at the right family. The PEDI on the lineage link is a separate line on the child’s FAMC; autocomplete offers exactly the enum values valid for your file’s version. Open the spec viewer on PEDI to read its allowed values inline.

Across versions. The mechanics are the same everywhere — an ADOP event with a FAMC+ADOP role, plus a PEDI on the lineage link. The enum spelling is what changes:

5.5 / 5.5.1 — PEDI values are lowercase: adopted, birth, foster, sealing. The ADOP role under the event’s FAMC is HUSB, WIFE, or BOTH.
7.0 — PEDI values are uppercase and gain OTHER: ADOPTED, BIRTH, FOSTER, SEALING, OTHER (with a PHRASE for the “other” case). The ADOP role enum is still HUSB/WIFE/BOTH.

So 2 PEDI adopted in 5.5.1 becomes 2 PEDI ADOPTED in 7.0. Converting versions remaps the casing for you; a 7.0 PEDI OTHER has no exact 5.5.1 equivalent, so converting down is best-effort (the value and its phrase are degraded to the nearest fit or a note).

Validation notes. A 7.0 file using a lowercase pedi value (or a 5.5.1 file using uppercase) is flagged as an invalid enumerated value — the casing is part of the enum. The 7.0 spec notes that ADOPTED implies only a social relationship and need not have an ADOP event, whereas SEALING implies an LDS SLGC ordinance is present. A PEDI OTHER in 7.0 should carry a PHRASE.

Record fostering and other parent-child link types

Goal. Mark how a child belongs to a family — fostered, sealed, or birth — when it isn’t the default biological relationship. The mechanism is the PEDI (pedigree linkage type) on the child’s FAMC.

The structure. PEDI qualifies the lineage link without needing a separate event:

0 @I3@ INDI
1 NAME Anne /Smith/
1 FAMC @F1@
2 PEDI foster
1 FAMC @F2@
2 PEDI birth

Here the child has two parent families: a foster family and a birth family, each labelled by its PEDI.

In the app. Add the FAMC link (or use Add relative to create the family), then add a PEDI line beneath it; autocomplete offers the version-correct enum values. Linea Codex doesn’t infer the link type — a plain FAMC with no PEDI is just “a parent family,” so add PEDI when the relationship is anything other than the unstated default.

Across versions. The four shared link types are adopted/ADOPTED, birth/BIRTH, foster/FOSTER, and sealing/SEALING — lowercase in 5.5 / 5.5.1, uppercase in 7.0, with 7.0 adding OTHER (+ PHRASE). One subtle cardinality difference:

5.5 lets PEDI repeat on a single FAMC link ({0:M}).
5.5.1 and 7.0 allow at most one PEDI per FAMC link ({0:1}). 5.5.1 also added a STAT (child-linkage status) line to the link; 7.0 carries STAT plus a PHRASE on both PEDI and STAT.

Note that foster is purely a PEDI value — there is no separate “fostering event.” Fostering is expressed entirely by the link type on FAMC.

Validation notes. A second PEDI on one FAMC link is valid only in 5.5 — in 5.5.1 and 7.0 the checker flags the repeat. As always, an enum value in the wrong case for the file’s version is flagged. The 7.0 spec cautions that BIRTH is interpreted inconsistently across applications (genetic vs. social parent), so don’t read more into it than the link asserts.

Record more than one set of parents

The structure. A child simply carries several FAMC links — one per parent family — and each family lists the child. Distinguish them with PEDI:

0 @I3@ INDI
1 NAME Anne /Smith/
1 FAMC @F1@
2 PEDI birth
1 FAMC @F2@
2 PEDI adopted

@F1@ is the birth family and @F2@ the adoptive one. Both families also list 1 CHIL @I3@.

In the app. Each parent family is a separate FAM with its own CHIL @I3@ and a matching FAMC on the child. Add relative can add a second set of parents only when the person has no parent family yet; once a person already belongs to one parent family, the app surfaces “Cannot add parents to a person with multiple parent families” for the guided flow — add the additional FAMC/CHIL pair by hand in the editor in that case, labelling each link with PEDI. Linea Codex never blocks the data; the limit is on the one-click helper, not on the file.

Across versions. Multiple FAMC links are valid in 5.5, 5.5.1, and 7.0 — FAMC is {0:M} on the individual everywhere. The 7.0 spec explicitly permits a person to have multiple FAMC substructures and even multiple FAMC pointing at the same FAM (though it recommends against the latter). Use PEDI on each link, with the version-correct casing, so a reader can tell birth parents from adoptive or foster ones.

Validation notes. Every FAMC still needs its matching CHIL back-pointer, and each link is validated independently. The checker does watch for an impossible loop — if the same person is reachable as both an ancestor and a descendant of themselves through CHIL/FAMS and HUSB/WIFE/FAMC pointers, that’s almost always an error (7.0 calls this out specifically, while noting non-biological relationships make it theoretically possible).

Record a witness, godparent, or other association

Goal. Link a person to someone who isn’t a spouse, parent, or child — a witness at a baptism, a godparent, an officiating clergy member, a friend, a neighbour. GEDCOM calls this an association (ASSO).

The structure (5.5 / 5.5.1). ASSO points at the associated individual; RELA gives the relationship as free text:

0 @I1@ INDI
1 NAME Anne /Smith/
1 ASSO @I9@
2 RELA godparent

In 5.5.1 the RELA line is required and free-form (“godparent”, “witness”, “great grandson”). 5.5 requires both a RELA and a TYPE naming what kind of record is being associated.

The structure (7.0). 7.0 replaces free-text RELA with an enumerated ROLE plus an optional PHRASE, and lets the association hang off an event as well as the record:

0 @I1@ INDI
1 NAME Anne /Smith/
1 ASSO @I9@
2 ROLE GODP
1 BAPM
2 DATE 1898
2 ASSO @I8@
3 ROLE WITN

Here @I9@ is the godparent (recorded on the person) and @I8@ is a witness at the baptism (recorded on the event).

In the app. Add an ASSO line to a person (or, in a 7.0 file, to an event) and let autocomplete offer the version-correct child — RELA in 5.5/5.5.1, ROLE in 7.0 — together with the reference picker for the pointer. For a 7.0 ROLE, autocomplete offers exactly the enumerated members; the spec viewer lists what each role means. The inspector renders these associations with role-aware labels such as “Godfather” / “Godmother” / “Godparent.”

Across versions. This is one of the more version-sensitive structures:

5.5 — ASSO on the INDI record, with a required TYPE (record type) and a required free-text RELA. It associates an individual to an individual.
5.5.1 — ASSO on the INDI record, with a required free-text RELA (the TYPE line is gone). Still individual-to-individual, and only on the record — not on events.
7.0 — ASSO carries a required ROLE (enumerated) with an optional PHRASE, and may sit on a record or an event. The ROLE enum is: CHIL, CLERGY, FATH, FRIEND, GODP, HUSB, MOTH, MULTIPLE, NGHBR, OFFICIATOR, PARENT, SPOU, WIFE, WITN, and OTHER (which should carry a PHRASE). 7.0 also adds ASSO to the FAM record, and notes that ASSO should not be used for relationships already expressible with HUSB, WIFE, or CHIL.

Converting a free-text 5.5.1 RELA to a 7.0 ROLE maps it to the closest enum member where one exists (e.g. “witness” → WITN, “godparent” → GODP) and otherwise falls back to ROLE OTHER with the original text preserved in PHRASE — best-effort. Going the other way, a 7.0 ROLE becomes a free-text RELA.

Validation notes. In 5.5.1, an ASSO with no RELA is flagged (RELA is required). In 7.0, an ASSO with no ROLE is flagged, a ROLE value outside the enum is rejected, and a ROLE OTHER should carry a PHRASE. A 7.0-style ASSO placed under an event in a 5.5.1 file is flagged, since 5.5/5.5.1 allow ASSO only on the individual record. For two records you believe describe the same person, don’t use ASSO — use a second NAME line or ALIA, covered in People & names.

See also: People & names (same-person links) · Record a birth, death, or other event (where event-level ASSO attaches) · The spec viewer.

Next: backing your facts with evidence — Sources & citations.