`sys_business_unit_member` is unadjudicated in `PLATFORM_OBJECT_TENANCY`, so seed-replayed and system-written membership rows land organization-less

[baozhoutao]

Filed as an out-of-scope finding while working #14547 (sharing rules with a business-unit recipient). Unassigned; recording, not claiming.

What was measured

sys_business_unit_member carries an organization_id column — applySystemFields injects it unconditionally for a managedBy: 'platform' object, and the schema in packages/platform-objects/src/identity/sys-business-unit-member.object.ts declares no tenancy opt-out. Whether a WRITER fills it depends entirely on the path:

write path	stamps organization_id?	why
REST / session write	YES	the engine threads execCtx.tenantId into DriverOptions, and the SQL driver's injectTenantOnInsert fills the injected column
seed replay	NO	packages/metadata-protocol/src/seed-loader.ts withholds its single-org fallbackOrgId from every sys_ / cloud_ / ai_ object, so a seeded membership lands org-less unless the replay pinned an organization or the record spells the column itself
elevated (system-context) write	NO	sys_business_unit_member is unclassified in PLATFORM_OBJECT_TENANCY (packages/objectql/src/tenancy/platform-object-tenancy.ts), so Engine.resolveSystemInsertOrganization returns early and stamps nothing
driver-memory / driver-mongodb	NO	neither implements a tenant column at all (both refuse to boot multi-tenant, which is what makes that safe)

The repo's own dogfood fixture is an instance of row 3: packages/qa/dogfood/test/showcase-bu-hierarchy-sharing.dogfood.test.ts inserts membership rows under a bare isSystem context and they land org-less, while the sys_business_unit rows beside them are explicitly stamped.

Why it matters now

sys_business_unit_member is the population an authorization path enumerates. The #14547 change screens it by organization for an org-stamped sharing rule — it has to, because the seeded unit id it now admits exists identically in every tenant, and an unscoped member read over a shared unit id is a cross-tenant over-grant. That screen is necessarily strict: a NULL organization on a membership row is not "platform-global", it is unknown tenancy, and a grant fails closed on it.

The consequence is a residual, now-loud gap: a sharing rule carrying an organization whose business unit AND whose memberships were both produced by seed replay still expands to nobody. SharingRuleService.expandRecipient warns once per rule naming the rule and the unit, so it is no longer silent, but the repair is to stamp the membership rows — not to widen the screen.

What the adjudication is

The PLATFORM_OBJECT_TENANCY header states that an object whose tenancy cannot be determined is LISTED for adjudication rather than guessed either way (2026-08-31 ruling, execution point 2: 「判不了的逐个列出回批呈裁，⛔ 不猜」). This is that listing for one object. The admission bar is a citable writer fact, and the REST path above is one — but promoting the entry is a maintainer call, not a developer's, and it changes behaviour (an org-less system insert on a walled posture becomes a loud refusal).

Related, neither of them this object: #14096 asks whether the seed loader and the #8686 backfill should follow the per-object classification at all — the answer there decides row 2 of the table. #13636 describes the third tenancy state this table's row 2/3 split keeps running into, where org-less is a property of the ROW rather than the object.

Blocked-by: #14096

Not proposed here

No backfill of existing rows. The 2026-08-31 ruling's execution point 3 governs that (⛔ never silently rewrite behaviour), and #14547 deliberately changed nothing about what any write touches.

Generated by Claude Code

[huangyiirene]

Triage — graded p2, pm:blocked on #14096 (which now carries pm:blocking), routed domain:engine. (All applied and read back first.)

Confirmed at origin/main c616c2c

• git grep -n "sys_business_unit_member" -- packages/objectql/src/tenancy/platform-object-tenancy.ts → no hit. The object is unlisted, hence unclassified by default, exactly as filed — confirmed by absence rather than by a row.
• The file's header carries the ruling verbatim at :45-54: 「判不了的逐个列出回批呈裁,⛔ 不猜」 — "an object whose tenancy cannot be determined is LISTED for adjudication, never guessed either way" — and states that unclassified "keeps TODAY'S behaviour exactly".

So the card is, by construction, the artefact that ruling asks for. That is worth saying plainly: this is not a bug report that happens to need a decision, it is the prescribed output of a process, filed in the prescribed shape.

⚠️ The state you will eventually want is needs-user-decision. It is not that yet, and the reason is worth recording.

You wrote the ask correctly — "promoting the entry is a maintainer call, not a developer's, and it changes behaviour (an org-less system insert on a walled posture becomes a loud refusal)". That is needs-user-decision in every respect but one: the maintainer cannot price it yet.

#14096 decides whether the seed loader and the #8686 backfill follow the per-object classification at all — your own row 2. Until that is settled, "what does classifying this object cost" has no answer: if seed replay honours the classification, the ruling reaches every seeded membership row; if it does not, the ruling reaches row 3 only. Those are different decisions wearing the same words.

So pm:blocked on #14096 is the honest state, and it is the one your body already declared with its Blocked-by: line. ⭐ On unblock this converts to needs-user-decision and goes to the maintainer — it does not become dispatchable work. Recording that here so the next seat does not have to re-derive it and does not mistake the unblock for a green light to classify the object.

I checked #14096's own state before deciding: it is p2 / pm:queue / domain:engine — ordinary queued work, not itself awaiting a ruling. So this is a chain of length one, not a stalled pair.

Why p2, and why not security

p2 matches #14096, and this sits on an authorization path.

⛔ No security label, deliberately. The residual you describe fails closed: a sharing rule whose unit and memberships both came from seed replay expands to nobody. Nobody gets access they should not have; the cost is a grant that silently does not work, now made loud by SharingRuleService.expandRecipient's per-rule warning. Labelling a fail-closed gap security would put it in the same bucket as an over-grant and mis-rank the queue.

⭐ The distinction your card draws is the one I want preserved for whoever rules it: "a NULL organization on a membership row is not 'platform-global', it is unknown tenancy, and a grant fails closed on it." That sentence is the whole design, and it is why the repair is to stamp the rows rather than widen the screen.

Scope, when it unblocks

⛔ No backfill of existing rows, per the 2026-08-31 ruling's execution point 3 (⛔ never silently rewrite behaviour). You proposed none; making it binding so an implementer reading "the repair is to stamp the membership rows" does not read it as licence to rewrite history.

⛔ Do not widen #14547's organization screen. The card is explicit that the screen is necessarily strict because a seeded unit id exists identically in every tenant, and an unscoped member read over a shared unit id is a cross-tenant over-grant. That screen is the thing protecting the boundary.

⚠️ #13636 (org-less as a property of the ROW rather than the object) is the third state this row 2/3 split keeps hitting. Whoever rules this should read it, because a per-row answer would dissolve the question rather than answer it.

On the filing

The four-row writer table is what makes this adjudicable without a re-walk — each path, whether it stamps, and why, with the dogfood fixture named as a live instance of row 3. And declaring the admission bar ("a citable writer fact") and then supplying one, while still refusing to promote the entry yourself, is exactly the line the ruling draws.

---

Generated by Claude Code