Scaffold prj-canon-federation per project-repository-flavor v0.1

GOAL.md (8 success gates + retirement conditions), SCOPE.md (authority
boundary, participating repos), README.md, .repo-classification.yaml
(category: project), genesis record, and CFED-WP-0001 foundation workplan
(T01-T10).

Governed by ADR-006 (the-custodian, status: proposed). No canon content
moves before T01 accepts the boundary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

history/2026-08-16-genesis.md

@@ -0,0 +1,83 @@
+# Genesis — 2026-08-16
+
+## Why this project exists
+
+The ecosystem was running two independent canons in the same market domain
+(`infotech`) with **no cross-reference in either direction**:
+
+- `info-tech-canon` — InfoTechCanon v0.6.0, `service-baseline`. Kernel, 12
+  models, 3 standards, declared per-model concept ownership, an orthogonality
+  rule ("standards can import but not redefine each other"), and a live
+  CLI/JSON/API surface on `infospace-bench`.
+- `identity-canon` — documentation-only research repo. Three `IDENTITY-WP-*`
+  workplans, all `finished`; no substantive work since the commercial-identity
+  research pass. ~60 concepts in `canon/CanonicalGlossary.md`.
+
+Three findings drove the decision.
+
+**Concept-ownership collision.** `InfoTechCanonOrganizationModel:55` owns
+`Actor, Person, Organization, Group, Role, Membership, ...`;
+`InfoTechCanonAccessControlModel:106` owns `Subject, Principal, ...`.
+identity-canon independently defined all of them. Precisely what InfoTechCanon's
+orthogonality rule exists to prevent.
+
+**An unowned gap.** `InfoTechCanonAccessControlModel:214` explicitly pushes
+identity provisioning, authentication, identity proofing, and account lifecycle
+out of scope, and `:41` does the same for generic organization modelling. So
+`Account`, `Identity Record`, `Identifier`, `Credential`, `Claim`, `Persona`,
+`Tenant`, `Realm`, `Synonymity Assertion` belonged to no model at all.
+
+**Commercial semantics accumulating in technical canon.** About a third of
+identity-canon's glossary is counterparty/commercial modelling, not identity —
+hence its `government` secondary domain. Independently,
+`info-tech-canon/demand/CapabilityProvisionEconomics.md` (accepted 2026-08-15)
+records procurement and economics demand arriving in `ITC-CAP` from consumer
+`resource-control`, domain `financials`. Two unrelated donors pushing commercial
+semantics into a technical canon is a domain boundary, not a coincidence.
+InfoTechCanon's own Purpose/Demand extension names this `ScopePressure`.
+
+## What was decided
+
+`ADR-006` (Custodian canon, status `proposed` at genesis): three federated
+canons — Custodian (ecosystem governance), InfoTech (information-processing
+semantics), Commerce (counterparty and commercial semantics) — importing but
+never redefining each other.
+
+Two shaping choices are worth recording, because both were revisions of an
+earlier plan:
+
+**Rename in place, don't found-and-archive.** The first proposal was to create a
+new `commerce-canon` repo and archive `identity-canon`. Renaming instead keeps
+git history, hub registration, `.repo-classification.yaml` lineage, and the
+three finished workplans attached to the commercial content that *stays*. Only
+identity emigrates. One repo changes name, one gains a model, nothing is
+archived.
+
+**Name it for commerce, not for "business terms".** The working name was
+`business-terms-canon`. "Terms" advertises a glossary, and an open-ended
+glossary is the failure mode — it invites every business-flavoured word in the
+ecosystem to land there with no ownership discipline. The real content is
+counterparty and commercial-relationship semantics with a KYC/AML/procurement
+driver, so the canon is named for that.
+
+## What the boundary rests on
+
+Two of the collisions were resolved by identity-canon's *own* design principles
+rather than by new argument: P1 ("Use Actor As The Participation Root") requires
+importing `itc-org`'s `Actor`; P6 ("Keep Authorization Projections Separate")
+already treats `Authenticated Subject` / `Authorization Principal` as
+projections rather than identity-owned definitions. The boundary largely wrote
+itself from principles already agreed inside the research repo.
+
+Six collisions were **not** resolved at genesis and are listed as open questions
+in `ADR-006` — `Scope`, `Assurance Level`, `Evidence Source`, `Relationship
+Tuple`, `Adjudication Outcome`, and the placement of `Community` / `Family Or
+Household`. Resolving them is the first task of `CFED-WP-0001`.
+
+## Risk being managed
+
+CommerceCanon could repeat identity-canon's failure mode: dormant, zero
+consumers, drifting. Two mitigations are built into the design — it launches
+holding real research-backed content rather than as an empty scaffold, and it
+grows only by demand signal with named consumer evidence, the mechanism
+InfoTechCanon already runs.