North London Beth Din

Shtar chov validation for halachic wills

Updated 9 April 2026 Faith England & Wales Dual System Fictional Scenario
50%
Reduction in dayan review time per endorsement

The Problem#

  • Jewish halachic wills use a shtar chov (debt instrument) mechanism to reconcile halacha with English testamentary freedom
  • Under halacha, inheritance is prescribed: sons inherit (firstborn gets a double portion), daughters inherit only if there are no sons, and the wife does not inherit (she has ketubah rights instead)
  • A testator who wants to leave assets to a daughter or wife must create a halachic debt instrument making the halachic heirs “owe” the estate an enormous sum, forgiven only if they distribute according to the English will
  • The Beth Din must validate that this mechanism is correctly constructed — but currently receives the will as a paper document, with no structured way to verify the shtar chov logic
  • Each endorsement takes a dayan 3–4 hours of manual review

How They’d Use INHERIT#

  • The Beth Din receives INHERIT documents containing the jewish-succession extension, which models the shtarChov mechanism with debtAmount, forgiveCondition (referencing the English will’s distribution), witnessPersonIds[] (the two kosher witnesses required), and bethDinEndorsement (the validation status)
  • person.json entries include ritualName with nameSystem: "hebrew" — essential for halachic documents where the Hebrew name, not the legal name, is the binding identifier
  • bequest.json entries carry constrainedBy: "religious_rule" where the distribution is driven by halacha
  • kinship.json entries model the halachic family tree — critical because halachic inheritance follows patrilineal descent, and the Beth Din must verify the family structure to confirm the correct heirs
  • The relationship.json entries establish the precise lineage required for firstborn double-portion calculations

The Integration#

  • The Beth Din receives INHERIT documents from solicitors who prepare halachic wills
  • A dayan reviews the structured shtar chov data, verifies the kinship tree against halachic rules, and records the endorsement directly in the INHERIT document’s jewish-succession extension fields
  • The endorsed document is returned to the solicitor as portable proof of halachic compliance

The Business Case#

  • The Beth Din handles approximately 200–300 halachic will endorsements per year
  • Currently, each endorsement requires 3–4 hours of manual review; structured data reduces this to 1–2 hours by pre-calculating the halachic distribution and presenting the shtar chov logic clearly
  • That is approximately 400–600 dayan hours saved annually
  • The Beth Din’s endorsement, recorded in the INHERIT document, becomes portable proof of halachic compliance that the family can present to any rabbinical authority worldwide

Before / After#

Without INHERIT:

  1. A solicitor prepares a halachic will and posts a paper copy to the Beth Din
  2. A dayan reads the entire will, manually identifies the shtar chov clause, and extracts the debt amount and forgiveness conditions
  3. The dayan reconstructs the family tree from the will text, checking each heir’s halachic status by hand
  4. The dayan calculates the correct halachic distribution and compares it to the shtar chov logic — 3–4 hours per case
  5. The endorsement is recorded on a separate letter, returned by post

With INHERIT:

  1. A solicitor submits an INHERIT document with the jewish-succession extension to the Beth Din
  2. The dayan sees the shtar chov logic, kinship tree, and halachic distribution pre-structured and machine-validated
  3. The dayan verifies the data, records the endorsement directly in the document, and returns it — 1–2 hours per case
“The shtar chov mechanism is delicate — one error in the kinship tree and the entire halachic will collapses. Structured data means I can see the logic, not just read a story.”
Dayan Moshe Feldman, Senior Dayan, North London Beth Din
Disclaimer: North London Beth Din is a fictional organisation created for illustrative purposes. This case study describes a hypothetical integration scenario. All metrics, savings, and outcomes are projected estimates, not actual results. References to real regulatory bodies, courts, and legislation are for accuracy and do not imply endorsement.

Get in touch

Have a question about INHERIT, or interested in becoming a partner? We'd love to hear from you.

or email hello@openinherit.org