TT Claude Memory

feedback_v1_is_valuable_starting_point_inclusive

Properties1
description2026-04-24 Rich directive during v1 deep-dive brainstorm. v1's data structure is imperfect but contains a huge amount of useful starting points that accelerate jurisdictions v2 can impact. Don't miss opportunities. v2 is an international standard.

3 min read

When working with INHERIT v1 (v6.6) content during v2 / InheritKit design or audit, treat it as a generous source of starting points — not as a flawed predecessor to be dismissed or improved-past.

Why

Rich’s directive on 2026-04-24 during the v1 deep-dive brainstorm:

“the structure of the data in inherit v1 may not be perfect, but there is a huge amount of very useful starting points, that will lead us to potentially accelerating the jurisdictions we are able to have an impact in. inherit v2 is an international standard: do not miss any opportunities to utilise inherit v1”

v1’s value is in concrete jurisdiction + tradition content that took years to accumulate:

  • 21 extensions spanning Western, Islamic, Hindu, Jewish, African traditions
  • Jurisdiction-specific schemas (UK-EW, US-estate, Scotland, Japan, PRC-China, Switzerland, etc.)
  • Tradition-law research embedded in schemas (fara’id, Mitakshara, halachic, customary)
  • Proposals documents (kinship-enrichment, contemplation-of-marriage, executed-estate-distribution)
  • Design docs (null-semantics, ai-integration, extension-composition)
  • ~28,207 LOC of research-embedded content

Even where v1’s STRUCTURE is wrong for v2, the CONTENT (concepts, constraints, values, edge cases) is valuable for accelerating v2’s jurisdictional coverage.

How to apply

Rule 1 — Inclusive bias during v1-reference work

When reviewing v1 content (schemas, docs, proposals) for v2 + InheritKit adoption:

  • Default: accept the v1 finding as a starting point unless there’s specific reason to reject
  • Only reject when: (a) concept duplicates existing v2, (b) concept is demonstrably legally-obsolete, (c) concept is MFI-only and law-vs-practice-split already applies
  • Don’t reject for: “v1 used different structure” (restructure, don’t discard), “v2 has cleaner pattern” (ensure v2 pattern covers the v1 concept), “feels too jurisdiction-specific” (jurisdiction-specific is the POINT)

Rule 2 — Jurisdictional-acceleration signal

Every v1 finding should answer: “Which jurisdictions does this help v2 impact sooner?”

  • Scotland extension content → accelerates Scotland coverage in Phase-1 or Phase-1.5
  • Islamic-succession schemas → accelerate Arab-state + SE-Asian Muslim-majority jurisdictions
  • Hindu-succession schemas → accelerate India + diaspora jurisdictions
  • Content that doesn’t clearly accelerate any jurisdiction gets noted-but-deprioritised

Rule 3 — v1-reuse as explicit Phase-1.5 strategy

Phase-1.5 A-25 stress-test should include “import v1 content for each extension” as an explicit step, not just “check v2 can model v1”. Phase-1.5 authoring can largely be a v1-content-migration exercise with v2-structural-adjustments rather than from-scratch extension authoring.

Rule 4 — International standard framing

When adjudicating v2 decisions, always check: “Does this preserve v1’s international reach?” v1 already covers 16 jurisdictions + 4 traditions + 1 hybrid region (Latin America). v2 must not regress on jurisdictional breadth while it’s busy on structural correctness.

Anti-patterns

  • ❌ Treating v1 as “the predecessor we’re replacing” — misses that v1 is also “the content-library we’re inheriting”
  • ❌ Over-applying lean-to-InheritKit to v1-derived content — v1 is open-source Apache-track content, much of which belongs in Core-for-jurisdictional-coverage
  • ❌ Dismissing v1 findings because “we’ll do it better in v2” — v2’s better-structure doesn’t obviate v1’s researched-content
  • ❌ Skipping v1 content that “looks complex” — complexity is usually jurisdiction-specific + valuable
  • ❌ Running v2 adjudication without checking v1’s prior-art

Triggers

  • Any v1 deep-dive / mining / audit work
  • v2 Phase-1.5 A-25 stress-test planning
  • InheritKit crate scoping (check v1 first for prior-art)
  • Partner-outreach preparation (v1’s jurisdictional extensions are partner-conversation starters)
  • Any decision that could discard v1 content (pause and check acceleration-potential first)
  • feedback_inherit_v2_international_from_day_one.md — Phase-1 = commercial tractability; Phase-1.5 = full international via v6.6 extensions
  • project_v2_clean_break_from_v6_6.md — v2 is structural clean-break; content reuse is the EXCEPTION not the rule for Phase-1 BUT IS expected for Phase-1.5 stress-test
  • feedback_always_check_library_indexed_first.md — parallel discipline for research library

Graph View

Backlinks