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>
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 oninfospace-bench.identity-canon— documentation-only research repo. ThreeIDENTITY-WP-*workplans, allfinished; no substantive work since the commercial-identity research pass. ~60 concepts incanon/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.