<divclass="wrap"><header><divclass="eyebrow"><span>CUST-ADR-006</span><spanclass="stat">accepted · accepted-1</span><span>the-custodian</span><span>reviewed 2026-08-17</span><span>generated from canonical source — do not edit</span></div><h1>Canon Federation and Concept Ownership Across InfoTech and Commerce</h1><pclass="sub">Source: <code>the-custodian · canon/architecture/adr-006-canon-federation-concept-ownership.md · f9435cd605cc5b3cb0f2e957ce6287d9f3129aac</code></p><pclass="sub">Review due: 2027-02-17</p></header><divclass="layout"><navclass="rail"aria-label="Sections"><ol><li><ahref="#status"><spanclass="n">·</span>Status</a></li><li><ahref="#context"><spanclass="n">·</span>Context</a></li><li><ahref="#decision"><spanclass="n">·</span>Decision</a></li><li><ahref="#resolutions"><spanclass="n">·</span>Resolutions</a></li><li><ahref="#consequences"><spanclass="n">·</span>Consequences</a></li><li><ahref="#references"><spanclass="n">·</span>References</a></li></ol></nav><main><sectionid="status"><h2>Status</h2>
<p>Accepted 2026-08-17. All seven ownership questions are resolved (see Resolutions); content may now move under <code>CFED-WP-0001</code>.</p>
</section>
<sectionid="context"><h2>Context</h2>
<p>The ecosystem currently runs two independent canons in the same market domain (<code>infotech</code>), with <strong>no cross-reference in either direction</strong>:</p>
<ul><li><code>info-tech-canon</code> — InfoTechCanon, v0.6.0, status <code>service-baseline</code>. 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 <code>infospace-bench</code>.</li><li><code>identity-canon</code> — documentation-only research repo, category <code>research</code>. Three <code>IDENTITY-WP-*</code> workplans, all <code>finished</code>; no active work since the commercial-identity research pass. ~60 concepts in <code>canon/CanonicalGlossary.md</code>.</li></ul>
<p>Two problems follow.</p>
<p><strong>Concept-ownership collision.</strong><code>InfoTechCanonOrganizationModel</code> (<code>:55</code>) declares ownership of <code>Actor, Person, Organization, OrganizationalUnit, Team, Group, Role, Position, Membership, Assignment, Responsibility, Authority, Accountability</code>. <code>InfoTechCanonAccessControlModel</code> (<code>:106</code>) declares <code>Subject, Principal, AccessRole, Permission, ...</code>. identity-canon independently defines <code>Actor, Natural Person, Collective Actor, Organization, Group, Role, Membership Relationship, Authenticated Subject, Authorization Principal</code>. Two canons claim the same concepts — exactly what InfoTechCanon's orthogonality rule exists to prevent.</p>
<p><strong>An unowned gap.</strong><code>InfoTechCanonAccessControlModel</code> (<code>:214</code>, "Boundary with Identity and Authentication") explicitly pushes identity provisioning, authentication factors, identity proofing, and account lifecycle out of scope, and <code>:41</code> does the same for generic organization modelling. So <code>Account, Identity Record, Identifier, Credential, Claim, Persona, Tenant, Realm, Synonymity Assertion, Assurance Level</code> belong to no model at all.</p>
<p><strong>Business semantics are accumulating in the wrong places.</strong> Roughly a third of identity-canon's glossary is not identity but counterparty/commercial modelling (<code>Legal Entity, Beneficial Owner, Customer, Vendor, Commercial Commitment, Payment Mandate, Pipeline Pursuit, Counterparty Assurance Gradient, ...</code>) — hence the repo's <code>government</code> secondary domain. Independently, <code>info-tech-canon/demand/CapabilityProvisionEconomics.md</code> (status <code>accepted</code>, 2026-08-15) records procurement and economics demand arriving in <code>ITC-CAP</code> from consumer <code>resource-control</code>, domain <code>financials</code>. Two unrelated donors pushing commercial semantics into technical canon is a domain boundary, not a coincidence. InfoTechCanon's own Purpose/Demand extension names this <code>ScopePressure</code>.</p>
</section>
<sectionid="decision"><h2>Decision</h2>
<p><strong>1. Three canons, federated by declared ownership.</strong></p>
<divclass="scroll"><table><thead><tr><th>Canon</th><th>Owns</th><th>Repo</th></tr></thead><tbody><tr><td>Custodian canon</td><td>ecosystem-normative governance: constitution, values, standards, ADRs, charters</td><td><code>the-custodian/canon/</code></td></tr><tr><td>InfoTechCanon</td><td>semantics of information-processing systems</td><td><code>info-tech-canon</code></td></tr><tr><td>CommerceCanon</td><td>counterparty and commercial-relationship semantics</td><td><code>commerce-canon</code></td></tr></tbody></table></div>
<p>Canons import but do not redefine each other's concepts, applying InfoTechCanon's existing orthogonality rule one level up.</p>
<p><strong>2. <code>identity-canon</code> is renamed to <code>commerce-canon</code>, in place.</strong> Git history, State Hub registration, <code>.repo-classification.yaml</code>, and the finished <code>IDENTITY-WP-*</code> workplans are retained as provenance for the commercial content that stays. Identity content emigrates; nothing is archived. Structure follows <code>info-tech-canon</code> (<code>canon.yaml</code>, <code>infospace/</code> with kernel/models/standards, <code>assimilation/</code>, <code>mappings/</code>, <code>profiles/</code>) per <code>InfoTechCanonRepositoryLayoutStandard</code>.</p>
<p><strong>3. Identity becomes an InfoTechCanon model</strong>, at <code>infospace/models/identity/InfoTechCanonIdentityModel.md</code> (<code>itc-ident</code>), importing rather than redefining upstream concepts. This fills the gap <code>InfoTechCanonAccessControlModel:214</code> leaves open.</p>
<p><strong>4. Concept ownership is assigned as follows.</strong></p>
<p><em>Imported by <code>itc-ident</code>, owned by <code>itc-access</code>:</em><code>Authenticated Subject</code> → <code>Subject</code> · <code>Authorization Principal</code> → <code>Principal</code></p>
<p>This follows identity-canon's own design principles: P1 makes <code>Actor</code> the participation root (owned upstream by <code>itc-org</code>), and P6 "Keep Authorization Projections Separate" already treats subject/principal as projections rather than identity-owned definitions.</p>
<p><em>Owned by <code>itc-evid</code>, the evidence model (see R3, R5, R7):</em><code>Evidence</code> · <code>Evidence Source</code> · <code>Adjudication Outcome</code></p>
<p>Identifier subtypes demonstrate the intended pattern: <code>itc-ident</code> owns <code>Identifier</code>; <code>commerce-canon</code> owns <code>Registry Identifier</code> and <code>Proxy Commercial Identifier</code> as specializations of it.</p>
<p><strong>5. CommerceCanon grows by demand signal, not speculative authoring.</strong> New content enters through the mechanism InfoTechCanon already runs — a demand signal with named consumer evidence (see <code>demand/</code>). Plausible future consumers (<code>fin-hub</code>, <code>target-revenue</code>, <code>adaptive-pricing</code>, <code>qonto-assistant</code>) must pull; the canon does not push.</p>
<p><strong>6. The Federated Organization Standard stays in Custodian canon.</strong><code>canon/standards/federated-organization-standard_v1.0.md</code> is ecosystem-normative organizational architecture, human-gated — not commercial vocabulary. If it ever moves, it becomes an InfoTechCanon organization standard, not a CommerceCanon one.</p>
</section>
<sectionid="resolutions"><h2>Resolutions</h2>
<p>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.</p>
<p><strong>R1 — <code>Scope</code>: owned by <code>itc-ident</code>.</strong> There is no head-on collision: <code>itc-access</code> owns <code>ResourceScope</code> (<code>:717</code>, "the boundary within which access applies"), a narrower concept, not a general <code>Scope</code>. <code>itc-ident</code> owns the general concept, keeping it with <code>Tenant</code> and <code>Realm</code> — <code>Tenant</code> is defined as "an administrative or isolation scope", so separating it from its genus would split a definition from the concept it depends on. <code>itc-access</code> keeps <code>ResourceScope</code> as a refinement.</p>
<p>If <code>landscape</code> or <code>information-space</code> later need general scoping, promote <code>Scope</code> to the kernel <strong>on that demand signal</strong>, not pre-emptively.</p>
<p><strong>R2 — <code>Assurance Level</code>: owned by <code>itc-ident</code>, distinct from governance assurance.</strong> A false collision. <code>itc-gov</code> owns <code>AssuranceCase</code> (<code>:1178</code>, a structured argument that a claim is justified) and <code>AssuranceConclusion</code> (<code>:1184</code>). identity's <code>Assurance Level</code> 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.</p>
<p>Design principle P12 ("Distinguish Assurance Dimensions") carries over: IAL, AAL, and FAL must not be collapsed into a single "trust level" on an account.</p>
<p><strong>R3 — <code>Evidence</code> and <code>Evidence Source</code> are a general pair, owned together, and not by commerce.</strong> They are not competing definitions of one concept:</p>
<ul><li><strong>Evidence Source</strong> — an addressable information container: a document, file, or other artifact identifiable by URI.</li><li><strong>Evidence</strong> — a distinct information item, textual or descriptive, drawn from a source: a quotation, an extracted value, a specific assertion.</li></ul>
<p>Both may carry commentary. Which evidence is captured from a source depends on the interest being served.</p>
<p>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.</p>
<p>The pair is domain-neutral (it extends to criminal, regulatory, and scientific evidence). Commerce, identity, and governance all <strong>use</strong> it; none owns it. Consequently <code>itc-gov</code> no longer owns <code>Evidence</code>; it imports it.</p>
<p><strong>R4 — <code>Relationship Tuple</code>: owned by <code>itc-access</code>.</strong> Already modelled there (<code>:549</code>, under <code>PolicyEvaluationEntity</code> beside <code>AuthorizationRequest</code>, <code>AuthorizationDecision</code>, <code>DecisionReason</code>, <code>EvaluationContext</code>). identity-canon's own entry agrees: "Relationship tuples are not canonical identity roots. They project from actors, accounts, memberships, and delegations into authorization domains." <code>itc-ident</code> must not define it.</p>
<p><strong>R5 — <code>Adjudication Outcome</code>: follows R3, owned with the evidence pair.</strong> Not <code>itc-access</code><code>AuthorizationDecision</code> (a PDP allow/deny, <code>:907</code>) and not <code>itc-gov</code><code>Decision</code> (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.</p>
<p>Structurally it is <strong>Evidence</strong> — the outcome asserted — sourced from an Evidence Source such as the judgment document.</p>
<p>The <code>assurance_tier</code> dimension splits accordingly: the evidence model owns a general evidence-strength dimension; <code>commerce-canon</code> owns the <code>Counterparty Assurance Gradient</code> as its named four-tier application of it.</p>
<p><strong>R6 — <code>Community</code> and <code>Household</code> extend <code>itc-org</code>; <code>Family</code> is a separate concept area.</strong> identity-canon defines "Family Or Household" as one entry. That conflation is rejected.</p>
<p><code>Community</code> and <code>Household</code> are collective actors and slot under <code>itc-org</code>'s existing <code>CollectiveActor</code> (<code>:363</code>, beside <code>Person</code>, <code>HumanActor</code>, <code>NonHumanActor</code>), honouring P4 ("Model Collective Actors Without Collapsing Them").</p>
<p><code>Family</code> 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.</p>
<p>Scope discipline applies: the family area is <strong>seeded, not authored</strong>. 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 <code>CFED-WP-0001</code>; it grows on demand signal like any other canon content.</p>
<p><strong>R7 — the evidence pair lives in a dedicated model, <code>itc-evid</code>.</strong> A new InfoTechCanon model at <code>infospace/models/evidence/</code> owns <code>Evidence</code>, <code>Evidence Source</code>, <code>Adjudication Outcome</code>, and the general evidence-strength dimension.</p>
<p><code>itc-gov</code>, <code>itc-ident</code>, and <code>commerce-canon</code> import it. Three named consumers existed before the model did, which is the demand signal the canon requires.</p>
<p>Rejected alternative: leaving both with <code>itc-gov</code> as incumbent owner of <code>Evidence</code>. That is cheaper and preserves the locality of the Policy-Control-Evidence chain pattern (<code>:1391</code>), 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.</p>
<p><code>itc-gov</code> retains <code>AssuranceCase</code>, <code>AssuranceConclusion</code>, <code>Audit</code>, and the Policy-Control-Evidence pattern, now expressed over imported evidence concepts.</p>
</section>
<sectionid="consequences"><h2>Consequences</h2>
<p><strong>Positive.</strong> Every concept gains exactly one owner. The identity gap that <code>itc-access</code> 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 <code>InfoTechCanonRepositoryLayoutStandard</code> is a real standard or merely InfoTechCanon's own shape described back to itself.</p>
<p><strong>Negative.</strong> 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 <code>identity-canon</code> name disappears from tooling, bookmarks, and any external reference.</p>
<p><strong>Risks.</strong> 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).</p>
</section>
<sectionid="references"><h2>References</h2>
<ul><li>ADR-001 — workplans originate as repo files; hub is a read model</li><li>ADR-005 — cross-repo workplans live in dedicated project repos</li><li><code>info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md:55</code></li><li><code>info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md:106</code>, <code>:214</code></li><li><code>info-tech-canon/infospace/models/governance/InfoTechCanonGovernanceModel.md:107</code></li><li><code>info-tech-canon/demand/CapabilityProvisionEconomics.md</code></li><li><code>identity-canon/canon/CanonicalGlossary.md</code>, <code>canon/DesignPrinciples.md</code></li></ul>
