Who can open what, and what happens when the system cannot tell

A closed list of permissions

Seven named permissions, and no eighth that a string could invent

Platform Built and running

The permissions an administrator can hold are a closed list of seven, declared once: managing users, managing roles, viewing the audit trail, managing billing, managing settings, viewing support, and managing support. A guard checks membership of that list rather than comparing strings, so a typo is not silently a new permission that nothing grants and nothing denies.

Closed lists are unglamorous and they are most of what access control actually is. The failure they prevent is the one where a feature ships checking canManageUser while every grant in the system says manage_users, and the check therefore passes for nobody or, worse, is skipped.

packages/shared/src/admin-rbac.ts:58 (ADMIN_PERMISSIONS) · :70 (isAdminPermission)

Scope, and failing closed

A grant is bound to a tenancy level, and an unbound grant matches nothing

Platform Built and running

Holding a permission is not enough; a grant is also bound to a level -- platform, district, or school -- and to a concrete identifier at that level. A check has to match both.

The interesting behaviour is at the edges, and it is fail-closed at every one of them. A district or school grant with no identifier bound to it is treated as unbound and matches nothing at all, rather than matching everything. A narrower actor can never contain a broader target. And a district-level actor is only allowed to reach a school when the caller has already established that the school belongs to that district -- the engine will not invent the link to make a check succeed.

Every one of those is a decision to answer "no" when the honest answer is "I cannot tell". That is the property worth paying for in this kind of code and it is invisible from a feature list.

packages/shared/src/admin-rbac.ts:84 (ADMIN_SCOPE_LEVELS) · :137 (scopeContains)

Reading records leaves a trace

An access to personal data is recorded, and an unattributed read is still recorded

Platform Built and running

Access to personal data writes an audit record. The detail that says something about the design is the sentinel for an unattributed actor: when a read cannot be tied to a person, the module records it against a reserved identifier rather than skipping the record.

The alternative -- no actor, no row -- makes the exact accesses you would most want to find afterwards the ones that leave no trace. A gap in an audit trail is worse than an ugly entry in it.

packages/db/src/pii-access-audit.ts:50 (PiiAccessAuditArgs) · :44 (UNATTRIBUTED_PII_ACTOR)

A trail that shows if it was edited

The safety audit ledger is hash-chained, so a quiet edit stops verifying

Platform Built and running

For the highest-sensitivity resources, entries are chained: each one is canonicalised and hashed together with the hash of the entry before it, starting from a fixed genesis value. A verifier can walk the chain and report exactly two kinds of break -- a link whose recorded previous hash does not match, and an entry whose hash does not recompute.

What this buys is narrow and worth stating precisely: it makes tampering DETECTABLE, not impossible. Someone with enough access can still rewrite history; they cannot do it without the chain failing verification afterwards. Any product that describes a feature like this as making records unalterable is describing something that does not exist.

apps/api/src/domain/safety-audit-ledger-hashchain.ts:144 (computeSafetyEntryHash) · :194 (verifySafetyChain)

One way in for writing the trail

Recording is a service with an interface, not a line copied into each caller

Platform Built and running

Writing an audit entry goes through one declared interface with one repository-backed implementation behind it. That sounds like housekeeping and it is the reason the trail is uniform: a caller cannot invent its own slightly different record shape, and a test can substitute the interface without a database.

The failure it avoids is an audit trail that is complete in the three places someone remembered and empty in the fourth.

apps/api/src/services/audit-service.ts:29 (AuditService) · :55 (RepoAuditService)

What the mailbox itself will do

An access-controlled inbox on a system we run -- and it is not provisioned yet

Mailbox Built, latched off

Here is the honest statement about the address rather than the platform. A Castra mailbox is intended to be a real inbox with controlled access, run on our own private system, for the staff who sit closest to sensitive correspondence.

Provisioning is a founder-confirmed step and it is currently off. No mailbox exists to apply any of the controls above to, and no message is being sent or received on this domain today. Every row on this page carrying the platform chip is describing the system the mailbox will live inside, and this row is the one that tells you the room is not built yet.

That distinction is the whole reason this site puts a scope chip on every claim. Without it, the four rows above read as features of your inbox, and they are not.

mailbox/brands.ts:502-533 (the brand's own promise) · mailbox/pricebook.ts (honest-off)