The direction of the failure is what makes a one-tenant fixture useless as evidence. Row-level security fails by returning rows the caller should not see, never by returning zero, so a fixture that holds nothing to refuse cannot tell a working boundary from an absent one [8]. The scoped assertion most people write, serving role returns only its own rows [12], comes back green in that fixture whether the policy applies, sits inert because the app account owns the table, or was never written at all [7].
Read the grid by columns. One of the five builds is sound, so four are broken [1]. Equality, the double run that Mads Hansen proposed in reply to the author's earlier piece [13], goes red in exactly one of those four [2], because two runs that both return everything are still equal [14]. Equality has one thing going for it as an assertion: it is green on almost everything. Scoped catches a different single case, the two-tenant table with no policy at all [3]. Disjointness catches three, and equality plus disjointness is the pair that covers all four broken builds [4].
The author's first published assertion was the wrong shape, and he says so. It was assertNotSame on the owner run, asserting the leak, which goes red the day somebody applies the correct fix [5]. Equality survives both worlds because after FORCE the owner sees exactly what the serving role sees [1]. That is the measurement: owner=[1,2] under ENABLE only [3], owner=[1] after FORCE, same fixture, same query [4].
The part worth stealing is how the fixture check itself is written. Proving that a second tenant still exists in the table wants a connection that can see everything, and under FORCE the author reports no such connection is left; borrowing a superuser to look moves the check outside the boundary you are trying to prove [10]. Setting the tenant context to the second tenant and asserting that its set is non-empty and does not intersect the first stays inside it, on the same role under the same policy [11].
For the grid to transfer, the role your application connects with has to own its tables, which is what happens when that same role runs your migrations [2]. A serving role that does not own the table is not covered by the owner exemption in the first place [1], and on that deployment ENABLE alone is doing real work. The other two conditions are yours to check: whether your isolation test is the scoped one, and whether any fixture it runs against contains a second tenant. Marco's line in the thread is the one the author says he would keep, that the fixture is part of the security claim, and if removing the violating state does not make the test fail then the test was never proving the invariant [9].
