ADR-0014 + tenant-engine boundary contract + IAM Profile v0.3

Ratifies the tenant capability-role model (PLTF/IAM/VEN/CUS, non-exclusive,
independent of ADR-0013's grouping axis), a hybrid carrying mechanism
(tenant-engine authoritative, key-cape caches a tenant_roles claim at
issuance, flex-auth re-validates live for aal2-class decisions), and
tenant-engine as a new, separate service owning tenant existence, grouping,
capability roles, and plan/subscription assignment -- not a module inside
user-engine, whose own boundary contract already scopes it to consuming
tenant identifiers, not owning them.

canon/standards/tenant-engine-boundary-contract_v0.1.md defines that
ownership boundary before the repo exists, mirroring how
user-engine-boundary-contract_v0.1.md was sequenced.

canon/standards/iam-profile_v0.3.md (minor version per ADR-0011's own
governance -- optional claim addition, no breaking change) adds the
tenant_roles claim, folds in ADR-0013's tenant-identifier vocabulary, and
documents the live-revalidation requirement. docs/platform-identity-
security-architecture.md's Tenant Model section and SCOPE.md's canonical
spec pointer updated to match; other historical citations of v0.2 left as
version-pinned references, not bulk-updated.

Records Bernd's trial-tenant policy: trial-grouped tenants may hold any
capability role (showcase/test/explore), with safety enforced through
tenant-engine-owned resource guardrails (spend limits, entity/action
counts) rather than role gating -- guardrail design is reserved, explicitly
not specified by this change.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/platform-identity-security-architecture.md

@@ -1,7 +1,7 @@
 # Platform Identity and Security Architecture
 
 Status: implemented architecture baseline for NetKingdom/Railiance/Coulomb
-Date: 2026-05-24
+Date: 2026-05-24 (Tenant Model updated 2026-07-23, ADR-0013/ADR-0014)
 
 ## Purpose
 
@@ -296,15 +296,39 @@ Examples of platform-root actions:
 Every protected resource should belong to a tenant or to the platform
 control plane.
 
-Suggested identifiers:
+Tenant identifiers are `tenant:<grouping>:<name>`, where `<grouping>` is an
+onboarding-risk / entity-shape classification ratified by ADR-0013
+(`trial`, `friendly`, `single`, `small`, `medium`, `large`, `enterprise`,
+`consumer`, `family`, `community`, `association`, `agentic`):
 
 ```text
-tenant:platform          # platform control plane resources
-tenant:coulomb           # first internal/reference tenant
-tenant:sandbox:<name>    # sandbox tenants
-tenant:customer:<name>   # future customer tenants
+tenant:platform            # platform control plane — reserved, ungrouped
+tenant:coulomb              # first internal/reference tenant — reserved, ungrouped
+tenant:friendly:binky       # first tenant onboarded under this taxonomy
+tenant:<grouping>:<name>    # general shape for tenants onboarded going forward
 ```
 
+`tenant:platform` and `tenant:coulomb` predate the taxonomy and stay
+reserved outside it — see `canon/standards/iam-profile_v0.3.md`'s Tenant
+Claim section for the full rationale.
+
+A tenant separately holds **capability roles** — `PLTF`, `IAM`, `VEN`, `CUS`
+(ADR-0014), non-exclusive — describing what it *does* on the platform,
+independent of its grouping (what kind of entity it *is*). A `trial`-grouped
+tenant may hold any capability role, since `trial` exists to showcase every
+role; safety instead comes from tenant-level resource guardrails (spend
+limits, entity/action counts — reserved, not yet designed).
+
+`tenant-engine` (new service, `canon/standards/tenant-engine-boundary-contract_v0.1.md`)
+is the canonical owner of both tenant grouping and capability-role facts,
+plus plan/subscription assignment. `key-cape` caches a tenant's roles on
+issued tokens (`tenant_roles` claim) for ordinary decisions; `flex-auth`
+re-validates live against `tenant-engine` before authorizing privileged,
+destructive, platform-root, or otherwise `aal2`-class actions — the same
+threshold the assurance model below already uses. `user-engine` continues
+to own users and memberships *scoped by* a tenant, not the tenant record
+itself.
+
 Tenant membership and platform membership are distinct. A subject may be
 an administrator in `tenant:coulomb` without being a platform operator.