<p>Separately, an unratified exploration (<code>docs/princedom-isolation-exploration.md</code>) proposes a non-exclusive <strong>capability-role</strong> model for tenants: <code>PLTF</code> (operates the platform), <code>IAM</code> (organizes its own users/secrets), <code>VEN</code> (provides apps/services to others), <code>CUS</code> (consumes apps/services from <code>PLTF</code> or <code>VEN</code> tenants) — one tenant can hold multiple roles simultaneously.</p>
<p>Binky Hedgehog GmbH is being onboarded as the platform's first tenant outside <code>tenant:coulomb</code> (<code>key-cape/workplans/KEY-WP-0004-binky-hedgehog-tenant-onboarding.md</code>), forcing a concrete identifier decision. Binky already exercises both <code>CUS</code> (consumes <code>qonto-assistant</code>) and, per <code>binky-control/INTENT.md</code>, will exercise <code>VEN</code> (packages and sells offers built on the ecosystem to real external customers) — it is not purely a "customer" in the role sense.</p>
<p>Using a capability-role word (<code>customer</code>, <code>vendor</code>, ...) as the tenant <em>grouping</em> segment collides with that separate role dimension: a tenant labeled <code>tenant:customer:binky</code> would carry a stale, misleading label the moment it also starts acting as a vendor, and tenant identifiers are expensive to rename once tokens, OpenBao paths, and downstream config reference them.</p>
</section>
<sectionid="decision"><h2>Decision</h2>
<p>Adopt an onboarding-risk / entity-shape <strong>grouping</strong> taxonomy for the tenant identifier's second segment, replacing the <code>sandbox</code>/<code>customer</code> suggested identifiers in <code>iam-profile_v0.2.md</code>'s "Tenant Claim" section:</p>
<pre>tenant:<grouping>:<name>
trial - test/trial/showcase tenants only
friendly - known, easily reached, tolerant of experimentation/instability
single - one-person business entities (freelance consultants)
small - up to 10 employees at time of onboarding (attoo)
medium - up to 100 employees (attoo)
large - up to 1000 employees (attoo)
enterprise - 1001+ employees (attoo)
consumer - private individuals
family - a legal family
community - a non-legal group of people
association - a legal association of people
agentic - financially enabled AI entities</pre>
<p>The taxonomy has two deliberately different uses:</p>
<ul><li>At creation, the identifier's grouping segment records the tenant's onboarding-time classification. The complete identifier is immutable, so this segment is historical after creation.</li><li>The tenant record's <code>grouping</code> field records current classification. It may change as the entity changes and is authoritative for present-day policy, including guardrails and spend ceilings.</li></ul>
<p>No consumer may parse the identifier's middle segment and treat it as current grouping. Consumers needing current grouping MUST read it from <code>tenant-engine</code>. Identifier creation still validates the segment against this vocabulary; historical does not mean free-form or optional.</p>
<p>Grouping is deliberately <strong>orthogonal to capability role</strong> (<code>PLTF</code>/<code>IAM</code>/<code>VEN</code>/<code>CUS</code>, subsequently ratified by ADR-0014): grouping describes <em>what kind of entity a tenant is and its current onboarding-risk classification</em>; role describes <em>what it does on the platform</em>. Both are carried as tenant metadata, but never conflated into the immutable identifier segment — that conflation is exactly what this ADR avoids.</p>
<p><code>tenant:platform</code> and <code>tenant:coulomb</code> remain <strong>reserved, ungrouped identifiers outside this taxonomy</strong>: <code>tenant:platform</code> is the control-plane root, not a business entity being onboarded; <code>tenant:coulomb</code> is the reference tenant established by ADR-0006, predating this taxonomy, and none of the twelve groupings meaningfully describe "the platform building itself." The taxonomy applies to tenants onboarded from here forward. <em>(This sub-point completes an open question raised during KEY-WP-0004 drafting and is Codex's reasoned proposal — flagged for Bernd's explicit confirmation rather than assumed settled.)</em></p>
<p>First application: Binky Hedgehog GmbH maps to <code>friendly</code> — known, reachable, tolerant of early instability — giving <strong><code>tenant:friendly:binky</code></strong> (<code>key-cape/workplans/KEY-WP-0004-binky-hedgehog-tenant-onboarding.md</code>).</p>
</section>
<sectionid="scope-and-governance-classification"><h2>Scope and Governance Classification</h2>
<p>Per ADR-0011's breaking-change governance, this does <strong>not</strong> meet the breaking-change bar: it doesn't add, remove, or rename a required claim; it doesn't change <code>tenant</code>'s type or validation rule (still an opaque string); it doesn't affect acceptance of any previously-issued token (<code>tenant:platform</code>, <code>tenant:coulomb</code> tokens remain valid as-is, and no <code>tenant:customer:*</code> or <code>tenant:sandbox:*</code> tokens have been issued yet). It only replaces non-normative suggested-identifier guidance for tenants onboarded going forward.</p>
<p>Per ADR-0011's own versioning rule ("New versions are added as new files... except for clearly editorial fixes that do not affect semantics"), this qualifies as an <strong>editorial update</strong> to <code>iam-profile_v0.2.md</code>'s Tenant Claim section — not a new versioned profile document.</p>
</section>
<sectionid="consequences"><h2>Consequences</h2>
<ul><li><code>canon/standards/iam-profile_v0.2.md</code>'s "Tenant Claim" section needs a follow-up edit replacing the <code>sandbox</code>/<code>customer</code> suggested identifiers with this taxonomy. Not made by this ADR itself — tracked as follow-up so the change is reviewable on its own.</li><li><code>key-cape/workplans/KEY-WP-0004-binky-hedgehog-tenant-onboarding.md</code> already reflects this decision (<code>tenant:friendly:binky</code>).</li><li>Future tenant onboarding work should classify a tenant against this list before minting an identifier, rather than reaching for a role word.</li><li>Tenant identifiers never change when current grouping changes. The middle segment is creation-time history; <code>tenant-engine</code> is authoritative for the current grouping value.</li><li>Policy and commercial consumers, including spend-ceiling resolution, MUST query <code>tenant-engine</code> and MUST NOT derive current grouping by splitting a tenant identifier.</li><li>The capability-role model (<code>PLTF</code>/<code>IAM</code>/<code>VEN</code>/<code>CUS</code>) remains a separate dimension, now ratified by ADR-0014. Role metadata is carried alongside — not instead of — current grouping and the historical identifier segment.</li><li><code>tenant:platform</code> and <code>tenant:coulomb</code> are reserved outside the taxonomy, pending Bernd's explicit confirmation (see Decision).</li></ul>
<h3>Keep using capability-role words as the tenant grouping</h3>
<p>Rejected: tenants are already known to hold multiple roles at once (Binky is <code>CUS</code> now, <code>VEN</code> later); a role-word grouping would need renaming as a tenant's roles evolve, which tenant identifiers are specifically expensive to do once tokens, OpenBao paths, and config reference them.</p>
<h3>Retrofit <code>tenant:coulomb</code> into the new taxonomy</h3>
<p>Considered <code>tenant:friendly:coulomb</code> or similar. Rejected for now: Coulomb is structurally the reference tenant from ADR-0006, predating this taxonomy, and none of the twelve entity-shape groupings describe "the platform's own ecosystem-development tenant." Revisit if a future grouping is ever added that genuinely fits it.</p>
<h3>Do nothing / keep the four original suggested identifiers</h3>
<p>Rejected: <code>tenant:customer:binky</code> was the working default going into Binky's onboarding despite the role-collision problem above; the fleet needs this resolved before the first non-Coulomb tenant goes live, not after.</p>
</section>
<sectionid="follow-up"><h2>Follow-Up</h2>
<ul><li>Edit <code>canon/standards/iam-profile_v0.2.md</code>'s Tenant Claim section to replace the old suggested identifiers with this taxonomy (separate, reviewable change).</li><li>Confirm the <code>tenant:platform</code>/<code>tenant:coulomb</code> reserved/ungrouped treatment explicitly.</li><li>ADR-0014 and the Tenant Engine Boundary Contract define how capability-role metadata is carried alongside grouping.</li><li>Keep <code>tenant-engine</code>'s identifier parser vocabulary-validating for creation and lookup compatibility, but do not expose parsed grouping as current classification.</li></ul>
