# 2.6 The Role Contract (/ai-worker-paradigm/what-is-an-ai-worker/role-contract) --- type: Document title: "2.6 The Role Contract" description: "The Role Contract, a worker's portable, owned and checkable one-page definition, with its template and two contrasting workers." status: stable order: 102.6 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-10-04T06:31:02Z chapter: "02" part: I expert_status: required concepts: [ "2.6" ] last_verified: 2026-10-03 generated: at: 2026-10-04T06:31:02Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:c93b28093c2f70c60faae2645a693d881b657ff94d00f7dd9f8c06427ff61c87 dirty: true ksor_version: 0.0.60 --- **In everyday life.** Think of a written job posting for a part-time bookkeeper. It lists the duties, the hours, who she reports to, what she may sign, and how her work will be reviewed. The **Role Contract** is the portable business definition of a worker: all sixteen elements of the anatomy from 2.1, written down on one page. It is not a legal contract. Three properties make it useful. It is portable, because it keeps business requirements apart from implementation choices. Business systems, such as the accounting system, can be named under tools and channels. But no AI vendor or model is named outside the runtime needs. The role survives a change of AI vendor, although the implementation must be retested. It is owned, because the company controls it and can export it, rather than leaving it only inside an AI vendor's settings. And it is checkable, because every line can be tested against what the worker actually did. ```markdown # Role Contract: Draft , ## Who it is Identity: Role: Mission: Owner: ## What it owes Responsibilities: KPIs: ## What it works with Knowledge sources: Memory: Skills: Tools: ## What bounds it Authority: Escalation: Evaluations: ## How it runs and is reached Channels: Triggers: Runtime needs: ## Open questions ``` This is a first draft. Chapter 3 adds the review rhythm around it. Chapter 7 turns the authority line into a full Authority Envelope, the exact limits of what it may do. Chapter 12 completes it as a specification. A good first draft passes four checks. Every field has an entry or an open question. The owner is a person, not a team. Authority is written as verbs, one per action. And no AI vendor or model name appears outside the runtime needs. Remember that a written line states a rule but does not enforce it. Tool permissions, approval steps and tests enforce it, and Chapter 7 builds them. ## Two contrasting workers The AP Worker is the one worker you build in full. The two workers below have the same sixteen elements, applied to different work. The anatomy is not only for accounting. > **Contrast: a compliance research worker.** A manufacturer's compliance team asks the same kinds of question every week. Does this new chemical need an updated safety sheet? Which state rules apply to a warehouse in Nevada? The worker's mission is to answer those questions from the approved rules, with a citation for every claim. Most of its sixteen elements are simple. It acts on nothing outside the team, so its authority line is short: it may observe and recommend, never execute. Three elements matter most. Knowledge is almost the whole job: which rules, which versions, approved by whom. Escalation is unusual, because the worker's most important skill is to abstain. When the rules do not answer the question, it says so and sends the question to the compliance lead, rather than guessing. And its evaluations test abstaining as much as accuracy: a set of questions with known answers, plus questions it must refuse to answer. The surface is research for new questions and a project for the standing rules. A capable model at higher effort is worth its cost, because a wrong citation is the failure that matters. Its KPI is not speed. It is answers that are still correct when an auditor checks them. Its owner is the head of compliance, by name. > > Same anatomy, different work. > **Contrast: a customer support worker.** An online store's support worker answers order questions by chat and email, all day. Different elements matter most here. It has many channels. A customer who starts in chat and then writes by email must meet the same worker with the same limits. Triggers are constant: every new message starts work. Authority is limited but clear. The worker may look up an order and explain a policy. It may execute a refund up to $50, but a larger refund or any change to an account goes to a person. Escalation must also find the customer who is angry, confused or asking for something the policy does not cover. Its KPIs are first-contact resolution, which means solving the problem the first time the customer asks, and customer satisfaction. Its evaluations replay real conversations with personal details removed, including aggressive ones. Because there are many messages and most questions are simple, a fast, low-cost model handles the everyday ones. Harder cases go to a larger model, or to a person. Its owner is the support manager, by name. > > Same anatomy, different work.