Your first Role Contract. Eight components, one afternoon.

In short: The data question is really two questions. Where processing happens is your vendor’s answer. What the system may touch is yours to design, per tool, with read and write kept apart.

A Role Contract sounds like a document you set up a project for. It is not, and the first one takes an afternoon, provided you start in the right place.

What a Role Contract is, and why it is something other than a good prompt, I have covered elsewhere. This piece is only about writing your first one.

Do not start with the AI

The most common mistake happens before the first sentence. Most people sit down and think about what the AI could do. That produces a wish list, not a contract.

Start instead with work that already exists in your company, that recurs, and where you can say what a good result looks like. If you cannot meet that third condition, pick different work. A task nobody can write a standard for is the wrong first role, however much time it eats.

A first Role Contract is not a job description. It describes recurring work for which you can define "done".

Keep it small as well. One routine, not a department. "Weekly sales report" is a first role. "Sales" is not.

The eight components

A complete Role Contract has eight mandatory components. Here they are in order, each with the mistake that most often goes with it.

1. Purpose and scope boundaries. One sentence on what the role is for, then the more important part: what it is explicitly not for. The usual mistake is writing only the purpose. The boundary is the half that prevents arguments later.

2. Outcomes and metrics. What the role answers for, and how that gets measured. If no metric comes to mind, that is a signal about the task, not about your imagination.

3. Routine ownership and standard outputs. Which recurring workflows belong to it, at what cadence, and what concretely comes out at the end. "A report" is not enough. "A report in this structure, on Fridays, containing these five numbers" is.

4. Decision rights, approval gates, escalation triggers. What the role may decide alone, what needs approval, and what must go up. The mistake is settling this during the first incident. Sort the recurring decisions by impact in advance and write down at least one concrete threshold at which a case reaches you.

5. Tool access policy. Read and write boundaries, per tool, on the least-privilege principle. Not "access to our systems", but per system and per direction. Write access is the exception you justify.

6. Quality confirmation duties. How it is checked that a result meets the standard, and what evidence the role supplies with it. This is where FTT (First Time Through) belongs, the share of outputs that pass the check on the first attempt. Without this component you have a description, not governance.

7. Interfaces. What the role receives from others and what it delivers to them. The mistake is designing the role in isolation. Most friction appears at the handovers rather than inside the work.

8. Upgrade rules. How the contract changes when something is learned. This is the component almost everyone omits, and it decides whether the role improves over time or stays exactly as good as you made it. A learning only counts when it changes an artifact, and this component says which one.

The first draft is allowed to be short

One page is enough. If your first contract runs past two, you have almost certainly described a department instead of a routine, so go back to the start and cut it smaller.

A fair objection at this point: how am I supposed to know what is realistic in components 4 and 6 before trying it? You are not, and you do not have to. That is why a new role starts at the Shadow level: it drafts, humans execute, and across a few runs you see where your standard was too vague. A first contract is a hypothesis with boundaries, not a finished rulebook.

Write it so the first run can disprove it. That is exactly what the upgrade rules are for.

Company 0

The Role Contract for our content-marketing operator fits on one page, and it works as an example because I can name all eight components concretely.

Purpose is weekly content production, explicitly not strategy and not pricing statements. Outcomes hang off published articles in two languages. The routines are the weekly sequence with defined outputs: article, LinkedIn posts, image prompt. Decision rights stop at the Leaf level, anything above reaches me, and one concrete trigger is any statement containing a commitment about price, dates or legal matters. Tool access is read on the knowledge base and calendar, write on drafts, and not write on the CMS. Quality confirmation is a fixed checklist, currently thirteen edit patterns, with FTT over the top. The interfaces are SEO input in and finished assets out. And the upgrade rule is the one that makes this blog interesting: whatever a review catches becomes a new rule in the checklist rather than a correction to a single text.

That last line is why the list grew from zero to thirteen in four months, and why none of those thirteen rules was written preventively.

What this means for you

Take an afternoon and a single piece of recurring work. Write the eight headings underneath each other and fill them in that order. If you cannot find a metric at component 2, or cannot state a check at component 6, you have not picked the wrong format, you have picked the wrong first role. Take a different one and the rest goes quickly.

And do not skip component 8, even though it feels superfluous the first time. Without it you have a role that stays exactly as good as you managed to make it in one afternoon.

Frequently Asked Questions

What is a tool access policy?

A mandatory part of the Role Contract: read and write boundaries, defined per tool, on the least-privilege principle. Not "has access to our systems", but set per system and per direction.

Why does the difference between read and write access matter so much?

An operator with read access can draw a wrong conclusion, and quality checks catch that. An operator with write access changes the state of your company. That is why write access is the justified exception rather than the default.

Where is my data processed with an AI Operator?

Your vendor answers that, not the operating system. Rocket Routine OS is deliberately provider-agnostic: the client decides which language model runs underneath, and that decision can change without the governance above it changing.

How do I start setting access boundaries?

With a four-column table: which system, read or write, which slice, and who notices if something wrong gets written. If you can fill it in for your first role, you have a tool access policy.