feedback_introduction_module_rule

When placing a class (role / facet classifier / testamentary instrument / any structural primitive) in a specific v2 module, apply the introduction-module rule: the class lives in the module where its concept is first semantically introduced, not where it’s “most used” or “where the author happens to be working.”

The rule

1. Primary placement — class lives in the module where the concept is first semantically introduced by the domain.

   • wills:ExecutorRole lives in Wills (Wills Act 1837 introduces the executor concept in testamentary law)
   • trusts:TrusteeRole lives in Trusts (trust semantics own it; Wills / Probate reference via import chain)
   • inherit-asst:AssetCategoryClassifier lives in Assets (Asset-domain-specific taxonomy authoring)
   • inherit-wills:TestamentaryInstrument (abstract parent) lives in Wills (testator-expression concept)

2. Core-fallback rule — where a concept has NO single “introducing” module (it’s genuinely cross-cutting), it lives in Core.

   • inherit-core:JurisdictionClassifier (no single host primitive; cross-cuts everything)
   • inherit-core:FaithTraditionClassifier (Wills/Trusts/Probate/Delegation all reference)
   • inherit-core:SourceChannelClassifier (Asset/Liability/Valuation/Provenance all reference)

3. Do NOT specialise downstream just because the class is used in another module. Probate uses wills:ExecutorRole directly via D1-ε import chain; context lives on RoleInstance properties, not on a new specialised class. Specialisation only warranted when the downstream module has genuinely NEW semantic fields for that concept.

4. Do NOT centralise in Core by default. Core leanness (14 canonical + 5 cross-module primitives; feedback_v2_asset_catalogue_scope) is load-bearing architectural discipline. Facet classifier classes are lightweight ~2-line shadows — they don’t inflate Core’s conceptual weight, but substantive concepts that semantically belong elsewhere should NOT migrate to Core.

Why

This rule won 100% in three independent scorecards on 2026-04-24:

• R-1’ (role domain-class placement): 100% vs R-1 naïve 92%; 3 refinements including introduction-module rule
• AC-1 (facet classifier placement): 100% vs AC-2 all-Core 74%; introduction-module + Core-fallback (two-rule pattern honestly named per L2 patch)
• W-1’ (Will/Codicil/LegacyLetter boundary): 100% vs W-1 naïve 94%; TestamentaryInstrument abstract parent preserves concept-home

Each scorecard applied the rule to a different structural primitive (roles / facets / testamentary instruments). In each case the rule resolved “where does this live?” without ambiguity + preserved Jackson concept-independence + kept Core lean.

How to apply

• New role needed (e.g. Phase 1.5 surfaces WaqfNazirRole from Islamic waqf governance):

  1. Where is the concept introduced? Trust-governance semantics → Trusts module
  2. Add under inherit-core:Role via rdfs:subClassOf
  3. Include SKOS multilingual annotations + CIDOC CRM E55 Type bridge per R-1’ Refinement 3
  4. No specialisation in Probate just because probate might reference a waqf-nazir

• New facet classifier needed (e.g. Phase 1.5 surfaces HalalStatusClassifier from Islamic asset permissibility):

  1. Which primitive does it attach to? Asset → Assets module; Organisation → Core
  2. If cross-cutting, Core-fallback applies
  3. Scheme values live in schemes/halal-status-scheme.ttl

• New testamentary instrument (e.g. Phase 1.5 surfaces Wasiyya from Islamic):

  1. Where is the concept introduced? Testator-expression in legal-religious tradition → Wills module
  2. Slot as sibling under wills:TestamentaryInstrument parent (formal/informal per Sharia binding-ness)

• When the introduction-module is ambiguous (genuinely multi-module concept; e.g. karta HUF governance in Hindu tradition — Trust-governance-shaped + Delegation-decision-shaped):

  1. Apply Jackson concept-independence: which single purpose dominates? (Karta = HUF-governance per A-2 → Trusts)
  2. If genuinely equal, consult Rich
  3. Document the judgment call in the amendment body + cross-reference

Do NOT

• Centralise all roles / all classifiers in Core “for consistency” (R-2 Core-central lost 92→64% in R-1’ scorecard; AC-2 all-Core lost 100→74% in AC-1)
• Create specialised subclasses in downstream modules without semantic warrant (ProbateExecutorRole was invented and then dropped in R-1’ Refinement 2)
• Mix A-Box (scheme values) into T-Box (module .ttl files) — schemes/*.ttl files are A-Box-only per A-23 vi-6

Phase 1.5 implications

When Phase 1.5 imports v6.6’s 21 extensions, this rule distributes faith-tradition + non-E&W primitives by function, not into one bucket:

Concept	Function	Introduction-module
Islamic wasiyya	Testament execution	Wills
Jewish tzava’ah	Testament execution	Wills
Hindu karta	HUF governance	Trusts
Islamic waqf nazir	Islamic trust governance	Trusts
Jewish hekdesh trustee	Jewish trust governance	Trusts
African clan elder	Customary governance	Trusts
Islamic qadi	Probate adjudication	Probate
Jewish beit din	Probate adjudication	Probate
Islamic wakala	Delegation/agency	Delegation
Jewish shaliaḥ	Delegation/agency	Delegation

No module concentrates all faith-tradition additions; distribution follows function.

Cross-references

• Scorecard R-1’ (docs/superpowers/scoping/2026-04-24-scorecards/r1-prime-scorecard.md) — role placement 100%
• Scorecard AC-1 (docs/superpowers/scoping/2026-04-24-scorecards/ac1-scorecard.md) — facet classifier 100% with two-rule acknowledgement
• Scorecard W-1’ (docs/superpowers/scoping/2026-04-24-scorecards/w1-prime-scorecard.md) — testamentary instrument 100%
• feedback_v2_asset_catalogue_scope.md — Core leanness discipline that introduction-module rule reinforces
• feedback_inherit_v2_international_from_day_one.md — international framing that introduction-module rule supports via function-based Phase 1.5 distribution
• $ref coherence table v1.5+ D3/D6/D4 resolutions — where the rule is applied concretely