Who can change what
This module gives you the line the system draws between who runs work and who can change the structure underneath it, so you can decide who on your team holds what.
Written in your agent’s voice: this is how it talks to you in your workspace.
Most people run work and feed back the friction they hit.
A few can change the structure — the rules, the safeguards, the skills, the methodology in a domain’s knowledge.
I enforce that line on every change, the same way every time.
Every role answers two questions: where, and how much
A role is two settings, and that is the whole model.
- Where is the scope. Either the whole system — every domain, the rules, the safeguards — or one domain and nothing outside it.
- How much is the role. A builder or an owner.
When you decide what to hand someone, you are answering these two questions for them.
Five named roles fall out of these two settings — end user, domain owner, domain builder, content builder, system owner — and the next module gives each one its job description.
A builder changes the machinery
Inside their scope a builder writes the skills, the safeguards, the rules, the structure itself.
A builder is the only role that touches the enforcement layer — the checks that fire on every action and the rules that load every session.
A system builder can do that anywhere, which is why that grant stays with the platform team and the system account: a change there lands on the whole workspace.
A builder scoped to one domain can do it in that domain only — a domain expert who ships the tooling for their own domain without reaching anyone else’s.
When you want a builder’s work, hand them the outcome, not the method:
"Build me a check that blocks any proposal from going out off-brand."
A domain owner changes the methodology, not the infrastructure
Inside their domain an owner writes the skills, the references, the decision log, the roadmap — everything that keeps the method right.
What an owner cannot touch is the enforcement layer, because it carries beyond their domain.
A marketing owner can rewrite their content methodology and lock the decision into the domain’s knowledge.
But a request for an automatic check that blocks off-brand output goes to a builder, because that check fires across the workspace.
When you own a domain and want to fix the method, say what is wrong and lock it in:
"Our proposal opening is too long — here’s the rule, save it as the decision so every future proposal follows it."
The end user changes nothing structural
Most of your team are end users: they use the system and get the work done.
An end user can always say "remember this about me" — that lands in their profile.
And "turn this into feedback" — that lands in the domain’s feedback log, where it reaches the owner who can act on it.
An end user cannot change knowledge, skills, or rules directly; feedback is how they reach the people who can.
The grant is data, not a handshake
Each person’s scope and role live in one record — the access roster.
The roster is a file the system carries; I read it on every change to allow or deny that change before it lands.
No matching role, no change.
Because the grant is recorded and enforced, "who can change this, and who did" is a question you answer from the record, not from someone’s memory.
To see where someone stands:
"What scope and role does Patrick hold, and what does that let him change?"
Two frames are worth knowing
The same model reads differently depending on whose workspace you are in.
- In this builder workspace, the whole team carries the full builder grant.
- It is a sandbox where heavy users optimize the product they sell, so a domain’s ownership marks accountability, not a write restriction.
- In a client workspace, the grant is tighter: the client’s owners get owner scope on their own domain, the platform team holds the system-builder grant everywhere for platform work, and the client decides who owns what.
The one thing to remember
Every role is two settings — a scope that says where, and a role that says how much — and a builder is the only one who touches the enforcement layer.
The grant lives in the access roster, and I read it on every change, so the line is enforced the same way every time and you can always trace who changed what.
Next: the five role job descriptions.