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