On the sqlite driver, tenant-scoped objects (`ats_employer`, `ats_interview`, `ats_offer`) return 0 rows to platform admins holding `viewAllRecords`; the memory driver returns all of them

[os-sam]

Found while verifying #27 on claude/issue-27-signable-personas at 48568f9, and reproduced on origin/main at 7e76ffe — so it is pre-existing and not attributable to that PR (which touches no object or tenancy setting).

Measured

Same artifact, same OS_PLATFORM_OWNER_EMAIL=admin@objectos.ai, --fresh, fresh sign-in per account, GET /api/v1/data/OBJECT?limit=1 read as that user. Seed loaded 801 rows, 0 errored, on both drivers.

account	driver	ats_employer	ats_interview	ats_offer	ats_job	ats_application	ats_candidate
platform owner (admin_full_access + config standing)	memory	12	40	14	40	200	80
platform owner	sqlite (default)	0	0	0	40	200	80
platform_admin persona (ats_platform_admin, viewAllRecords)	memory	12	40	14	40	200	80
platform_admin persona	sqlite (default)	0	0	0	40	200	80
job seeker persona	memory	9 (verified)	0	0	22	1	1
job seeker persona	sqlite (default)	0	0	0	22	1	1

Baseline on origin/main 7e76ffe, sqlite, signed in as the runtime-minted dev admin with owner standing: ats_employer 0 · ats_interview 0 · ats_offer 0 · ats_job 40 · ats_application 200. Identical split.

The three objects that read 0 are exactly the ones that stay inside the Layer 0 tenant wall under the 2026-09-07 split contract (ats_employer, ats_employer_member, ats_interview, ats_offer carry organization_id); the objects that read fine are the platform-global ones (tenancy: { enabled: false }). So the SQL driver appears to apply an organization filter on organization_id that the memory driver does not — the seeded rows carry org_ats_* while every platform session's active organization is the Default Organization. DESIGN.md §03 says the wall produces null under the single posture, which is what the memory driver does; the sqlite path does not match that. I did not run a debug-level boot to read the tenancy or RLS lines, so the mechanism is a hypothesis, not a finding.

What it does to the demo

The literal pnpm dev (sqlite is the default driver) serves the Platform group's Employers Pending queue empty to every platform persona, while pnpm dev --database-driver memory shows its 2 rows. The README's demo path on #27's branch therefore only shows employer data on the memory driver.

Suggested next step

Boot with --log-level debug on sqlite, read as admin@platform.example, and capture the [RLS] / tenancy lines for one ats_employer find; then decide whether this is an upstream driver defect (relay to objectstack-ai/objectstack) or a posture the app must declare. #18 is about accessible_org_ids on the employer side and is a different mechanism — this one hits viewAllRecords holders.

Filed without a label for triage.

[os-sam]

PM re-measurement on main 8e6d7d4. The report is real, but the characterisation is off in a way that matters, and the split is sharper than "tenant-scoped objects".

It is four objects, and they are exactly the walled set

Signed in as admin@platform.example, default (sqlite) driver, after waiting for the seed to settle:

object	sqlite	memory	DESIGN §03 class
ats_employer	0	12	进墙
ats_employer_member	0	30	进墙
ats_interview	0	40	进墙
ats_offer	0	14	进墙
ats_job	40	40	平台全局
ats_application	200	200	平台全局
ats_candidate	80	80	平台全局

ats_employer_member was missed in the original report — so it is all four walled objects, and the boundary follows the tenancy declaration exactly: every object with tenancy enabled reads 0, every tenancy: { enabled: false } object reads in full. That is not a coincidental subset, it is the tenancy flag.

⚠️ A methodology note, because it bit me first. The boot logs [Seeder] Inline seed exceeded 8000ms budget for ats; continuing in background. My first memory run read ats_interview 0 / ats_offer 0 and briefly looked like a contradiction of this issue — it was just a mid-load count. Wait for [Seeder] Seed loading complete {"inserted":801,...} before counting anything, on either driver.

It is not permissions, and not the wall as reported

• The platform owner (admin_full_access, wildcard viewAllRecords) reads the same zeros on sqlite. A read bypass does not lift it, so it is not the permission sets.
• Both drivers log the identical posture line at boot:
  [security] tenancy posture 'single' — Layer 0 is inert; the platform's own tenant-scoped RLS policies are stripped (app-authored ones are retained and fail closed, ADR-0105 D3)

So the two drivers agree on the posture and disagree on the result. One of them is wrong, and the interesting possibility is that it is not sqlite: an organization predicate is being applied to tenancy-enabled objects under a posture that reports Layer 0 inert, and the memory driver simply does not apply it. On that reading the demo "works" on memory only because memory is the permissive one — which would make every memory-driver measurement in this repository, including the ones in #41, weaker evidence than it looks.

The app-side half nobody has stated

Platform staff are not members of the ATS organizations. Measured:

• sys_organization: 13 rows — the 12 seeded org_ats_* plus one runtime-minted Default Organization.
• admin@platform.example: activeOrganizationId = the Default Organization; its only sys_member row is there.
• admin@quillstone.example: activeOrganizationId = org_ats_quillstone, with 3 sys_member rows in it — so the seeded employer memberships are correct and this is not Membership backfill binds all 80 job seekers and both platform staff to the Default Organization: the auth membership policy is left at auto, which DESIGN.md §03 forbids #38 eating them. (The backfill's skipped: 31 is those rows being left alone, exactly right.)

⛔ One trap for whoever takes this: reading sys_member is itself org-scoped. Read as the owner it returns 83 rows all in the Default Organization and looks like proof that every membership was rewritten. It is not — it is the reader's own scope. I made that mistake before signing in as the employer admin and seeing its 3 correct rows. Do not repeat it; check from inside each organization.

So on any driver that enforces org scoping, platform staff see no walled rows because they are genuinely not in those organizations — while DESIGN.md §03 intends platform staff to see everything. That is an app-model gap independent of the driver question, and fixing the driver disagreement alone will not give the platform group its rows back.

Two questions to settle before a fix

1. Which driver is right? Under single with Layer 0 inert, should an organization_id predicate be applied at all? Settle this against @objectstack/plugin-security and the driver query paths, and file upstream if the drivers genuinely disagree — this is an upstream-shaped defect, not an app one.
2. How do platform staff reach walled rows? Their viewAllRecords is supposed to be the answer and is not. Either the bypass must precede the org predicate, or platform staff need standing in every ATS org (which contradicts §03's model), or the four objects' wall placement needs revisiting.

Still a release blocker for #9: the literal pnpm dev demo shows an empty Employers Pending.

---

Generated by Claude Code

[os-sam]

Root-caused in framework source. sqlite is correct; the memory driver is the broken one — and the consequence for this repository is larger than the issue title.

Mechanism

Engine.buildDriverOptions (packages/objectql/src/engine.ts) hands tenantId to the driver for every object that has not opted out:

const hasTenant =
  execCtx?.tenantId !== undefined && !isTenancyDisabled(objectSchema) && !isFederated;

No posture check — single is scoped like any other. Its docstring: "the SQL driver auto-scopes reads and auto-injects the tenant column on writes." driver-sql does exactly that (sql-driver.ts:4360).

driver-memory does not. tenantId, tenantIds and organization_id do not appear anywhere in its 2318-line driver — zero hits in the whole driver-memory/src tree. Its guard has a hole the exact size of the default case:

export function declaresTenantScope(schema) {
  return schema?.tenancy?.enabled === true;   // explicit opt-IN only
}

Our four walled objects (ats_employer, ats_employer_member, ats_interview, ats_offer) omit the tenancy block entirely — tenant-scoped by default. The engine scopes them; the guard cannot see them; the driver discards the scope. Our seven platform-global objects declare tenancy: { enabled: false } explicitly, so both drivers agree on them. That is the whole table.

Filed upstream as objectstack#16589.

What this means for this repository, and it is not small

⚠️ Every isolation measurement we have taken on the memory driver overstates visibility. Memory is the fast path all of our agents reach for, and on it a cross-organization read succeeds that production would refuse. So "two employer accounts see disjoint pipelines" passing on memory would not establish isolation — the rows come back to everyone there.

Concretely, this reframes two open issues:

• Employers cannot read any candidate, and profile_visibility is enforced nowhere #13 (employers read all 80 candidates) is not softened by this. ats_candidate is tenancy: { enabled: false }, so both drivers agree — the 80 is real on sqlite too. It stays a live privacy hole.
• Employer-side RLS policies fail closed for everyone: IN (current_user.accessible_org_ids) is the deprecated SQL-style spelling and the bridge cannot bind the variable #18's acceptance must be taken on sqlite, or on both. On memory a resolver that resolves nothing and a resolver that works could produce the same non-zero counts, because the driver is not filtering by organization in the first place. The employer personas' active org matches their rows' organization_id, so sqlite should serve them once the RLS predicate binds — that is the run that proves it.

Retitling the problem

This is not "sqlite returns 0 rows". It is: the demo relies on the memory driver's non-enforcement, and the app's own model does not give platform staff a way to read tenant-scoped rows. Platform staff sit in the minted Default Organization; the walled rows carry org_ats_*; viewAllRecords does not help because driver scoping is below the permission evaluator (measured: the platform owner's wildcard reads the same zeros).

So even after upstream fixes the driver, the Platform group's Employers Pending is still empty on a correct driver unless we answer: how does platform staff reach tenant-scoped rows? The options look like (a) platform staff hold standing in every ATS org — contradicts §03, (b) the four objects move out of the wall to tenancy: { enabled: false } and rely on RLS like ats_job already does, or (c) upstream makes viewAllRecords precede driver scoping.

(b) is the one worth costing first: §03's split already puts ats_job and ats_application outside the wall for the same joint-ownership reason, and ats_employer is arguably the same shape. That is a DESIGN §03 amendment, so it needs a ruling before anyone edits an object.

Still a release blocker for #9, now for a better-understood reason.

---

Generated by Claude Code

[os-sam]

The app-side half is resolvable, and the evidence now says how. Analysis only — this is a DESIGN.md §03 change that removes a security layer, so it needs the maintainer's call before anyone edits an object.

The question this issue left open

How do platform staff reach tenant-scoped rows? Their viewAllRecords is supposed to be the answer and is not.

Options were (a) platform staff hold standing in every ATS org — contradicts §03, (b) the four objects leave the wall and rely on RLS, (c) upstream makes viewAllRecords precede driver scoping.

I said (b) was worth costing first. It is now costed, and the answer is better than I expected: all four walled objects already have isolation that does not depend on the wall.

object	wall	what isolates it without the wall
ats_employer	walled	RLS ×3 — record.organization in current_user.employer_org_ids
ats_employer_member	walled	RLS ×2 — record.employer_org in …, plus controlled_by_parent off ats_employer
ats_offer	walled	RLS ×3 — record.employer_org in …, plus the seeker's candidate_user == current_user.id
ats_interview	walled	no RLS policy at all — sharingModel: 'controlled_by_parent', masterDetail → ats_application

⭐ ats_interview is the one I expected to block this and it does the opposite. It has no policy and no employer_org column, so I assumed the wall was its only boundary — which would have made (b) a silent security regression. It is not: it inherits from ats_application, which is already tenancy: { enabled: false } and RLS-scoped. Its isolation is independent of the wall today. That is also why employers read 10 / 6 interviews rather than 40 on the memory driver, which does no organization scoping at all — the number the #18 agent flagged as unexplained.

So moving all four to tenancy: { enabled: false } would:

• preserve every isolation property (RLS predicates and master-detail inheritance, both proven working since Employer-side RLS policies fail closed for everyone: app-owned membership resolver republishes accessible_org_ids as current_user.employer_org_ids #44 and fix(hooks): re-stamp on update only when the write names a source field (#43, #22) #46);
• restore platform staff visibility on the default driver — the release blocker;
• make both drivers agree for this app entirely, since every object would then be tenancy-disabled and outside the divergence objectstack#16589 describes;
• fix a seeker bug in passing — seeker_own_offers (candidate_user == current_user.id) currently yields nothing on sqlite because a seeker sits in the Default Organization while offers carry org_ats_*. Measured: seeker reads 0 offers today.

And it follows the precedent already in §03: ats_job and ats_application are outside the wall for joint-ownership reasons, and they carry the largest and most sensitive volume (40 and 200 rows).

What it costs, stated honestly

1. The app would have no walled objects at all. §03's "tenancy wall split contract" becomes a contract with one side empty, and that section should be rewritten rather than left describing a split that no longer exists.
2. The forward-compatibility story changes. §03 says the split is 前向兼容 — when a walled posture is eventually raised, walled objects gain engine-level isolation stronger than RLS. Moving them out forfeits that, permanently and by choice, rather than deferring it.
3. Defense-in-depth goes from two layers to one on those four objects. RLS is proven working today, but Employer-side RLS policies fail closed for everyone: IN (current_user.accessible_org_ids) is the deprecated SQL-style spelling and the bridge cannot bind the variable #18 is a reminder of what happens when the layer everyone relies on silently stops binding — for a year, with all three gates green.

Point 3 is the real argument against, and it is not weak: the entire reason this repository has a §03 is that a single silent layer failed and nobody noticed.

The alternative worth weighing against it

Do nothing here and treat it as upstream's: under single posture the platform logs "Layer 0 is inert" while the driver scopes by organization anyway, and a wildcard viewAllRecords cannot reach past it. If that inconsistency is resolved upstream (objectstack#16589 names it), the four objects stay walled, platform staff get their rows, and nothing in this repository changes. The cost is that the demo's default path stays broken until someone else's fix lands, on someone else's schedule.

Recommendation

Move the four out, and rewrite §03 to say why — with point 3 recorded in the section as the accepted risk, not omitted. The isolation is real and measured, the divergence disappears, the demo works on the driver a newcomer actually uses, and a seeker bug closes for free. If the wall is wanted back when a walled posture is real, putting these objects back is a one-line change per object and the RLS layer stays underneath it either way.

⛔ Not dispatching this on my own authority: it deletes a security layer from four objects and rewrites a §03 section the maintainer asked for by name. Waiting on a decision.

---

Generated by Claude Code