Found while building the tenancy write-call-site census for #13178. Not fixed there: that card is scoped to a measurement and forbids source changes.
The claim, and what falsifies it
packages/metadata-core/src/record-organization.ts:56-58 justifies createFieldPresenceProbe like this:
Why the probe exists at all: the SchemaRegistry auto-injects organization_id only in multi-tenant mode (applySystemFields({ multiTenant })), so on single-tenant stacks the sys_audit_log / sys_activity tables have no such column.
That is no longer true. applySystemFields (packages/objectql/src/registry.ts, comment at lines 509-517) states the opposite in the present tense:
The organization_id COLUMN is provisioned unconditionally (subject only to the explicit opt-outs above) — its existence no longer depends on the global multi-tenant flag. ... The multi-tenant flag now governs only whether the column is INDEXED
The derivation agrees: resolveInjectedSystemColumns (packages/spec/src/data/injected-system-column-provenance.ts) computes tenant from systemFields, managedBy and tenancy.enabled only. It takes no multiTenant input at all, and its own docstring says so ("the flag cannot change what EXISTS, only what is indexed").
Measured on origin/main at 090f2302e: of 117 object declarations in the tree, 92 resolve a tenant field and 25 do not — and all 25 are excluded by managedBy: 'better-auth' or tenancy.enabled: false, never by posture.
Why it is worth recording rather than ignoring
The docstring is the stated REASON the probe exists. Read literally it says the probe is a single-tenant-posture workaround, which invites two wrong moves: deleting the probe as dead once someone checks that the column is always provisioned, or hand-rolling a fresh posture-conditional probe elsewhere on the same false premise. The probe does still have real work to do — external objects and getSchema-less test doubles, per its own "best-effort in both directions" paragraph — so the fix is to the stated reason, not to the code.
This is the family sql-driver.ts names in its own applyTenantScope docstring: "which is exactly how a docstring becomes the last place a wrong fact survives."
Not established here
Re-check
sed -n '50,64p' packages/metadata-core/src/record-organization.ts
sed -n '509,518p' packages/objectql/src/registry.ts
git grep -n "multiTenant" packages/spec/src/data/injected-system-column-provenance.ts
The third command prints nothing, which is the point.
Found while building the tenancy write-call-site census for #13178. Not fixed there: that card is scoped to a measurement and forbids source changes.
The claim, and what falsifies it
packages/metadata-core/src/record-organization.ts:56-58justifiescreateFieldPresenceProbelike this:That is no longer true.
applySystemFields(packages/objectql/src/registry.ts, comment at lines 509-517) states the opposite in the present tense:The derivation agrees:
resolveInjectedSystemColumns(packages/spec/src/data/injected-system-column-provenance.ts) computestenantfromsystemFields,managedByandtenancy.enabledonly. It takes nomultiTenantinput at all, and its own docstring says so ("the flag cannot change what EXISTS, only what is indexed").Measured on
origin/mainat090f2302e: of 117 object declarations in the tree, 92 resolve a tenant field and 25 do not — and all 25 are excluded bymanagedBy: 'better-auth'ortenancy.enabled: false, never by posture.Why it is worth recording rather than ignoring
The docstring is the stated REASON the probe exists. Read literally it says the probe is a single-tenant-posture workaround, which invites two wrong moves: deleting the probe as dead once someone checks that the column is always provisioned, or hand-rolling a fresh posture-conditional probe elsewhere on the same false premise. The probe does still have real work to do — external objects and
getSchema-less test doubles, per its own "best-effort in both directions" paragraph — so the fix is to the stated reason, not to the code.This is the family
sql-driver.tsnames in its ownapplyTenantScopedocstring: "which is exactly how a docstring becomes the last place a wrong fact survives."Not established here
registry.tscites the decoupling; meta:applySystemFieldsstampsindexedonorganization_id— a keyFieldSchemarejects by name, so every registry-backed object read answers_diagnostics: { valid: false }#6810 is cited nearby for removingindexed: opts.multiTenant, but I did not measure which change moved the provisioning itself.Re-check
The third command prints nothing, which is the point.