Least privilege, staged by sensitivity.
At the scale this platform targets — real-time money movement and assets under custody — the governing rule is least privilege: engineers hold access to exactly what their role requires. For the most sensitive parts of the system, the ability to read is itself treated as a risk and restricted accordingly.
Three tiers of sensitivity
Every component of the platform sits in one of three tiers, and the tier determines who may read it and who may change it.
Foundation
The kernel and the published contracts that everything else depends on. Readable across engineering; changed only by a small platform group.
Shared
Most domain capability — accounts, custody, compliance, intelligence. Readable across engineering, with the component owner gating every change.
Restricted
Money movement, and the trust surface: cryptography, key handling, and authorization. Access is granted person by person to the responsible team, and read access alone is a deliberate grant.
Separation of duties
The controls are designed so that no single person can move money-path code from idea to production alone.
An owner for every path
Each part of the system has a named owner, and changes to it require that owner’s review rather than general approval.
Author is not sole approver
On money-path and trust-surface changes, the person who wrote the change cannot be the only person who approves it.
Boundaries, not folders
Components depend on the kernel and on published contracts, never on another component’s internals — which is what makes the boundaries real rather than cosmetic.
Staged isolation
The boundaries exist before the teams do, so raising a component’s tier is a procedure rather than a rewrite.
Reviewing us as a vendor?
Security, compliance, and audit teams can request the operational detail behind this governance model, including the control descriptions used in review.