Put the rules where they can't be skipped
Why Vault enforces who-can-see-what in PostgreSQL itself (147 row-level security policies) instead of trusting every endpoint to remember.
Vault is built for an organisation of roughly twenty-two thousand people, arranged in six tiers, where every person may only see the people below them.
The usual way to build that is to check permissions in the API: every endpoint looks up the caller, works out their scope and filters the query. It works, until someone writes the hundred-and-first endpoint and forgets.
Moving the rule down a layer
In Vault, access control lives in PostgreSQL itself, as row-level security. Today that's 147 policies. When the API asks for a ward's roster, it asks as an actor, and the database only returns the rows that actor is allowed to see. An endpoint that forgets to filter returns nothing it shouldn't, because the filter isn't its job.
That changes the failure mode completely. A bug in the API is now a bug that returns too little, not too much.
"View as", for free
It also made a feature that is usually dangerous almost trivial. Commanders need to see exactly what a subordinate sees: to help, to check, to cover when someone steps away. In most systems that's an admin backdoor. In Vault it's the same query, run as a different actor, through the same policies. There is no second path to get wrong.
The map has to be real
The other rule that lives at the bottom is the map. The electoral areas (5 local governments, 56 wards and 731 polling units) were parsed from the electoral commission's own file and validated against the published totals before anything was seeded. Unit codes are checked by a database constraint against the official format.
Every placeholder code in the early designs was thrown out. One of them had the right shape and the wrong state number; it would have looked fine for months.
Open questions are data
Some answers don't belong to engineers: which local government splits across two sectors, which wards get a second command. Those are modelled as data, not code. When the decision comes, it's a few rows, not a migration.
The general lesson
Put a rule at the lowest layer that can enforce it. Everything above that layer gets simpler, and every future bug gets smaller.