---
title: A Gentle Proposal: New Record Types for GEDCOM 8
author: Tineke Ko…smis
date: Aug 15, 2025
tags: [gedcom8, suggestion, structure, sticky, template, asset, group, proof, flex]
---
## A Structured Event-Based Source System
---
🦜 *A clean structure is a happy structure.*
🪶 A gentle proposal — designed to nest in the minds of developers, not ruffle their feathers.
---
# A Personal Note Before We Begin
Back in 1971, when I first started programming, we had no schools or structured learning materials for what we were doing. We simply figured it out — experimenting, failing, trying again. There were no “best practices” — just logic, curiosity, and perseverance. I’ve carried that approach ever since, and it led me, decades later, to take a fresh look at GEDCOM.
I’ve always found it odd that in GEDCOM, source metadata is so carefully structured — what book, page, archive, etc. — but the actual data from documents gets dumped as one large transcription into a single blob of text. That transcription then gets chopped into pieces and glued to individual persons and facts, often detached from the document context it came from. That never sat right with me.
One day, I thought: what if we approached this the way forensic teams do — like in CSI movies? They use evidence boards: post-its, strings, scribbled notes, all anchored to specific events and people. I began to imagine little post-its sliding across an invisible whiteboard — grouped, rearranged, then pinned down again. Once I visualized those post-its, the solution came.
That vision gave birth to STICKY records: a way to preserve and structure document-derived data as it really appears, before it’s scattered across a family tree. Not just metadata, not just conclusions — but the raw material, **kept in context**.
This whole system didn’t come from a spec sheet. It came from a feeling — a hunch, a sense that something in the process was broken, and that if I could see it clearly, I maybe ould fix it. That’s how I work. Always have.
This isn’t just about data. It’s about respecting context, improving clarity, and letting software assist human understanding — not just mimic it. I’ve been the odd one out before: a woman in a field of men, a logic-driven person who follows intuition. But I believe GEDCOM can evolve. And I hope this helps a bit to point the way.
---
# How this was done:
Now before diving into the details, I want to explain how this proposal was created — both technically and personally.
It started with the `STICKY` idea, nothing more, and I had absolutely no idea at that time, where it would lead me, that it would lead me to all this. But I saw it grow, and it looked beautifull, and it seemed worthwhile, so I kept going.
Countless hours were spent experimenting, building examples, and asking:
- “Is this the easiest and best way to do this?”
- "Is this the only and the correct solution?"
- "Doesnt this make things too complex?"
- "Could this be programmed in an easy way?"
Ánd when the answer was "NO", a new search began for a solution that was better.
This is not just a list of technical tweaks; it’s the outcome of deep, hands-on testing, long searches and stubbornly continuing to make the format easier for real genealogists to use — while keeping it rigorous for software developers.
The tone of this proposal reflects me — sometimes meticulous, sometimes playful, always focused on clarity. If you see humor and beauty here, it’s intentional: real family history is rarely dry, and neither should the examples we use to model it.
---
## 🧭 Executive Summary
This proposal introduces a set of new GEDCOM record types to provide a more structured and flexible approach to source citations, event roles, and document representation. The new records and structures — `TEMPLATE`, `STICKY`, `GROUP`, `ASSET`, `PROOF`, and `FLEX` — are designed to operate **alongside existing GEDCOM 7 records** without breaking compatibility. Together, they form an optional but powerful system for capturing source information in an event-centric, role-aware format.
---
## Why GEDCOM 8 Might Need New Structures
This goes beyond "convenience features" — the new structures solve real modeling problems that GEDCOM 7 simply cannot express cleanly, consistently, or at all.
### The Problem
GEDCOM's biggest strength — and its biggest limitation — is that it's built around **conclusions**. You declare people (`INDI`), link families (`FAM`), cite sources (`SOUR`), and build up a network of logical relationships. That works great for clean trees. But not for messy documents.
In real-life research, documents don't hand you neat conclusions. They give you messy input: odd names, unclear relationships, strange places. You need space to *describe* what's in front of you — before drawing conclusions.
✅ **Problem: Unstructured event blobs**
Traditional GEDCOM often reduces a real-life document to a single `EVEN` or `FACT` tag with scattered `NOTE` and `SOUR` references. There's no way to model complex roles, shared documents, or assets cleanly. The data ends up flat, unlinked, and ambiguous.
*Example:* A land grant may mention a grantor, grantee, several plots, and legal witnesses — but GEDCOM 7 users must cram that into one `EVEN` tag, with disconnected notes or loosely associated sources.
✅ **Problem: Repeating participants in multiple roles**
A person appearing in several documents must be described repeatedly, without clear links or context.
No way to say:
> "This baptism record, and this marriage record, both refer to this person, but use different names."
No way to show:
> "This inheritance record mentions the same asset described in that land record."
✅ **Problem: No way to model non-human participants**
GEDCOM lacks a real structure for non-person entities. Assets (land, medals, books, etc.) can't be linked properly across multiple records.
That’s where these new structures help. They let you **describe the evidence** — document by document, person by person, object by object — and keep the connections alive, even if you don’t yet know who someone “really” is.
---
## 🧩 What This Proposal Includes
This project introduces **five new GEDCOM8 record types** — and one flexible extension — all designed to work alongside the existing `INDI`, `FAM`, `SOUR`, and `OBJE` structures.
---
## 🍃 TEMPLATE — One Document, One Container
TEMPLATE records act as **containers for one event**: a birth, a census, a will, a gravestone. They hold a date, a place, and a set of STICKYs — each one representing a person, object, or group involved.
Think of a TEMPLATE as a virtual version of the event, often a piece of paper in your hand.
A single TEMPLATE can link to several STICKYs. Each STICKY has a role — “father,” “child,” “registrar,” “property,” “clan.” And the TEMPLATE brings them all together with a shared context.
---
## 🧍 STICKY — One Person (or Thing), One Moment
A STICKY record is **a role in a specific context**. Not a person’s full life — just their appearance in one event or document.
You might have 20 STICKYs all linked to the same person (`INDI`) — one from a birth record, one from a marriage, one from a court file. Each one shows **how that person was recorded at the time** — their name, role, place, occupation, sex, and more.
This preserves the raw data **before** it’s merged into conclusions. And it makes it easier for software to analyze discrepancies or patterns across sources.
STICKYs can also represent **non-human things** (via ASSET), or memberships in GROUPs. Everything that plays a role in a document gets a STICKY.
---
## 🏠 ASSET — One “Thing,” Over Time
ASSETs are like `INDI`, but for **non-human entities**. Think of:
- A parcel of land passed through a family
- A medal awarded to multiple individuals
- A horse or ship documented in property transfers
Each ASSET is a stable container, with **STICKY records linked into it**. Over time, these STICKYs show how the ASSET changed: who owned it, where it was, what its status was.
---
## 🧑🤝🧑 GROUP — Named Communities with Join/Leave
GROUPs represent **named social structures** that people can join, leave, or interact with:
- A village council
- A religious order
- A rebel faction
- A sports team
GROUPs give a name, date, place, and optional attributes. STICKYs link people (or things) into them — showing **how** they were involved, and when.
---
## 🔍 PROOF — Describe reasoning and outcome
The `PROOF` record is an **experimental and optional structure** designed to support **reasoning, weighing, and justification** when evaluating competing `STICKY` records for use in an `INDI` , `GROUP` or `ASSET` role.
It has a list of candidate STICKYs, each with ARGUMENTs and OUTCOME.
And a TOPSTICKY designating the chosen STICKY from all ARGUMENTs.
---
## 🎛️ FLEX — Clean Representation of Unknown or Nonstandard Fields
FLEX is a new container that holds **structured values** that don’t map directly to GEDCOM tags — things like:
- "Height: 1.73m"
- "Name uncertain: 'Antonia?'"
- "Currency: 12 gulden"
- "Land size: 4 morgens"
- "Alias: 'Jan de Wit'"
These are **not extensions** in the traditional sense. FLEX is *not* a tag like `_MYSILLYTAG` — it’s a self-contained structure with a type, required `CONTENTS`, and human-readable `PHRASE`.
---
Continued in next post.....
something in that direction could be far more productive for collaborative genealogy than the current lossy or siloed approaches likeGEDCOM, FamilySearch or WikiTree or the vendor locked-in platforms like MyH or Anc., Geni etc.