About INHERIT

There is no global data interchange standard for estate planning information. FHIR solved this for health records. OpenBanking solved it for financial accounts. Estate planning — one of the most consequential data domains a person encounters — has nothing equivalent.

Every consumer platform is a walled garden. When a user creates an account on one platform and later moves to another, their estate data cannot travel with them. Professionals receive printed PDFs, scanned documents, or nothing at all. Structured data exists nowhere in the workflow.

INHERIT changes that. It defines a common vocabulary, a common structure, and a common API surface so that estate data can move between platforms, professionals, and jurisdictions without being trapped in any single system.

Twenty candidate names were scored on five criteria: brevity, domain relevance, simplicity, international appeal, and availability as a domain and trademark. Each criterion was scored out of 4, giving a maximum of 20.

INHERIT scored 18/20. It is immediately understood in every English-speaking jurisdiction, has no negative connotations in the target languages, and is short enough to use in code without abbreviation. The only point lost was on international appeal — the word has no direct cognate in some East Asian languages, though the concept is universally understood.

Rejected candidates included ESTATA (too close to a trademark), LEGACY (overloaded in software), HEIRDATA (awkward), and SUCCESSION (legally precise but consumer-unfriendly).

Sixteen schema format candidates were evaluated: JSON Schema 2020-12, JSON Schema Draft 7, Protocol Buffers, Apache Avro, XML Schema (XSD), RELAX NG, ASN.1, FlatBuffers, Cap'n Proto, GraphQL SDL, OpenAPI components, YAML Schema, CDDL, JSON-LD with SHACL, TypeScript interfaces, and a bespoke format.

Each was scored on seven criteria: tooling ecosystem, human readability, validation expressiveness, versioning support, extension mechanism quality, interoperability with existing standards, and implementation cost. Maximum score: 35.

JSON Schema 2020-12 scored 33/35. It has the broadest tooling support of any schema format, a mature validation ecosystem, first-class support in OpenAPI 3.1, and an extension mechanism via $vocabulary. Protocol Buffers scored 28 — strong on performance but weak on human readability and extension. Bespoke formats were eliminated immediately: GEDCOM's experience shows the maintenance burden of a custom format requiring custom parsers.

GEDCOM 7 is the closest prior art to INHERIT. It models genealogical data — family trees, vital events, source citations — across cultures and over centuries. We studied it carefully.

What GEDCOM 7 got right: event-based modelling (events happened at a point in time, not as boolean flags), source citation as a first-class concept (every assertion can be sourced), and a formal extension mechanism that allows community-defined structures without forking the core spec.

What GEDCOM 7 got wrong: gendered tags (HUSB, WIFE) survived until very late in the v7 revision, requiring a breaking change. The two-partner limit in family records is baked into the data model. And despite being open, GEDCOM remains a bespoke line-oriented format requiring custom parsers — a maintenance burden INHERIT avoids entirely by building on JSON Schema and OpenAPI.

INHERIT models 13 categories of relationship type drawn from legal systems, religious traditions, and cultural practices across the 10 launch jurisdictions. Categories include state-recognised civil marriage, state-recognised civil partnership, religious marriage (various traditions), customary marriage, de facto cohabitation, nikah, ketubah, lobola, mahr arrangements, and domestic partnership.

Relationship records in INHERIT support N partners — there is no structural two-partner limit. Roles within a relationship are not gendered: the schema uses party arrays rather thanhusband/wife fields. No assumption of monogamy is made at the schema level; jurisdictional rules about legal recognition are modelled separately via the data protection and jurisdiction extension schemas.

This was a deliberate design choice informed by the failure mode in GEDCOM. Assumptions baked into a data model become breaking changes. We prefer to model the world as it is and let jurisdictional validation schemas enforce local rules on top.

INHERIT was designed with four explicit principles to avoid encoding Western cultural assumptions into a global standard.

No gendered defaults. Person names use a structured object with given,family, middle, and preferred fields, plus a scriptfield for non-Latin representations. No field is marked as masculine or feminine.

No assumption of state recognition. A relationship that is legally recognised in one jurisdiction may not be in another. INHERIT separates the fact of a relationship from its legal status in a given jurisdiction. Both can be modelled without either invalidating the other.

No assumption of individual property. Community property, joint family property, and customary land tenure are modelled as first-class ownership structures, not exceptions to an individual ownership default.

Financial instruments as first-class data. Mahr (Islamic dower), ketubah (Jewish marriage contract), lobola (Southern African bridewealth), and prenuptial agreements are all modelled as structured financial instruments with defined parties, amounts, currencies, and conditions — not as free-text notes on a person record.

INHERIT does not reinvent what existing standards have already solved. Where a well-maintained international standard exists, we use it.

Date and time values use ISO 8601. Currency codes use ISO 4217. Jurisdiction and country codes use ISO 3166-1 alpha-2 and ISO 3166-2for subdivisions. Language tags use BCP 47. Person names and postal addresses follow the Schema.org vocabulary where compatible. Legal entity types use ISO 20275(GLEIF entity type codes).

The JSON-LD context published alongside the schemas maps INHERIT terms to Schema.org and Dublin Core equivalents, enabling semantic web consumption without requiring implementers to understand RDF.

RTL PDF rendering is unsolved. INHERIT defines the data model for estate documents; rendering those documents as PDFs in right-to-left scripts (Arabic, Hebrew, Persian) requires a typesetting engine that handles bidirectional text correctly. Current tooling (Puppeteer, WeasyPrint, PDFKit) has significant RTL limitations. Typst is a likely long-term solution but is not yet production-stable for complex documents. This is a known gap in the v1.0 tooling layer.

Early-stage versioning. INHERIT v1.0 does not yet commit to long-term backwards compatibility guarantees. The schema versioning mechanism is in place, but until implementations exist in the wild, we cannot know where the breaking-change pressure points are. We will commit to a compatibility policy at v2.0, informed by real-world adoption data.

We will add to this list as we learn. Transparency about limitations is not a weakness — it is the foundation of a standard that practitioners can actually trust.