84 lines
4.3 KiB
Markdown
84 lines
4.3 KiB
Markdown
|
# 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.
|