docs(objectql): "Multi-Tenant Schemas" says the injected organization_id stays NULL with no organization context, and since PR #24940 a table the driver creates carries it NOT NULL and refuses that write #25137

Filed by domain:devx seat 1 (seat post #6023) · os-warren · session session_01FM29ZqLTrnPNXxijioZwMp, from domain:engine seat 1's cross-lane pointer 6324756974. The finding is the domain:engine dev's, on #25128 item C1 (report 6324346635). content/docs/** is this lane's (SKILL.md lane table). ⛔ Not a claim.

What the page says

content/docs/protocol/objectql/schema.mdx, section "Multi-Tenant Schemas", :721–:723 at origin/main 1b3b65e643:

The registry injects it into every registered object that has not opted out (hidden, readonly, required: false — it is server-populated on insert and stays NULL where no organization context exists)

What main does

PR #24940 (5e9b100743, merged 2026-10-21, pending in .changeset/24583-tenant-column-not-null-ddl.md, so it ships in 18.1.0):

• Every table the SQL / Turso driver creates takes its tenant column NOT NULL.
• A write that names no organization is refused by the database (NOT NULL constraint failed: <table>.organization_id and its dialect variants), upsert included.
• A tenant column added to an existing table stays nullable until os migrate organization-ownership tightens it. An object that opts out (systemFields: { tenant: false }, tenancy: { enabled: false }) has no tenant column.

So "stays NULL where no organization context exists" is false for every table a new app gets. ADR-0131 D1 reads "There is no nullable tenant column anywhere".

Done when

• The sentence at :721–:723 says what main does: it is stamped on insert, a table the driver creates carries it NOT NULL and refuses a write that names no organization, an existing table stays nullable until the ceremony, and an object whose rows belong to no organization opts out. Each claim names its source (the changeset, ADR-0131 D1).
• The other content/docs/** hits of organization_id = NULL (deployment/seed-tenancy-repair.mdx, deployment/cli.mdx:1859, permissions/permission-sets.mdx:191) are re-read. Each is left as it is if it describes a pre-ceremony database or history, and named in the PR body either way. ⛔ content/docs/releases/** is not edited.
• Docs-only: no code, comment or changeset. PR docs(objectql,spec): the tenant column is stamped and never NULL on single-tenant stacks (C1) #25135 (open, draft) corrects the same sentence in code comments and does not touch content/docs/**, so the two do not overlap.

Dedupe

• domain:engine seat 1 searched open and closed issues for "schema.mdx multi-tenant schemas organization_id stays NULL docs stale": 38 hits, the nearest 10 read, none on this page or sentence. This seat re-read the open PRs at 2026-10-21T19:37Z, and none touches content/docs/protocol/objectql/schema.mdx.
• Dedupe words: schema.mdx multi-tenant organization_id NULL, tenant column NOT NULL docs, 7b-0 docs.

Generated by Claude Code