Ledger Append-Only Enforcement Automation: Membership Answered a Question It Was Never Asked

Row-level security scoped to organization membership answers a genuinely important question — whose data is this — and for the great majority of a product's own tables, that answer is also the complete answer to who may write to them: any member of an organization can reasonably read and write their own organization's ordinary operational records. A financial ledger is a specific, narrower case: its entire value as a ledger comes from being a trustworthy, permanent history of what happened, which means the real question for an UPDATE or DELETE on one of its rows is never really "does this caller belong here" — it is "should this kind of change be possible at all, by anyone, outside the one function built to apply it correctly." A security model that only ever answers the first question has, by construction, no way to also answer the second.

Granting any organization member equal read-and-write access to their own organization's tables is the natural default, and for the overwhelming majority of a product's tables, it is also the entirely correct one — most operational data genuinely is meant to be editable by any legitimate member. The gap opens specifically for the narrower class of record where the real rule is not about WHO but about WHAT KIND of change: a ledger, by definition, is supposed to only ever grow, never be edited or shrunk after the fact, and that property has to be enforced as its own explicit, separate rule — it is not something ordinary tenant-scoped access control was ever built to express on its own, and a table's default database privileges, granted automatically on creation, will not narrow themselves down to match that stricter rule without someone deliberately doing so.

Centriu Loop's own cashback ledger previously enforced only organization-scoped row-level security — any authenticated member of the organization a row belonged to could read it, and, because the table's own default database privileges had never been narrowed, could also directly UPDATE or DELETE it, entirely outside the dedicated function meant to apply and record every legitimate movement correctly.

The fix closes the gap with three independent, deliberately overlapping layers, because the migration's own reasoning is explicit that no single one is sufficient alone. First, a database trigger fires before any update or delete on the ledger table and unconditionally raises an explicit error — and this layer is enforced even for the platform's OWN privileged backend connection, which normally bypasses row-level security by design as the trusted path the application itself uses. That is a deliberate, stricter choice than exempting a trusted backend identity: correcting a mistaken ledger entry, even from the application's own official code path, must always mean recording a new, separate, opposite entry — never editing or deleting the original. Second, the permissive update policy that had allowed the write is removed outright. Third, the underlying UPDATE, DELETE, and TRUNCATE privileges themselves are revoked from every role the table had ever granted them to — closing the gap not just for the row-level security layer, but for the privilege layer underneath it as well.

The fix was measured directly against a real PostgreSQL 16 database, before and after, using the schema state that matched what production's own catalog showed at the time. The first attempt at that measurement produced a false result: a `set local` statement used to simulate an ordinary member's identity, issued outside an explicit transaction block, silently has no effect in PostgreSQL — the session quietly continued running as the database superuser, which bypasses row-level security entirely by design. What caught the error was a POSITIVE CONTROL built into the same test: a cross-tenant write, from a different organization entirely, that should always fail regardless of anything else being tested. When that control unexpectedly "succeeded," it proved the instrument itself was not measuring what it claimed to measure — a superuser can write anywhere, tenant or no tenant. The test was corrected to genuinely assume an ordinary member's identity inside its own transaction, and re-run: the same-org member's UPDATE returned exactly one affected row before the fix and zero — a genuine permission denial — after it; DELETE showed the identical pattern; the cross-tenant control correctly failed in both runs; and an ordinary, legitimate read of the same row was completely unaffected, returning the identical single row before and after.

Before the fix, an ordinary member of their own organization could issue a direct UPDATE against a real ledger row and have it succeed — altering a permanent financial record with the same ease as editing an ordinary settings field, entirely outside the function meant to apply and validate a legitimate change. After the fix, the identical UPDATE, issued by the identical member against the identical row, is refused outright by the database itself — measured directly, not merely reasoned about, against Loop's own live production catalog.

Centriu Loop's cashback ledger now rejects any direct update or delete at the database level itself — through a trigger, a removed policy, and a revoked privilege, together — closing a gap where any authenticated member of their own organization could alter or delete a permanent financial record directly, bypassing the function meant to apply and validate every legitimate movement.

This automation covers specifically the write-protection of Centriu Loop's own cashback ledger table. It is a distinct mechanism from this pillar's separate pages on Loop's expiration and reconciliation model, and on how a wrongful credit is now corrected as a distinct chargeback entry — both build on top of this same append-only foundation but address different, separately-covered questions.

Granting any organization member equal read-and-write access to their own organization's records is simpler to build and correct for the great majority of a product's own tables. A ledger is a deliberate exception: its value depends entirely on being unable to be rewritten after the fact, a property tenant-scoped access alone was never built to express. Enforcing that property at three independent layers — a trigger, a policy, and the underlying privilege grant — rather than any single one alone, is the only version of the two that survives a gap being found in any one specific layer, which is exactly the reasoning the fix's own migration states explicitly.