prj-canon-federation/history/2026-08-16-genesis.md
tegwick 45e7e6d352 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>
2026-08-16 02:39:37 +02:00

4.3 KiB

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-006Scope, 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.