Align repository model documentation and governance

Author: raphaelmarra

CHANGELOG.md

@@ -2,6 +2,14 @@
 
 All notable changes to Method Forge are documented here.
 
+## Unreleased
+
+- Added probability, statistics, and inference coverage, including sampling, estimation, testing, regression, hierarchical models, time series, survival, Bayesian analysis, missing data, and reproducibility.
+- Added urban, territorial, and regional planning coverage.
+- Expanded process improvement, evaluation, finance and social value, climate, and health coverage.
+- Documented canonical ownership, secondary routing, and cross-domain composition rules through the taxonomy and architecture decisions.
+- Added catalog-routing regression evidence and strengthened repository validation guidance.
+
 ## 0.1.0 — 2026-08-16
 
 - Established the Method Forge public repository structure.

CONTRIBUTING.md

@@ -16,6 +16,8 @@ For every new or materially changed candidate:
 6. Separate definition/status evidence from effectiveness evidence.
 7. Record the date when volatile status, version, or jurisdiction was checked.
 
+If a method is relevant to more than one catalog, keep one canonical definition and route the secondary use to it. Add a domain specialization only when the estimand, authority, measurement system, validation boundary, or other decision-relevant context changes. Record that ownership and routing decision in the taxonomy or composition patterns when it is not obvious.
+
 Do not copy substantial third-party text. Summarize in original language and link to the source.
 
 ## Adding a domain
@@ -28,6 +30,7 @@ Laws, vendors, datasets, registries, rates, and platform features may constrain
 
 - [ ] The change has one clear purpose.
 - [ ] Terminology is stable and does not duplicate an existing owner.
+- [ ] Any cross-catalog method has one canonical owner and an explicit secondary-routing decision.
 - [ ] Local links resolve.
 - [ ] Volatile claims include a check date.
 - [ ] Proprietary, emerging, contested, and draft material is labeled.

README.md

@@ -4,7 +4,7 @@
 
 Method Forge helps people and AI agents turn underspecified problems into small, defensible method stacks. It distinguishes methodologies from frameworks, standards, techniques, representations, assurance mechanisms, artifacts, and metrics before comparing them.
 
-The repository currently covers 37 domain and cross-domain catalogs, from strategy, software, evidence, statistics, and AI to finance, law, sustainability, supply chains, health, assets, geospatial analysis, and urban planning.
+The repository currently contains 39 reference catalogs: 37 domain and cross-domain catalogs, plus two meta-reference catalogs for taxonomy and source discovery. Coverage ranges from strategy, software, evidence, statistics, and AI to finance, law, sustainability, supply chains, health, assets, geospatial analysis, and urban planning.
 
 ## Why it exists
 

docs/architecture.md

@@ -12,7 +12,7 @@ The root documentation explains purpose, governance, contribution, citation, and
 
 ## Validation boundary
 
-The dependency-free repository validator checks package structure, frontmatter, local links, catalog headings, route integrity, placeholders, and duplicate ownership signals that can be detected mechanically. Human review remains responsible for methodological fit, evidence quality, proportionality, and jurisdiction.
+The dependency-free repository validator checks required package structure, frontmatter, local links, catalog headings, reference count, route integrity, and unresolved TODO markers. Canonical ownership and duplicate-method signals are reviewed through the taxonomy, composition patterns, architecture decisions, contribution checklist, and scenario contracts; the validator does not infer those judgments as facts. Human review also remains responsible for methodological fit, evidence quality, proportionality, and jurisdiction.
 
 ## Evolution
 

docs/index.md

@@ -4,4 +4,4 @@ Method Forge is both a curated methodological knowledge base and an installable
 
 Start with the [repository README](../README.md) for purpose and usage. Read the [architecture](architecture.md) to understand ownership and validation. The operational selection workflow lives in the [`select-methodologies` skill](../skills/select-methodologies/SKILL.md).
 
-Structural decisions are preserved in [`docs/adr`](adr/0001-repository-architecture.md).
+Structural decisions are preserved in the [architecture decision records](adr/).

tests/scenarios/selection-invariants.md

@@ -43,3 +43,9 @@ These scenarios define behavioral expectations for future agent evaluations. The
 **Prompt:** Recommend a complete stack for an auditable public-source investigation.
 
 **Expected invariants:** Every selected fragment must produce a distinct consumed output. The response should remove any element whose absence causes no material loss and preserve verified, rejected, and possible evidence states.
+
+## Repository model organization
+
+**Prompt:** Add or revise a method that could be relevant to more than one domain catalog.
+
+**Expected invariants:** Keep one canonical method definition, route secondary uses to that owner, and add a specialization only when the decision-relevant context changes. Update the relevant taxonomy or composition guidance, preserve a rationale in an ADR when the ownership boundary changes, and keep the dependency-free validator passing.