Mersal Who May See What
A permission you can click around is not a permission
Most access control in legal software is decoration. The screen hides a button. The menu omits an option. The associate does not see the restricted matter, because the interface chose not to draw it. This is politeness, not security. The record still sits in the database, one crafted request away from anyone whose session reaches the server.
The distinction matters because interfaces are the softest layer in any system. They are rewritten, bypassed, and inspected. A rule enforced only at the screen is a rule that depends on every future engineer, every export path, and every direct query respecting an agreement they may never have read. That is not a control. It is a hope.
The question is not what a role is shown. The question is what a role can reach.
Four roles, one boundary the engine keeps
A firm runs on distinct hands. The partner carries the client relationship and the liability. The associate drafts and advances the file. The paralegal assembles and files. Billing prepares the money and answers to the auditor. Each needs a different reach, and the reach of one is the exposure of another.
In Mersal, Row-Level Security at the database engine filters every query by firm and by role, so a restricted matter is invisible to anyone outside its circle with no application-side path around it. The boundary does not live in the page. It lives one layer below every page, every export, and every report, in the place the data actually rests.
Consider the consequence. A paralegal building a filing index cannot enumerate a partner's sealed engagement. A billing clerk exporting the month cannot surface a matter walled off for conflict reasons. The wall is not drawn by the menu. It is drawn by the engine that answers the menu.
Governance becomes physics
The same principle extends past who reads to who may act. Associates cannot activate matters alone; the approval gate is enforced by the database, not by a disabled button an eager hand might re-enable. The audit ledger rejects modification through triggers that fire before every update and every delete, for every role including administrators. Nobody edits the record of what happened, because the record refuses the edit at the level where edits are made.
Policy written into a handbook is a preference. Policy written into the engine is a constraint. The difference is whether the rule survives the person who wants to break it.
A firm's promises about confidentiality are only as strong as the weakest place they can be undone. Move the boundary from the interface to the engine, and the promise stops depending on discipline, memory, or the honesty of the next query. The partner's sealed matter is not hidden from the associate; it is unreachable. The audit trail is not discouraged from tampering; it declines. Governance you can click around is advice. Governance the database keeps is law.
Matters, conflicts, VAT billing, sealed receipts and the docket, in one defensible system.