policy-nexus/build/adr/custodian-canon-federation/v1/index.html
tegwick 25dd59a7c6
Some checks failed
Build and publish policy-nexus image / build-and-push (push) Failing after 48s
Publish estate ADRs, platform ADRs, and IAM Profile v0.3
T04 classifies the remaining corpus. Chapter 9 on the first-wave
arc42 stubs now matches what is published.
2026-08-19 01:09:41 +02:00

253 lines
32 KiB
HTML

<!doctype html>
<html lang="en"><meta charset="utf-8">
<meta name="policy-source-revision" content="4039c9d1c08c92014ecc0a65dda63cc73ba187bb">
<meta name="policy-source-digest" content="a454df0e1d227f99ebb36c4abd45c76cc12579086d34f0c0ccfccfd7f4790823">
<title>Canon Federation and Concept Ownership Across InfoTech and Commerce</title>
<style>
:root{
--paper:#EDEEF0; --surface:#F6F7F8; --surface-2:#E4E6E9;
--ink:#171D24; --ink-2:#4A5561; --ink-3:#737E8A;
--rule:#D3D7DC; --rule-strong:#B6BCC3;
--brass:#8A6A2E; --brass-soft:#EFE5CD; --brass-line:#C9AE74;
--clay:#8A3A2C; --clay-soft:#F2DFDA;
--l0:#DCE0E2; --l1:#B9C4C7; --l2:#8CA1A6; --l3:#567D84; --l4:#23555E;
--chip-fg:#F6F7F8;
--font-display:ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,"Helvetica Neue",sans-serif;
--font-body:"Iowan Old Style","Palatino Linotype",Palatino,Georgia,serif;
--font-mono:ui-monospace,"SF Mono","Cascadia Code",Menlo,Consolas,monospace;
--measure:66ch;
}
@media (prefers-color-scheme:dark){
:root:not([data-theme="light"]){
--paper:#12161A; --surface:#191E24; --surface-2:#222831;
--ink:#E6E9EC; --ink-2:#A3ADB7; --ink-3:#78838E;
--rule:#2A3138; --rule-strong:#3B444D;
--brass:#C9A45C; --brass-soft:#33290F; --brass-line:#6B5426;
--clay:#D08A76; --clay-soft:#3A211B;
--l0:#262C32; --l1:#35424A; --l2:#4A626B; --l3:#6A939D; --l4:#97C4CD;
--chip-fg:#12161A;
}
}
:root[data-theme="dark"]{
--paper:#12161A; --surface:#191E24; --surface-2:#222831;
--ink:#E6E9EC; --ink-2:#A3ADB7; --ink-3:#78838E;
--rule:#2A3138; --rule-strong:#3B444D;
--brass:#C9A45C; --brass-soft:#33290F; --brass-line:#6B5426;
--clay:#D08A76; --clay-soft:#3A211B;
--l0:#262C32; --l1:#35424A; --l2:#4A626B; --l3:#6A939D; --l4:#97C4CD;
--chip-fg:#12161A;
}
*{box-sizing:border-box}
body{
margin:0; background:var(--paper); color:var(--ink);
font-family:var(--font-body); font-size:17px; line-height:1.62;
-webkit-font-smoothing:antialiased;
}
.wrap{max-width:1180px;margin:0 auto;padding:0 24px 96px}
.layout{display:grid;grid-template-columns:180px minmax(0,1fr);gap:56px;align-items:start}
@media (max-width:960px){.layout{grid-template-columns:1fr;gap:0}.rail{display:none}}
/* ---------- rail ---------- */
.rail{position:sticky;top:28px;padding-top:8px;font-family:var(--font-display);font-size:12px;line-height:1.5}
.rail ol{list-style:none;margin:0;padding:0;display:flex;flex-direction:column;gap:7px}
.rail a{color:var(--ink-3);text-decoration:none;display:flex;gap:9px}
.rail a:hover,.rail a:focus-visible{color:var(--brass)}
.rail .n{font-family:var(--font-mono);font-size:10px;color:var(--rule-strong);min-width:16px;padding-top:1px}
.rail .grp{margin-top:14px;font-size:9.5px;letter-spacing:.14em;text-transform:uppercase;color:var(--rule-strong)}
/* ---------- header ---------- */
header{padding:64px 0 40px;border-bottom:2px solid var(--ink);margin-bottom:44px}
.eyebrow{font-family:var(--font-mono);font-size:11.5px;letter-spacing:.13em;text-transform:uppercase;color:var(--ink-3);display:flex;flex-wrap:wrap;gap:14px;margin-bottom:22px}
.eyebrow .stat{color:var(--clay)}
h1{font-family:var(--font-display);font-weight:800;letter-spacing:-.035em;line-height:.94;font-size:clamp(46px,9vw,92px);margin:0 0 6px;text-wrap:balance}
.sub{font-family:var(--font-display);font-weight:500;font-size:clamp(16px,2.4vw,21px);letter-spacing:-.01em;color:var(--ink-2);margin:0 0 30px;max-width:34ch;line-height:1.3}
.metagrid{display:grid;grid-template-columns:repeat(auto-fit,minmax(180px,1fr));gap:20px 28px;border-top:1px solid var(--rule);padding-top:20px}
.metagrid dt{font-family:var(--font-mono);font-size:10px;letter-spacing:.13em;text-transform:uppercase;color:var(--ink-3);margin-bottom:5px}
.metagrid dd{margin:0;font-family:var(--font-display);font-size:13.5px;line-height:1.45;color:var(--ink)}
/* ---------- typography ---------- */
section{margin-bottom:60px;scroll-margin-top:24px}
h2{font-family:var(--font-display);font-weight:750;letter-spacing:-.022em;font-size:clamp(24px,3.4vw,31px);line-height:1.12;margin:0 0 18px;text-wrap:balance;display:flex;gap:14px;align-items:baseline}
h2 .sn{font-family:var(--font-mono);font-size:12px;font-weight:400;color:var(--brass);letter-spacing:.06em;flex:none;padding-top:2px}
h3{font-family:var(--font-display);font-weight:700;font-size:16px;letter-spacing:-.008em;margin:34px 0 10px;color:var(--ink)}
p{margin:0 0 15px;max-width:var(--measure)}
ul,ol{max-width:var(--measure);margin:0 0 15px;padding-left:20px}
li{margin-bottom:7px}
strong{font-weight:600}
em{font-style:italic}
code{font-family:var(--font-mono);font-size:.855em;background:var(--surface-2);padding:1px 5px;border-radius:2px}
a{color:var(--brass)}
.lede{font-size:19px;line-height:1.55;color:var(--ink-2);max-width:60ch}
/* ---------- devices ---------- */
.callout{border-left:3px solid var(--brass);background:var(--brass-soft);padding:18px 22px;margin:0 0 24px;max-width:var(--measure)}
.callout p:last-child{margin-bottom:0}
.callout .lbl{font-family:var(--font-mono);font-size:10px;letter-spacing:.13em;text-transform:uppercase;color:var(--brass);display:block;margin-bottom:8px}
.rule-quote{border-top:2px solid var(--ink);border-bottom:2px solid var(--ink);padding:26px 0;margin:28px 0;max-width:var(--measure)}
.rule-quote p{font-family:var(--font-display);font-weight:600;font-size:19px;line-height:1.38;letter-spacing:-.014em;margin:0;text-wrap:balance}
.hard{border-left:3px solid var(--clay);background:var(--clay-soft);padding:18px 22px;margin:0 0 24px;max-width:var(--measure)}
.hard .lbl{font-family:var(--font-mono);font-size:10px;letter-spacing:.13em;text-transform:uppercase;color:var(--clay);display:block;margin-bottom:8px}
.hard p:last-child{margin-bottom:0}
.dec{font-family:var(--font-mono);font-size:10.5px;letter-spacing:.08em;color:var(--brass);text-transform:uppercase}
.vec{font-family:var(--font-mono);font-size:.9em;font-weight:600;background:var(--surface-2);padding:2px 7px;border-radius:2px;white-space:nowrap;letter-spacing:.04em}
/* ---------- tables ---------- */
.scroll{overflow-x:auto;margin:0 0 24px;-webkit-overflow-scrolling:touch}
table{border-collapse:collapse;width:100%;min-width:520px;font-family:var(--font-display);font-size:13.5px;line-height:1.45}
th{text-align:left;font-family:var(--font-mono);font-size:9.5px;letter-spacing:.13em;text-transform:uppercase;color:var(--ink-3);font-weight:400;padding:0 16px 8px 0;border-bottom:1px solid var(--rule-strong);vertical-align:bottom}
td{padding:11px 16px 11px 0;border-bottom:1px solid var(--rule);vertical-align:top;color:var(--ink-2)}
td:first-child{color:var(--ink);font-weight:600}
tbody tr:last-child td{border-bottom:none}
.lvl{font-family:var(--font-mono);font-weight:600;font-size:12px;letter-spacing:.04em;color:var(--ink)}
/* ---------- ladders ---------- */
.breakout{margin:34px 0 40px}
.bhead{display:flex;justify-content:space-between;align-items:baseline;gap:20px;border-bottom:1px solid var(--rule-strong);padding-bottom:9px;margin-bottom:22px;flex-wrap:wrap}
.bhead h3{margin:0;font-size:13px;letter-spacing:.1em;text-transform:uppercase;font-family:var(--font-mono);font-weight:400;color:var(--ink-3)}
.bhead .note{font-family:var(--font-display);font-size:12.5px;color:var(--ink-3)}
.ladders{display:grid;gap:26px}
.ladder{display:grid;grid-template-columns:126px minmax(0,1fr);gap:18px;align-items:start}
@media (max-width:700px){.ladder{grid-template-columns:1fr;gap:10px}}
.ladder .pname{font-family:var(--font-display);font-weight:700;font-size:14px;letter-spacing:-.01em;padding-top:2px}
.ladder .pname span{display:block;font-family:var(--font-mono);font-size:10px;font-weight:400;letter-spacing:.1em;text-transform:uppercase;color:var(--ink-3);margin-top:3px}
.rungs{display:grid;gap:3px;grid-template-columns:repeat(5,minmax(0,1fr))}
@media (max-width:700px){.rungs{grid-template-columns:repeat(2,minmax(0,1fr))}}
.rung{padding:9px 10px 11px;background:var(--surface);border-top:4px solid var(--l0);min-width:0}
.rung.r1{border-top-color:var(--l1)} .rung.r2{border-top-color:var(--l2)}
.rung.r3{border-top-color:var(--l3)} .rung.r4{border-top-color:var(--l4)}
.rung .code{font-family:var(--font-mono);font-size:11px;font-weight:600;letter-spacing:.06em;color:var(--ink);display:block;margin-bottom:4px}
.rung .txt{font-family:var(--font-display);font-size:11.5px;line-height:1.34;color:var(--ink-2);display:block}
.rung.na{opacity:.42}
/* ---------- matrix ---------- */
.matrix-shell{display:grid;grid-template-columns:auto minmax(0,1fr);gap:12px;align-items:stretch;margin-bottom:14px}
.ylab{writing-mode:vertical-rl;transform:rotate(180deg);font-family:var(--font-mono);font-size:9.5px;letter-spacing:.14em;text-transform:uppercase;color:var(--ink-3);text-align:center;padding-bottom:22px}
.mgrid{display:grid;grid-template-columns:34px repeat(5,minmax(0,1fr));gap:3px}
.mcell{background:var(--surface);min-height:60px;padding:6px;display:flex;flex-direction:column;justify-content:flex-end;gap:4px;min-width:0}
.mcell.tint1{background:color-mix(in srgb,var(--l1) 26%,var(--surface))}
.mcell.tint2{background:color-mix(in srgb,var(--l2) 26%,var(--surface))}
.mcell.tint3{background:color-mix(in srgb,var(--l3) 24%,var(--surface))}
.mcell.tint4{background:color-mix(in srgb,var(--l4) 22%,var(--surface))}
.mcell.void{background:repeating-linear-gradient(135deg,transparent,transparent 5px,var(--rule) 5px,var(--rule) 6px);opacity:.55}
.rlab,.clab{font-family:var(--font-mono);font-size:10px;font-weight:600;letter-spacing:.05em;color:var(--ink-3);display:flex;align-items:center;justify-content:center}
.rlab{min-height:60px}
.clab{padding-top:7px;min-height:22px}
.pin{font-family:var(--font-mono);font-size:9.5px;font-weight:600;letter-spacing:.02em;background:var(--ink);color:var(--paper);padding:2px 5px;border-radius:2px;line-height:1.3;display:block;overflow:hidden;text-overflow:ellipsis;white-space:nowrap}
.pin.ghost{background:transparent;color:var(--ink-2);border:1px dashed var(--rule-strong)}
.mnote{display:flex;gap:22px;flex-wrap:wrap;font-family:var(--font-display);font-size:12px;color:var(--ink-3);padding-top:6px}
.mnote .k{display:flex;align-items:center;gap:7px}
.sw{width:13px;height:13px;flex:none;background:var(--ink)}
.sw.g{background:transparent;border:1px dashed var(--rule-strong)}
.sw.v{background:repeating-linear-gradient(135deg,transparent,transparent 4px,var(--rule) 4px,var(--rule) 5px);border:1px solid var(--rule)}
@media (max-width:640px){
.mgrid{grid-template-columns:28px repeat(5,minmax(0,1fr))}
.mcell{min-height:52px;padding:4px}
.pin{font-size:8px;padding:1px 3px}
.rlab{min-height:52px}
}
/* ---------- methodology ---------- */
.verbs{display:grid;grid-template-columns:repeat(auto-fit,minmax(210px,1fr));gap:2px;background:var(--rule);border:1px solid var(--rule)}
.verb{background:var(--surface);padding:18px 18px 20px}
.verb h4{font-family:var(--font-display);font-weight:750;font-size:15px;margin:0 0 7px;letter-spacing:-.01em}
.verb p{font-family:var(--font-display);font-size:12.5px;line-height:1.46;color:var(--ink-2);margin:0;max-width:none}
.verb .step{font-family:var(--font-mono);font-size:9.5px;letter-spacing:.13em;color:var(--brass);display:block;margin-bottom:9px}
/* ---------- questions ---------- */
.qs{display:flex;flex-direction:column;gap:0;border-top:1px solid var(--rule-strong)}
.q{display:grid;grid-template-columns:34px minmax(0,1fr) 170px;gap:18px;padding:16px 0;border-bottom:1px solid var(--rule);align-items:start}
@media (max-width:760px){.q{grid-template-columns:28px minmax(0,1fr);gap:12px}.q .owner{grid-column:2}}
.q .qn{font-family:var(--font-mono);font-size:11px;color:var(--brass);padding-top:3px}
.q .qt{font-family:var(--font-display);font-size:14px;line-height:1.48;color:var(--ink-2)}
.q .qt b{color:var(--ink);font-weight:700;display:block;margin-bottom:2px;font-size:14.5px}
.owner{font-family:var(--font-mono);font-size:10px;letter-spacing:.05em;color:var(--ink-3);padding-top:4px}
.owner .tag{display:inline-block;border:1px solid var(--rule-strong);padding:2px 7px;border-radius:2px}
.owner .tag.need{border-color:var(--clay);color:var(--clay)}
/* ---------- misc ---------- */
.numbers{font-family:var(--font-mono);font-size:12.5px;line-height:1.85;background:var(--surface);border-left:3px solid var(--l3);padding:16px 20px;margin:0 0 22px;overflow-x:auto;max-width:var(--measure)}
.numbers .v{color:var(--ink);font-weight:600}
.numbers .k{color:var(--ink-3)}
pre{font-family:var(--font-mono);font-size:12.5px;line-height:1.68;background:var(--surface);border-left:3px solid var(--rule-strong);padding:16px 20px;overflow-x:auto;margin:0 0 22px;max-width:var(--measure);color:var(--ink-2)}
.alt{border-bottom:1px solid var(--rule);padding:14px 0;max-width:var(--measure)}
.alt:last-of-type{border-bottom:none}
.alt b{font-family:var(--font-display);font-size:14px;display:block;margin-bottom:3px}
.alt p{font-size:14.5px;margin:0;color:var(--ink-2)}
.alt .verdict{font-family:var(--font-mono);font-size:10px;letter-spacing:.1em;text-transform:uppercase;color:var(--clay)}
footer{border-top:2px solid var(--ink);margin-top:20px;padding-top:22px;font-family:var(--font-mono);font-size:11px;letter-spacing:.06em;color:var(--ink-3);display:flex;justify-content:space-between;gap:20px;flex-wrap:wrap}
.tm td,.tm th{text-align:center}
.tm td:first-child,.tm th:first-child{text-align:left}
.yes{color:var(--l4);font-weight:700}
.no{color:var(--clay);font-weight:700}
.kind{font-family:var(--font-mono);font-size:9px;letter-spacing:.09em;text-transform:uppercase;padding:2px 6px;border-radius:2px;white-space:nowrap;border:1px solid var(--rule-strong);color:var(--ink-3)}
.kind.adv{border-color:var(--clay);color:var(--clay)}
.routes{display:grid;grid-template-columns:repeat(auto-fit,minmax(240px,1fr));gap:2px;background:var(--rule);border:1px solid var(--rule);margin:0 0 22px}
.route{background:var(--surface);padding:16px 18px}
.route h4{font-family:var(--font-display);font-weight:750;font-size:14px;margin:0 0 6px}
.route p{font-family:var(--font-display);font-size:12.5px;line-height:1.45;color:var(--ink-2);margin:0;max-width:none}
.route .tag{font-family:var(--font-mono);font-size:9px;letter-spacing:.1em;text-transform:uppercase;color:var(--brass);display:block;margin-bottom:8px}
a:focus-visible,.rail a:focus-visible{outline:2px solid var(--brass);outline-offset:3px}
@media (prefers-reduced-motion:reduce){*{animation:none!important;transition:none!important}}
</style>
<div class="wrap"><header><div class="eyebrow"><span>CUST-ADR-006</span> <span class="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><p class="sub">Source: <code>the-custodian · canon/architecture/adr-006-canon-federation-concept-ownership.md · 4039c9d1c08c92014ecc0a65dda63cc73ba187bb</code></p><p class="sub">Review due: 2027-02-17</p></header><div class="layout"><nav class="rail" aria-label="Sections"><ol><li><a href="#status"><span class="n">·</span>Status</a></li><li><a href="#context"><span class="n">·</span>Context</a></li><li><a href="#decision"><span class="n">·</span>Decision</a></li><li><a href="#resolutions"><span class="n">·</span>Resolutions</a></li><li><a href="#consequences"><span class="n">·</span>Consequences</a></li><li><a href="#references"><span class="n">·</span>References</a></li></ol></nav><main><section id="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>
<section id="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>
<section id="decision"><h2>Decision</h2>
<p><strong>1. Three canons, federated by declared ownership.</strong></p>
<div class="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-org</code>:</em> <code>Actor</code> · <code>Natural Person</code><code>Person</code> · <code>Artificial Agent</code><code>Agent</code> · <code>Organization</code> · <code>Group</code> · <code>Role</code> · <code>Membership Relationship</code><code>Membership</code></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-ident</code> (new):</em> <code>Account</code> · <code>Service Account</code> · <code>Identity Record</code> · <code>Identifier</code> · <code>Scoped Identifier</code> · <code>Pseudonymous Identifier</code> · <code>Credential</code> · <code>Claim</code> · <code>Profile</code> · <code>Persona</code> · <code>Tenant</code> · <code>Realm</code> · <code>Synonymity Assertion</code> · <code>Lifecycle State</code> · the actor-linking relationship taxonomy (<code>Relationship</code>, <code>Affiliation</code>, <code>Following</code>, <code>Representation</code>, <code>Delegation</code>, <code>Administration</code>, <code>Trust</code>) · convenience terms <code>User</code>, <code>Subscriber</code></p>
<p><em>Owned by <code>commerce-canon</code>:</em> <code>Legal Entity</code> · <code>Legal Person</code> · <code>Beneficial Owner</code> · <code>Beneficial Ownership Relationship</code> · <code>Beneficial Ownership Exemption</code> · <code>Customer</code> · <code>Vendor</code> · <code>Commercial Relationship</code> · <code>Commercial Commitment</code> · <code>Payment Instrument Reference</code> · <code>Payment Mandate</code> · <code>Pipeline Pursuit</code> · <code>Commercial Record</code> · <code>Counterparty Assurance Gradient</code> · <code>Reputation Signal</code> · <code>Performance Evidence</code> · <code>Registry Identifier</code> · <code>Proxy Commercial Identifier</code> · convenience terms <code>Reputation</code>, <code>Customer Account</code></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>
<section id="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>
<section id="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>
<section id="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>
</section><footer><span>CUST-ADR-006 · accepted-1 · accepted</span><span>the-custodian · canon/architecture/adr-006-canon-federation-concept-ownership.md · 4039c9d1c08c92014ecc0a65dda63cc73ba187bb</span></footer></main></div></div></html>