Picture a building that is two things at once. Downstairs is a workshop where a small firm does private, paid work for clients — drawings, plans, things no outsider is ever meant to see. Upstairs is a classroom where people who have never done this kind of work come to learn it, on real tasks, with real tools. Same building. Same front door. Same coffee machine.
That is roughly the situation we found ourselves in. We build private systems for clients, and we also bring complete beginners onto the same platform to learn the trade by doing genuine work. A learner needs the real thing, not a pretend version with the interesting parts switched off. But that same learner must never be able to wander downstairs and read a client's confidential file. Hold both of those at once and you have a genuine problem to solve.
The obvious fix is the wrong one
The instinct is to reach for locks. Give this person a key to that room, deny them a key to this one, and keep a list of who can open what. Permissions, in other words.
We went a step earlier than locks, to a simpler question: who is this person in the first place? Before you decide what someone is allowed to touch, you decide which part of the building they belong to. A learner is given a desk upstairs, in the classroom. They were never issued a downstairs address at all. You cannot read a file in a room you were never placed in — there is no lock to pick, because there is no door from where they're standing.
The wall isn't a key the learner was refused. It's a floor of the building they were never given an address on.
One name, the same meaning everywhere
Here is the dull part that turned out to be the whole job. The building has more than one register that records who belongs where — think of a staff directory and a separate visitor log. The rule we held to, without exception, is that a name must mean exactly the same thing in every register that records it.
It sounds trivial. It is the single point where this kind of system quietly fails. If "the classroom" means one group of people in the directory and a slightly different group in the visitor log, the wall between upstairs and downstairs doesn't fall over with a crash. It just stops being a wall, silently, and nobody finds out until a learner is looking at something they were never meant to see. So we wrote down, in plain words, what each name meant — and made sure every register agreed, letter for letter.
The honest exception
There is one group that does cross between the two worlds: a handful of trusted helpers who work for the firm itself and genuinely need to move between the workshop and the classroom to do their job. We didn't pretend they don't exist. We named them, said exactly which of them may cross, and on whose authority they do it. Everyone else stays on their own floor.
That is the part I'd defend hardest. A boundary that admits its own exceptions — and says out loud precisely who is allowed to step over and why — is sturdier than one that claims to be absolute and then springs a leak at the first awkward case. Honesty about the exception is what keeps the rule trustworthy.
What carries over
If your team builds for clients and teaches newcomers at the same time, don't picture it as one shared room with a complicated set of keys. Picture it as a building with separate floors, and decide which floor each person lives on before you decide what they may touch. Then — and this is the part everyone underrates — write down what each floor is called, and make every register that records it agree. The moment one name means two different things, the wall is already gone. You just haven't found out yet.
For the technical reader
The "building with floors" is a multi-tenant identity model, and the "registers" are two distinct systems: a chat-and-workspace platform and a separate work-item system. Every principal — a person or an agent — belongs to a tenant, and each tenant is a short slug. We fixed a small set of them and wrote the meaning of each one down so it could not drift:
- A private build tenant for the firm's own infrastructure and client work — Brynn and the fleet agents only; trainees have no visibility into it.
- A collaborative workforce tenant — the shared day-to-day space where the HOFMI ministry team and trainees actually work.
- A per-trainee tenant for each cohort member, isolated from the others.
- A leadership-private tenant backed only by the work-item system, with no shared chat space.
The load-bearing invariant: one slug means the same thing in both systems. A tenant exists in both the chat platform and the work-item system, and the hazard we'd already spotted was a mismatch — the same slug standing for one population in one system and a subtly different one in the other. When that happens the boundary doesn't error; it silently stops being a boundary. So the stated rule became: a principal in the workforce tenant must be provably unable to read any work item in the private build tenant. Provably, not probably — the word forces a test rather than a vibe.
The exception is the fleet's shared agents. They are cross-tenant by design: homed in the workforce tenant, where the team lives, but retaining access to the private build tenant to do that work — under the owner's authority, not their own. Workforce agents that belong to a trainee or a team member are the opposite: tenant-locked, scoped out of the private side entirely. That asymmetry is deliberate, and naming exactly who may cross and on whose authority is what keeps the model honest.