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

---
id: CUST-ADR-006
type: architecture-decision-record
title: "Canon Federation and Concept Ownership Across InfoTech and Commerce"
status: accepted
owner: the-custodian
revision: "accepted-1"
last_reviewed: "2026-08-17"
review_interval: 6m
decided_by: Bernd Worsch
date: "2026-08-16"
accepted: "2026-08-17"
tags: ["architecture", "canon", "concept-ownership", "info-tech-canon", "commerce-canon", "identity", "orthogonality"]
---

# ADR-006: 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.**

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