[finding] `AUTH_SSO_PROVIDER_SCHEMA` is the same shape #11777 retired — a publicly exported mapping with no code consumer, and the ruling that kept the sso *bridge* never ruled on the exported copy

[os-sam]

Found while implementing #11777 (deleting AUTH_SCIM_PROVIDER_SCHEMA), out of that card's scope, not fixed there. Filed unassigned, no pm:queue. Observation-class: nothing is broken today.

What was measured

packages/plugins/plugin-auth/src/auth-schema-config.ts:952 exports AUTH_SSO_PROVIDER_SCHEMA, an ssoProvider model + column mapping. Measured on origin/main at 497ded7801:

$ git grep -n "AUTH_SSO_PROVIDER_SCHEMA" origin/main -- .
origin/main:packages/platform-objects/CHANGELOG.md:8403: `domainVerified` documented in `AUTH_SSO_PROVIDER_SCHEMA`.
origin/main:packages/plugins/plugin-auth/CHANGELOG.md:9166: `domainVerified` documented in `AUTH_SSO_PROVIDER_SCHEMA`.
origin/main:packages/plugins/plugin-auth/src/auth-manager.ts:2964: // AUTH_SSO_PROVIDER_SCHEMA).
origin/main:packages/plugins/plugin-auth/src/auth-schema-config.ts:952:export const AUTH_SSO_PROVIDER_SCHEMA = {

Four hits: its own declaration, two frozen CHANGELOG lines, and one comment. No code reads it, and it is never handed to sso() as a schema option. The channel was controlled against a symbol known live in the same file (buildOrganizationPluginSchema, 15 hits across README, auth-manager.ts and four test files), so the low count is a measurement rather than a broken grep.

Its sibling AUTH_JWKS_SCHEMA looks similar on a per-file hit count and is not dead — it is consumed in-file at auth-schema-config.ts:868. AUTH_SSO_PROVIDER_SCHEMA has no such in-file use.

Why this is not already covered by the closed cards

This is the question the existing cards route around rather than answer, which is why it is filed rather than assumed handled:

• [finding] @better-auth/sso now accepts a schema.ssoProvider option — the adapter-level ssoProvider model bridge predates that and may be replaceable #8224 (closed completed by PR docs(plugin-auth): sweep the stale "@better-auth/sso accepts no schema option" claim, re-measured against 1.7.1 #10072) swept the stale claim that @better-auth/sso accepts no schema option. It changed comments only.
• [triage call] Should the ssoProvider → sys_sso_provider mapping move onto schema.ssoProvider now that the option is measured to work? (the half #8224's sweep does not close) #10074 (closed not_planned) asked whether the ssoProvider mapping should move onto schema.ssoProvider, and landed on option A — do not rewire, on strong reasoning: the adapter's camelCase-to-snake_case rule is mechanical and total, while a hand-maintained per-field list is covered only if someone remembers. That ruling stands and this card does not reopen it.

Ruling A settles the seam: the adapter layer (AUTH_MODEL_TO_PROTOCOL + mechanical field resolution) owns the column names, and the plugin option is deliberately not used. What it does not settle is what should happen to the exported constant that copies those names alongside the seam it lost. A comment recording a deliberate choice is exactly the right artifact; a publicly exported as const object is a different thing, and it is the thing #11777 names.

Why it may be worth the same treatment as #11777

1. It is public API. packages/plugins/plugin-auth/src/index.ts:69 does export * from './auth-schema-config.js', so it ships from the published package and a downstream consumer can read it as authoritative.
2. It can drift silently. If the adapter-side names ever change, nothing fails when this copy does not follow — there is no consumer to break. Under ruling A the adapter is authoritative by construction, which makes the exported copy a strictly second source of truth for the same four-plus column names.
3. It is the shape ADR-0049 enforce-or-remove and Prime Directive chore: version packages #10 name: one contract, two declarations, only one load-bearing.

Why it is NOT one of the easy answers

Recording the genuine differences from #11777, since they may change the disposition:

• Unlike scim, the sso option is real — SSOOptions.schema.ssoProvider.{modelName,fields,additionalFields} exists on @better-auth/sso@1.7.1 and the runtime honours it (measured on [triage call] Should the ssoProvider → sys_sso_provider mapping move onto schema.ssoProvider now that the option is measured to work? (the half #8224's sweep does not close) #10074). So this constant is not inert by construction the way the scim one was; it is unused by choice.
• The domainVerified entry carries a real explanatory comment (ADR-0024 ②) that has value independent of the constant, and any removal should keep that knowledge as prose.
• [triage call] Should the ssoProvider → sys_sso_provider mapping move onto schema.ssoProvider now that the option is measured to work? (the half #8224's sweep does not close) #10074 named the one thing that would change its answer: sso needing additionalFields, which has no adapter-layer equivalent. If that ever arrives, this constant is the natural seed for it — an argument for keeping it that the scim one did not have.

So the plausible dispositions are: delete it and keep the reasoning as a NOTE (what #11777 did for scim, following this file's own sso NOTE convention); or keep it and say so in writing — a short line recording that it is deliberately retained against a possible additionalFields need, which turns a silent orphan into a declared one. Both are cheap; what is not cheap is leaving the next reader unable to tell which of the two copies is authoritative.

Not urgent, not a runtime defect: no behaviour depends on it today.

Refs: #11777 (the scim sibling, retired) · #10074 (ruling A, do not rewire the seam) · #8224 (the stale-claim sweep) · ADR-0049 (enforce-or-remove) · ADR-0024

---

Generated by Claude Code

[os-steve]

Triage: pm:blocked (was finding), domain:services, type Task.

Blocked-by: #11777

Same-family grading: this is the #11777 class (publicly exported zero-consumer mapping) one constant over, in the same file the in-flight #11777 PR is editing — hard serial regardless of disposition. Inherit the treatment #11777's landed contract-review verdict establishes rather than opening a second decision card: on the four-axis walk the differences this card honestly records do not move the endpoint — the additionalFields seed argument is exactly the speculative-capability shape the focus axis declines, and a second unconsumed source of truth for adapter-owned column names is the drift trap the AI-error axis exists for. Expected shape: delete + keep the domainVerified knowledge and the retain-reasoning as a prose NOTE (this file's own convention), mirroring #11777. Fork clause: if #11777's review verdict carves out sso, or implementation shows the constant load-bearing after all, back to triage — do not silently choose.

---

Generated by Claude Code