Role Contract, Not a Prompt: How AI Operators Are Governed in Rocket Routine OS

You write a prompt. The AI delivers a result. Sometimes it is exactly what you needed. Sometimes it goes in the right direction but requires rework. Sometimes it misses the point entirely. You correct, rephrase the prompt, try again. Next time, the same thing happens in a different variation.

The problem is not the AI. The problem is that a prompt is not a control instrument.

A prompt describes what you want right now. In this moment, for this one task. It contains no boundaries. No quality criteria. No decision rights. No escalation rules. No mechanism that ensures the result meets a verifiable standard. A prompt is an instruction. A Role Contract is a governance artifact.

A prompt describes what you want right now. A Role Contract defines what an operator may, must, and must not do on an ongoing basis.

What happens when you deploy AI without governance

Most companies using AI today are doing essentially the same thing: giving a language model instructions and hoping for usable results. Some have more sophisticated prompts than others. Some have prompt templates. Some even have prompt libraries. But the underlying structure is identical: a human formulates an instruction, a model produces an answer, a human evaluates the result.

That works for ad-hoc tasks. For anything done once and never again. For the quick summary, the one-off draft, the spontaneous research request.

It does not work for recurring work. And in a company, the vast majority of work is recurring. The weekly report. The daily quality check. The monthly analysis. The routines that keep the business running.

When you delegate recurring work to AI without explicit governance, three things happen:

1. Quality fluctuates. Without defined quality criteria, the human reviewer decides every time whether the result is "good enough." That is subjective, inconsistent, and does not scale.

1. Boundaries blur. Without an explicit scope, the AI does more or less than intended. It makes decisions it should not make. Or it asks for clarification on things it could have resolved on its own.

1. There is no learning. When every cycle depends on a new prompt, there is no mechanism that improves the system. Mistakes repeat. Good outcomes are accidents, not system properties.

The Role Contract: eight components

Rocket Routine OS solves this with a formal artifact: the Role Contract. A Role Contract is the complete specification of what an AI operator may, must, and must not do within the system. It consists of eight components.

1. Purpose and scope boundaries

What is this operator's job? And, equally important: what is not its job? A content operator produces content to defined standards. It does not decide on content strategy. It does not change the branding. It does not communicate directly with customers. The boundary is as important as the mandate.

2. Outcomes and metrics

What measurable results must the operator deliver? Not "good content," but: weekly blog article meeting defined quality criteria, FTT rate above 80 percent, terminology matching the Knowledge Base vocabulary. Measurable. Verifiable. Non-negotiable.

3. Routine ownership and standard outputs

Which recurring routines belong to this role? What artifacts does the operator produce by default? A content operator might own three routines: blog production (weekly), LinkedIn derivation (three times per week), quality review of existing content (monthly). Each routine has a defined output and a defined cadence.

4. Decision rights, approvals, and escalation

This is the core. Which decisions may the operator make independently? Which require approval? And in which situations must it escalate?

A content operator may independently choose which synonym to use. It may not independently decide whether a new topic enters the content plan. When a quality criterion is ambiguous, it escalates rather than picking an interpretation.

Decision rights do not define what an operator can do. They define what it may do. That is the difference between a tool and a governed actor.

This gradation uses the Decision Impact Classification from the Rocket Routine OS concept. Leaf decisions (routine, low risk) are made by the operator. Branch decisions (operational, medium risk) require approval. Trunk and Root decisions belong to the human.

5. Tool access policy

Which tools may the operator use? With what permissions? A content operator has read access to the Knowledge Base, write access to the content workspace, and no access to financial data. Read and write permissions are defined separately. No operator gets more access than its role requires.

6. Quality confirmation duties and evidence types

What must the operator prove to report a result as complete? What kind of evidence is required? A content operator must demonstrate for every article: vocabulary check passed, scope discipline maintained (only topics from the source article), both language versions produced as standalone texts, no prohibited terms used. This is not an optional checklist. It is an obligation.

7. Interfaces

What does the operator consume from other roles and domains? What does it produce for others? A content operator consumes the weekly topic from the content pipeline (Marketing domain) and the vocabulary from the Knowledge Base (Knowledge domain). It produces finished articles for the publication routine (Marketing domain) and social media derivations for the Social operator. Interfaces are explicit. No operator works in isolation.

8. Upgrade rules

How is the Role Contract updated when the system learns? Every time the Impact phase identifies a deviation, the question is asked: does the cause lie in the Role Contract? Is a boundary missing? Is a decision right too broad or too narrow? Does a quality criterion need sharpening?

A Role Contract that never changes is a sign that nobody is learning from the results.

Upgrade rules define who may change the contract, under what conditions, and through what approval process. This ensures contracts evolve without being altered arbitrarily.

Poka Yoke: preventing errors by design

If you come from the quality management world, you know Poka Yoke. The principle originates from the Toyota Production System and means: design the process so that errors cannot happen, rather than finding and correcting them after the fact.

Role Contracts are built on this principle. The scope boundaries prevent the operator from taking on tasks outside its role. The decision rights prevent it from making decisions beyond its authority. The tool access policy prevents it from accessing data it does not need. The quality obligations prevent unchecked results from being reported as complete.

This is not distrust of AI. It is good system design. The same principles apply to human roles in well-run organizations. The difference: with human roles, these boundaries are often left implicit and only become visible when someone crosses them. With AI operators, they must be explicit, because a language model does not reliably interpret the implicit.

Three levels of adoption

Not every operator starts with full autonomy. Rocket Routine OS defines three Adoption Levels for every operator in every domain:

1. Shadow. The AI creates drafts. The human executes. Every result is manually reviewed before it takes effect. This is the entry level: you see what the AI produces while retaining full control.

1. Copilot. The AI executes, but within explicit approval gates. A content operator in Copilot mode produces the article and delivers the quality evidence. The human approves or sends it back. The AI works, the human decides.

1. Autopilot. The AI executes and delivers within the strict boundaries of the Role Contract. The human steers by exception and reviews through audits. Quality confirmation runs automatically against the defined criteria. The human intervenes when metrics deviate, not on every individual result.

The transition between levels is not arbitrary. It is based on measurable performance: when an operator's FTT rate consistently exceeds the threshold across multiple cycles, the next level can be activated. When it drops, the operator moves back one level. This is not a manual vote of confidence. It is a data-driven decision.

What happens in Company 0

I have been running a content operator with a Role Contract in Company 0 for several weeks. The operator has a clearly defined purpose: produce content across all channels, derived from the weekly blog article, in compliance with the brand rules.

A concrete example. Last week, the operator wrote the blog article on the I2I loop. In the Impact phase, quality confirmation identified that a phrase in the German text used a term not defined in the vocabulary table. The result: the operator was not corrected. The Role Contract was updated with an explicit rule requiring every technical term to be checked against the vocabulary table before the result is reported as complete.

That is a small example. But it illustrates the mechanism. The Role Contract is not a static document. It is a living artifact that improves with every cycle. And because the upgrade rules are defined, that improvement happens systematically, not by chance.

The operator currently runs at Copilot level. I review every result before it is published. The FTT rate stands at 75 percent after three weeks. That means three out of four results pass quality confirmation on the first attempt. That is a starting point, not a target. With every upgrade iteration, the rate increases.

Why this is not "a better prompt"

You might be thinking: this sounds like a lot of work. Why not just write a better prompt?

The answer lies in the difference between an instruction and a system.

A prompt is ephemeral. It exists in one context and disappears after. It has no memory of previous cycles. It has no built-in quality check. It has no defined boundaries that persist beyond the current invocation. And it has no upgrade mechanism.

A Role Contract is persistent. It survives the individual cycle. It defines what should hold true across many cycles. It contains the quality criteria against which every result is measured. And it has a built-in mechanism that improves it when the results demand it.

The prompt says: "Do this." The Role Contract says: "This is how you work. Within these boundaries. With these rights. Against these standards. And when something is off, the contract changes, not just the next prompt."

Why this is not a skill either

If you follow the AI agent space, you know the concept of skills: reusable instruction packages that teach an agent how to perform a specific task. A skill for blog production contains the steps, the templates, the formatting rules. A skill for data analysis contains the query logic, the visualization standards, the output formats.

Skills are capabilities. They describe the how.

A Role Contract describes something different. It describes the who, the what, the under-which-conditions, and the with-which-rights. A skill tells the operator: "This is how you write a blog article." The Role Contract tells it: "You may write blog articles, within this scope, with these decision rights, against these quality criteria, and when something is off, the contract is updated."

The two concepts work together but are not interchangeable:

1. A skill is a capability. It defines a procedure. It has no concept of decision rights, escalation rules, or quality obligations. A skill does not know whether the operator is even authorized to execute it.

1. A Role Contract is a governance artifact. It references skills as part of routine ownership (component 3) and the tool access policy (component 5). But it adds everything a skill cannot contain: boundaries, rights, obligations, upgrade mechanisms.

1. A skill without a Role Contract is an ungoverned capability. It can be executed, but nobody has defined who may execute it, what quality standard applies, or what happens when the result is off.

The analogy from the human work world: a skill is like knowing how to write code. A Role Contract is the job description, the authorization matrix, and the quality standards combined. Knowing how to code does not tell you what you are allowed to ship.

A skill without a Role Contract is a capability without governance. The Role Contract turns a capability into a governed responsibility.

The Role Contract inside the I2I loop

The Role Contract does not exist in isolation. It is embedded in the I2I loop that I explained in Blog #3.

In the Intent phase, the Role Contract defines what results the operator must deliver and under what conditions. In the Insight phase, it determines which decisions the operator may make and which methods it must apply. In the Implementation phase, it governs which tools the operator may use and which routines it executes. In the Impact phase, it provides the criteria against which the result is checked and the upgrade rules that determine how the contract evolves.

The Role Contract is therefore the link between the universal control principle (I2I loop) and the concrete execution. The loop defines the cycle. The Control Tower makes it visible. The Role Contract makes it operational by specifying who does what under which conditions.

What comes next

The Role Contract governs the individual operator. The I2I loop governs the cycle. But where do the structures come from within which operators work? Next week, I will explain how Rocket Routine OS defines the artifacts every domain needs: Outcomes, Metrics, Principles, Routines, Initiatives, Knowledge, Learning. Seven artifact types, one canonical model. OMPRIKL.

If you are running a founder-led B2B company with 15 to 50 employees and you want AI operators that work within clear governance: rocket-routine.com