Canon Federation and Concept Ownership Across InfoTech and Commerce

Status

Accepted 2026-08-17. All seven ownership questions are resolved (see Resolutions); content may now move under CFED-WP-0001.

Context

The ecosystem currently runs two independent canons in the same market domain (infotech), with no cross-reference in either direction:

• info-tech-canon — InfoTechCanon, v0.6.0, status service-baseline. Kernel + 12 models + 3 standards, with declared concept ownership per model, an orthogonality rule ("standards can import but not redefine each other"), and a live CLI/JSON/API surface built on infospace-bench.
• identity-canon — documentation-only research repo, category research. Three IDENTITY-WP-* workplans, all finished; no active work since the commercial-identity research pass. ~60 concepts in canon/CanonicalGlossary.md.

Two problems follow.

Concept-ownership collision. InfoTechCanonOrganizationModel (:55) declares ownership of Actor, Person, Organization, OrganizationalUnit, Team, Group, Role, Position, Membership, Assignment, Responsibility, Authority, Accountability. InfoTechCanonAccessControlModel (:106) declares Subject, Principal, AccessRole, Permission, .... identity-canon independently defines Actor, Natural Person, Collective Actor, Organization, Group, Role, Membership Relationship, Authenticated Subject, Authorization Principal. Two canons claim the same concepts — exactly what InfoTechCanon's orthogonality rule exists to prevent.

An unowned gap. InfoTechCanonAccessControlModel (:214, "Boundary with Identity and Authentication") explicitly pushes identity provisioning, authentication factors, 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, Assurance Level belong to no model at all.

Business semantics are accumulating in the wrong places. Roughly a third of identity-canon's glossary is not identity but counterparty/commercial modelling (Legal Entity, Beneficial Owner, Customer, Vendor, Commercial Commitment, Payment Mandate, Pipeline Pursuit, Counterparty Assurance Gradient, ...) — hence the repo's government secondary domain. Independently, info-tech-canon/demand/CapabilityProvisionEconomics.md (status 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 technical canon is a domain boundary, not a coincidence. InfoTechCanon's own Purpose/Demand extension names this ScopePressure.

Decision

1. Three canons, federated by declared ownership.

Canons import but do not redefine each other's concepts, applying InfoTechCanon's existing orthogonality rule one level up.

2. identity-canon is renamed to commerce-canon, in place. Git history, State Hub registration, .repo-classification.yaml, and the finished IDENTITY-WP-* workplans are retained as provenance for the commercial content that stays. Identity content emigrates; nothing is archived. Structure follows info-tech-canon (canon.yaml, infospace/ with kernel/models/standards, assimilation/, mappings/, profiles/) per InfoTechCanonRepositoryLayoutStandard.

3. Identity becomes an InfoTechCanon model, at infospace/models/identity/InfoTechCanonIdentityModel.md (itc-ident), importing rather than redefining upstream concepts. This fills the gap InfoTechCanonAccessControlModel:214 leaves open.

4. Concept ownership is assigned as follows.

Imported by itc-ident, owned by itc-org: Actor · Natural Person → Person · Artificial Agent → Agent · Organization · Group · Role · Membership Relationship → Membership

Imported by itc-ident, owned by itc-access: Authenticated Subject → Subject · Authorization Principal → Principal

This follows identity-canon's own design principles: P1 makes Actor the participation root (owned upstream by itc-org), and P6 "Keep Authorization Projections Separate" already treats subject/principal as projections rather than identity-owned definitions.

Owned by itc-ident (new): Account · Service Account · Identity Record · Identifier · Scoped Identifier · Pseudonymous Identifier · Credential · Claim · Profile · Persona · Tenant · Realm · Synonymity Assertion · Lifecycle State · the actor-linking relationship taxonomy (Relationship, Affiliation, Following, Representation, Delegation, Administration, Trust) · convenience terms User, Subscriber

Owned by commerce-canon: Legal Entity · Legal Person · Beneficial Owner · Beneficial Ownership Relationship · Beneficial Ownership Exemption · Customer · Vendor · Commercial Relationship · Commercial Commitment · Payment Instrument Reference · Payment Mandate · Pipeline Pursuit · Commercial Record · Counterparty Assurance Gradient · Reputation Signal · Performance Evidence · Registry Identifier · Proxy Commercial Identifier · convenience terms Reputation, Customer Account

Owned by itc-evid, the evidence model (see R3, R5, R7): Evidence · Evidence Source · Adjudication Outcome

Identifier subtypes demonstrate the intended pattern: itc-ident owns Identifier; commerce-canon owns Registry Identifier and Proxy Commercial Identifier as specializations of it.

5. CommerceCanon grows by demand signal, not speculative authoring. New content enters through the mechanism InfoTechCanon already runs — a demand signal with named consumer evidence (see demand/). Plausible future consumers (fin-hub, target-revenue, adaptive-pricing, qonto-assistant) must pull; the canon does not push.

6. The Federated Organization Standard stays in Custodian canon. canon/standards/federated-organization-standard_v1.0.md is ecosystem-normative organizational architecture, human-gated — not commercial vocabulary. If it ever moves, it becomes an InfoTechCanon organization standard, not a CommerceCanon one.

Resolutions

The six collisions listed at draft time, resolved 2026-08-17. Two were settled by evidence already present in the models rather than by argument.

R1 — Scope: owned by itc-ident. There is no head-on collision: itc-access owns ResourceScope (:717, "the boundary within which access applies"), a narrower concept, not a general Scope. itc-ident owns the general concept, keeping it with Tenant and Realm — Tenant is defined as "an administrative or isolation scope", so separating it from its genus would split a definition from the concept it depends on. itc-access keeps ResourceScope as a refinement.

If landscape or information-space later need general scoping, promote Scope to the kernel on that demand signal, not pre-emptively.

R2 — Assurance Level: owned by itc-ident, distinct from governance assurance. A false collision. itc-gov owns AssuranceCase (:1178, a structured argument that a claim is justified) and AssuranceConclusion (:1184). identity's Assurance Level is NIST SP 800-63-4 IAL/AAL/FAL — graded confidence metadata on credentials, bindings, and federation assertions. They share an English word and nothing else. Both models carry a disambiguation note, because the word will keep causing this.

Design principle P12 ("Distinguish Assurance Dimensions") carries over: IAL, AAL, and FAL must not be collapsed into a single "trust level" on an account.

R3 — Evidence and Evidence Source are a general pair, owned together, and not by commerce. They are not competing definitions of one concept:

• Evidence Source — an addressable information container: a document, file, or other artifact identifiable by URI.
• Evidence — a distinct information item, textual or descriptive, drawn from a source: a quotation, an extracted value, a specific assertion.

Both may carry commentary. Which evidence is captured from a source depends on the interest being served.

Worked example: an invoice PDF is an Evidence Source; the amount, the issuer, and the due date are separate Evidence items within it. The common electronic- invoicing pattern of an XML embedding inside a signed PDF is exactly this structure — evidence pre-extracted and bound to its source so the extraction is itself tamper-evident.

The pair is domain-neutral (it extends to criminal, regulatory, and scientific evidence). Commerce, identity, and governance all use it; none owns it. Consequently itc-gov no longer owns Evidence; it imports it.

R4 — Relationship Tuple: owned by itc-access. Already modelled there (:549, under PolicyEvaluationEntity beside AuthorizationRequest, AuthorizationDecision, DecisionReason, EvaluationContext). identity-canon's own entry agrees: "Relationship tuples are not canonical identity roots. They project from actors, accounts, memberships, and delegations into authorization domains." itc-ident must not define it.

R5 — Adjudication Outcome: follows R3, owned with the evidence pair. Not itc-access AuthorizationDecision (a PDP allow/deny, :907) and not itc-gov Decision (a governance choice point). The concept is general rather than commercial: an arbitration award, court judgment, or regulatory consent order is evidence in employment, licensing, or compliance disputes as much as in commercial ones. Commerce is a consumer, not the owner.

Structurally it is Evidence — the outcome asserted — sourced from an Evidence Source such as the judgment document.

The assurance_tier dimension splits accordingly: the evidence model owns a general evidence-strength dimension; commerce-canon owns the Counterparty Assurance Gradient as its named four-tier application of it.

R6 — Community and Household extend itc-org; Family is a separate concept area. identity-canon defines "Family Or Household" as one entry. That conflation is rejected.

Community and Household are collective actors and slot under itc-org's existing CollectiveActor (:363, beside Person, HumanActor, NonHumanActor), honouring P4 ("Model Collective Actors Without Collapsing Them").

Family does not. Family carries substantial structure — kinship, guardianship, dependency, care, and legal, biological, and social parenthood — which changes over time and is subject to interpretation. Modelling it as one more collective actor is the specific mistake most family-oriented software makes, and it is why such software generally models families badly. It gets its own concept area.

Scope discipline applies: the family area is seeded, not authored. Record the concept, the privacy sensitivity already flagged in identity-canon ("may have legal implications outside the canon's scope"), and the open modelling questions. Do not build it out inside CFED-WP-0001; it grows on demand signal like any other canon content.

R7 — the evidence pair lives in a dedicated model, itc-evid. A new InfoTechCanon model at infospace/models/evidence/ owns Evidence, Evidence Source, Adjudication Outcome, and the general evidence-strength dimension.

itc-gov, itc-ident, and commerce-canon import it. Three named consumers existed before the model did, which is the demand signal the canon requires.

Rejected alternative: leaving both with itc-gov as incumbent owner of Evidence. That is cheaper and preserves the locality of the Policy-Control-Evidence chain pattern (:1391), but it would force identity and commerce to import "governance" in order to describe an invoice line item — mis-signalling evidence as a governance sub-topic when it is domain-neutral.

itc-gov retains AssuranceCase, AssuranceConclusion, Audit, and the Policy-Control-Evidence pattern, now expressed over imported evidence concepts.

Consequences

Positive. Every concept gains exactly one owner. The identity gap that itc-access explicitly declines is filled. Commercial semantics get a home before they accrete further into technical canon. A dormant research repo with no inbound references becomes a canon with declared consumers. A second canon tests whether InfoTechCanonRepositoryLayoutStandard is a real standard or merely InfoTechCanon's own shape described back to itself.

Negative. This is a concept-ownership reconciliation, not a file move: the first ~15 glossary entries must be rewritten as imports. Three canons cost more coordination than one. The identity-canon name disappears from tooling, bookmarks, and any external reference.

Risks. CommerceCanon could repeat identity-canon's failure mode — dormant, zero consumers, drifting — if it launches as a scaffold. Mitigated by decision 2 (it opens holding real, research-backed content) and decision 5 (growth requires consumer evidence).

References

• ADR-001 — workplans originate as repo files; hub is a read model
• ADR-005 — cross-repo workplans live in dedicated project repos
• info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md:55
• info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md:106, :214
• info-tech-canon/infospace/models/governance/InfoTechCanonGovernanceModel.md:107
• info-tech-canon/demand/CapabilityProvisionEconomics.md
• identity-canon/canon/CanonicalGlossary.md, canon/DesignPrinciples.md