canon: distinguish sector domains from project identity

canon/standards/contrib-templates/br-template.md

@@ -5,7 +5,7 @@ target_org: <github-org-or-owner>
 target_repo: <repository-name>
 title: "Short description of the bug"
 status: draft
-domain: custodian   # change to your domain
+domain: infotech    # select an allowed sector domain; do not use a legacy project name
 related_workstream: null
 state_hub_contribution_id: null
 created: "YYYY-MM-DD"

canon/standards/contrib-templates/ep-template.md

@@ -6,7 +6,7 @@ target_org: <github-org-or-owner>
 target_repo: <repository-name>
 title: "Short description of the extension point"
 status: draft
-domain: custodian   # change to your domain
+domain: infotech    # select an allowed sector domain; do not use a legacy project name
 related_workstream: null
 state_hub_contribution_id: null
 created: "YYYY-MM-DD"

canon/standards/contrib-templates/fr-template.md

@@ -5,7 +5,7 @@ target_org: <github-org-or-owner>
 target_repo: <repository-name>
 title: "Short description of the requested feature"
 status: draft
-domain: custodian   # change to your domain
+domain: infotech    # select an allowed sector domain; do not use a legacy project name
 related_workstream: null
 state_hub_contribution_id: null
 created: "YYYY-MM-DD"

canon/standards/contrib-templates/upr-template.md

@@ -5,7 +5,7 @@ target_org: <github-org-or-owner>
 target_repo: <repository-name>
 title: "Short description of the upstream PR"
 status: draft
-domain: custodian   # change to your domain
+domain: infotech    # select an allowed sector domain; do not use a legacy project name
 related_workstream: null
 state_hub_contribution_id: null
 created: "YYYY-MM-DD"

canon/standards/contribution-convention_v0.1.md

@@ -65,7 +65,7 @@ target_org: <github-org-or-owner>                  # required
 target_repo: <repository-name>                     # required
 title: "Human-readable title"                      # required
 status: draft | submitted | acknowledged | accepted | rejected | merged | withdrawn
-domain: custodian | railiance | markitect | ...    # originating domain
+domain: infotech | agents | communication | ...   # current sector domain; see Repo Classification Standard §6
 related_workstream: <workstream-slug>              # optional
 state_hub_contribution_id: <uuid>                  # set once registered in State Hub
 created: "YYYY-MM-DD"

canon/standards/repo-classification-standard_v1.0.md

@@ -388,6 +388,24 @@ secondary_domains:
 | `space` | Space industry, satellites, orbital systems, launch, space logistics, space simulation. |
 | `government` | B2G, civic infrastructure, public administration, procurement, citizen services, regulation-facing systems. |
 
+### 6.3 Legacy Project Identities Are Not Domain Aliases
+
+The older labels `custodian`, `railiance`, `markitect`, `coulomb_social`,
+`personhood`, `foerster_capabilities`, and `netkingdom` identify projects,
+estates, or bodies of canon. They are not allowed values for
+`repo_classification.domain` and MUST NOT be mechanically translated as if
+each named project served one market sector.
+
+Keep those identities in project titles, topics, architecture, provenance,
+and historical records. Classify each repository by the user/customer rule in
+§6.1. A project can legitimately contain repos in different sectors: for
+example, a Railiance platform repo can be `infotech`, while a rail-operations
+product can be `industrials`.
+
+Migration review seeds and the live 2026-08-23 fleet baseline are recorded in
+`docs/repo-classification-sector-migration-baseline-2026-08-23.md`. Its mapping
+table is a triage aid, not an automatic rewrite rule.
+
 ---
 
 ## 7. Capability Tags

tools/validate_repo_classification.py

@@ -163,10 +163,22 @@ def self_test(allowed: dict) -> bool:
             "business_mechanics": ["teleportation"],
         }
     }
+    legacy_project_as_domain = {
+        "repo_classification": {
+            "category": "research",
+            "domain": "custodian",
+        }
+    }
     ge, _ = validate(good, allowed)
     be, _ = validate(bad, allowed)
-    ok = (ge == []) and (len(be) >= 5)
+    le, _ = validate(legacy_project_as_domain, allowed)
-    print(f"self-test: good_errors={len(ge)} bad_errors={len(be)} -> {'PASS' if ok else 'FAIL'}")
+    legacy_rejected = any("`domain` 'custodian' not in allowed domains" in error for error in le)
+    ok = (ge == []) and (len(be) >= 5) and legacy_rejected
+    print(
+        "self-test: "
+        f"good_errors={len(ge)} bad_errors={len(be)} "
+        f"legacy_project_domain_rejected={legacy_rejected} -> {'PASS' if ok else 'FAIL'}"
+    )
     return ok
 
 

workplans/CUST-WP-0065-reclassify-repos-and-guidance-docs-to-the-new-sector-domain.md

@@ -51,7 +51,7 @@ when the answer is ambiguous.
 
 ```task
 id: CUST-WP-0065-T02
-status: todo
+status: done
 priority: medium
 ```
 
@@ -61,6 +61,13 @@ historical project names and canon references intact. Add a validation example
 that rejects legacy names in `repo_classification.domain` while allowing them
 as project/topic identity.
 
+**Done (2026-08-23):** the active Repo Classification Standard now explicitly
+separates legacy project/estate identities from sector-domain metadata and
+links the governed migration baseline. The contribution convention and all
+four contribution templates now show current sector values. The classification
+validator self-test proves `custodian` is rejected as a classification domain;
+project names remain valid outside that field.
+
 ## Repair source records and authoritative projection
 
 ```task
@@ -109,7 +116,7 @@ path can bind them.
 
 - [x] Live missing-classification baseline is reproducible and split by cause
 - [x] Legacy project identity is distinguished from sector-domain metadata
-- [ ] Canonical and agent-facing migration guidance is current
+- [x] Canonical and agent-facing migration guidance is current
 - [ ] Missing source classifications are owner-reviewed and validated
 - [ ] Present source classifications project into State Hub
 - [ ] Active fleet has zero unexplained null category projections