What you decide vs. what the builder decides
This module hands you the one line that keeps an owner and a builder out of each other’s way.
Written in your agent’s voice: this is how it talks to you in your workspace.
Most friction inside a domain comes from a single blurred line: who decides what gets built, and who decides how.
Hold that line clear and the two roles never collide.
You decide what and why; the builder decides how; shipping needs both
The two roles are two different kinds of decision.
Owner is governance.
You set the method, you ratify the calls, you curate the domain’s knowledge.
What you’re solving, who feels the problem, what success looks like, and how it ranks against everything else — those are judgment calls about your domain, and they’re yours.
Builder is implementation.
They write the skills and ship the tooling.
The shape the fix takes, where it lives, and what happens if it fails — those are engineering calls, and they’re theirs.
Nothing ships on one signature: you approve that it solves the right problem, the builder confirms it works.
When you’re not sure whose call a question is, this settles it.
| Question | Yours (owner) | The builder’s |
|---|---|---|
| What problem are we solving? | yes | — |
| Who has the problem? | yes | — |
| What does success look like? | yes | — |
| What’s the priority against everything else? | yes | — |
| What shape should the fix take? | — | yes |
| How far down the stack should it go? | — | yes |
| What’s the undo if it doesn’t work? | — | yes |
| Does this ship? | both — you approve, the builder confirms |
To hand a question across the line, say it plainly:
*"As owner, I’m deciding the priority.
The shape is yours to call."*
The tell that you've crossed the line: you've started naming the mechanism
The moment you say "build something that does X," you’ve jumped from what to how — and you’ve shrunk the builder’s options before they ever saw the problem.
The fix is to restate the outcome and stop.
- Crossed the line: "build a hook that blocks every send until I approve."
- Back on your side: "outbound work should never go out without my sign-off — solve that."
You named the problem and what success looks like; how to get there is the builder’s, and they may know a cleaner path than the one you’d have spelled out.
The line runs both ways.
If a builder starts deciding what the work is for or how it should rank against the rest of the domain, that’s your half — say so:
"That’s a priority call — let me set that, then you take the shape."
When you wear both hats, switch hats out loud
Plenty of domains have one person owning and building at once, and the two kinds of decision stay two different decisions.
Name which one you’re making as you make it.
- "As owner, the priority this week is faster proposals."
- "As builder, the cleanest place for that is the proposal step, not a new skill."
Switching hats inside one head is harder than handing off to another person, because nothing outside forces the seam.
Saying it out loud forces it — and it keeps the pull of building from quietly resetting the priorities you set as owner.
Why the line is enforced, not just encouraged
The owner-builder roles live as an encoded rule in the roles model — owner is governance, builder is implementation, and the roster records who holds which role on each domain.
It’s not advice.
The structural-access-control hook checks who you are against the roster before any structural write, so a builder edit to a domain’s plugin code goes through where an owner-only edit to the same code does not.
So when a change breaks something, who decided what is traceable: you owned the intent, the builder owned the build.
Blur the line and a failure has no clear owner, which means no clear fix.
The hook is what keeps that from happening by accident.
Curating the knowledge your work flows from is the deepest lever on your side of the line.
When you want to teach me something to keep, say "save how we work on this so I work this way from now on" and I’ll build the note properly; the Create-1 module walks the whole craft if you want it.
The one thing to remember
You decide what and why; the builder decides how; nothing ships until you approve the problem and the builder confirms the build.
The tell you’ve crossed the line is that you’ve started naming the mechanism — restate the outcome and hand the how back.
Next: curating knowledge and the cadence