diff --git a/.changeset/i18n-inline-locale-map-population-count.md b/.changeset/i18n-inline-locale-map-population-count.md
new file mode 100644
index 0000000000..a625886cf4
--- /dev/null
+++ b/.changeset/i18n-inline-locale-map-population-count.md
@@ -0,0 +1,26 @@
+---
+"@objectstack/spec": patch
+---
+
+`i18n.zod.ts` stops asserting a stale size for the inline-locale-map population.
+
+Two docblocks in this file each stated that the repo authors 31 inline locale maps — the
+`INLINE_LOCALE_KEY` rationale ("Every inline map authored in this repo (31 of them, across
+three platform pages) uses `en` / `zh-CN` / `ja-JP` / `es-ES`, so the constraint costs no real
+authoring surface") and the `I18nLabelSchema` form-2 note ("Three published platform pages
+author 31 of these"). The measured population is 45: 33 in `sys-user.page.ts`, 6 in
+`sys-organization.page.ts`, 6 in `sys-position.page.ts`.
+
+The number is **dropped** at both sites rather than corrected to 45. Neither sentence's
+argument needs a magnitude. The first turns on the universal — *every* authored map uses those
+four tags — so the accept set is what makes the constraint free, not the size of the set. The
+second turns on the map being authored on published platform pages *and* resolved by
+`pickLocalized`; one authored-and-resolved map already refutes "a convention the runtime
+ignores", so the count was never load-bearing there either. Writing 45 would buy one release of
+accuracy in prose that is cited as evidence for a schema constraint, and the figure has already
+drifted once with nothing noticing; deriving it would mean a permanent gate whose only job is
+keeping a number in a comment true.
+
+The measured half survives untouched at both sites: three platform pages author these maps, and
+that is still exactly three. No schema arm, bound, default, `.describe()` string or export
+changes; nothing an author can write is affected.
diff --git a/packages/spec/src/ui/i18n.zod.ts b/packages/spec/src/ui/i18n.zod.ts
index b1f0a88667..0907abe41d 100644
--- a/packages/spec/src/ui/i18n.zod.ts
+++ b/packages/spec/src/ui/i18n.zod.ts
@@ -93,9 +93,9 @@ import { strictObject } from '../shared/strict-object';
  * inline locale map the resolver really honours is authorized, and the dead
  * key-reference dialect stays rejected — declared = enforced in both
  * directions, which is exactly the #4667 consistency the ruling asks for.
- * Every inline map authored in this repo (31 of them, across three platform
- * pages) uses `en` / `zh-CN` / `ja-JP` / `es-ES`, so the constraint costs no
- * real authoring surface.
+ * Every inline map authored in this repo (across three platform pages) uses
+ * `en` / `zh-CN` / `ja-JP` / `es-ES`, so the constraint costs no real
+ * authoring surface.
  *
  * The two retired spellings are rejected BY NAME, in any combination
  * (#10492). An earlier revision of this comment argued the opposite — that the
@@ -238,9 +238,9 @@ export const InlineLocaleMapSchema: z.ZodType<
  *     `pages.<page>.components.<id>.label`, …) and resolved by
  *     `system/i18n-resolver.ts`.
  *  2. **An inline locale map** — `{ en: 'Members', 'zh-CN': '成员' }`, picked at
- *     render time. Three published platform pages author 31 of these and
- *     objectui resolves them (`pickLocalized`), so the map is a delivered
- *     capability, not a convention the runtime ignores.
+ *     render time. Three published platform pages author these and objectui
+ *     resolves them (`pickLocalized`), so the map is a delivered capability,
+ *     not a convention the runtime ignores.
  *
  * Form 2 is resolved **on this side too**, since #6765: `resolveI18nLabel` in
  * `./i18n-label-resolver` is the shared `I18nLabel` → `string` resolver, pinned