the-custodian/canon/architecture/adr-006-canon-federation-concept-ownership.md

---
id: ADR-006
type: architecture-decision-record
title: "Canon Federation and Concept Ownership Across InfoTech and Commerce"
status: proposed
decided_by: Bernd Worsch
date: "2026-08-16"
tags: ["architecture", "canon", "concept-ownership", "info-tech-canon", "commerce-canon", "identity", "orthogonality"]
---

# ADR-006: Canon Federation and Concept Ownership Across InfoTech and Commerce

## Status

Proposed. Canon changes are review-gated; this ADR is the review artifact for
the identity/commerce split and must be accepted before content moves.

## 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.**

| Canon | Owns | Repo |
|---|---|---|
| Custodian canon | ecosystem-normative governance: constitution, values, standards, ADRs, charters | `the-custodian/canon/` |
| InfoTechCanon | semantics of information-processing systems | `info-tech-canon` |
| CommerceCanon | counterparty and commercial-relationship semantics | `commerce-canon` |

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` · `Adjudication Outcome` · `Registry Identifier` ·
`Proxy Commercial Identifier` · convenience terms `Reputation`,
`Customer Account`

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.

## Open questions

These are unresolved collisions that must be settled before the affected
concepts move. They are deliberately listed rather than silently decided.

1. **`Scope`.** identity-canon P3 makes it first-class; `itc-access` uses "access
   scope" throughout. Does `itc-ident` own `Scope` with `itc-access` importing,
   or the reverse?
2. **`Assurance Level` vs `itc-gov` `Assurance`.** Specialization or distinct
   concept? `Counterparty Assurance Gradient` builds on whichever wins.
3. **`Evidence Source` vs `itc-gov` `Evidence`.** Likely an `itc-gov`
   specialization rather than an identity-owned concept.
4. **`Relationship Tuple`.** A Zanzibar/OpenFGA-style authorization primitive —
   plausibly `itc-access`, not `itc-ident`.
5. **`Adjudication Outcome` vs `itc-access` `AuthorizationDecision` and `itc-gov`
   `Decision`.** Three candidate owners.
6. **`Community`, `Family Or Household`.** Social collectives absent from
   `itc-org`, which covers enterprise structures (`Team`, `Group`,
   `OrganizationalUnit`). Recommend extending `itc-org` rather than placing them
   in `itc-ident`.

## 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`