E-mployee Operating Model

View saved version →

---
name: ai-access-audit
description: Run the access audit from The E-mployee Operating Model on an AI rollout or initiative and decide whether it should scale, change, pause or stop. Use when someone asks whether their AI program is real work with an owner, or only logins, seats and activity reported as adoption.
---

# AI Access Audit

The access audit is the book's diagnostic for the Login Problem: "the habit of treating access to software as if it were the assignment of work" (Chapter 1). "A login is a permission. A job is a commitment." The audit asks six questions of each significant AI initiative. It is "not a demand for heavy bureaucracy. It is a minimum test for serious claims." When a specific role is proposed, Chapter 2's commissioning test and operating test go one level deeper.

## When to use
- The user wants to know whether an AI rollout, pilot or program is producing real work or only activity ("we bought seats for everyone; is it working?").
- The user is reporting adoption figures (seats, active users, prompts, time saved, number of agents) and wants to know what they prove.
- A specific AI role is about to go live and the user wants a commissioning check first.
- Do not use this to decide whether a system counts as an E-mployee role. Use `e-mployee-inclusion-test` for that. To design a new use from the outcome up, use `outcome-first-design`. To test whether the work pays, use `value-ledger`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. What was rolled out, to whom, and what it is claimed to achieve.
2. The metrics currently reported to leadership.
3. Who owns it, who reviews its output, and what systems and data it is connected to.

If the user cannot answer, run the audit anyway and mark the gaps `Missing`. Do not stall.

## The access audit (six questions, exact, in this order)
| # | Audit question | Book's decision rule for a weak answer |
|---|---|---|
| 1 | What recurring outcome is this use intended to improve? | "People are using it" means the program is measuring activity. |
| 2 | What work is the system allowed to perform, and what work is excluded? | No rule given. Judge with the tests below. |
| 3 | What is the definition of done, and what evidence supports it? | No rule given. Judge with the tests below. |
| 4 | Who reviews the result, with what competence, time, and authority? | "Someone checks it" means the program has not yet specified oversight. |
| 5 | What can the system observe, draft, recommend, execute, approve, spend, or communicate? | "Whatever the integration permits" means access has been allowed to define authority. |
| 6 | What baseline and measures will determine whether the role should scale, change, pause, or stop? | No rule given. Judge with the tests below. |

How to judge the answers:
- **Outcome**: "a sentence, not a software diagram." "We are using an assistant in finance" is a location. "We are producing a weekly exception brief for the controller, using approved ledger data, with a human review before release" is a result.
- **Owner**: must be "close enough to the consequence". "If the named owner cannot change the role, pause the system, or call for help, the title is decorative."
- **Standard**: must be "specific enough to reject". "High quality" is a preference, not a control.
- **Review**: must be "visible before the first failure" and proportionate to stakes and reversibility.
- **Stop question**: "If the system's output is wrong, who will know before it reaches the customer, and who has the authority to stop it?" The answer cannot be "the user."
- **Exposure**: "A named human owner who lacks authority is not accountable in the meaningful sense. The person is exposed."
- **Proportion**: low-risk exploration can stay light. "A company should not demand a full operating model before an employee tests a low-risk idea."

## Dashboard metrics
| Metric | What it can tell you | What it cannot tell you |
|---|---|---|
| Seats or licenses | How widely access has been distributed | Whether the access is connected to a business result |
| Active users | Whether people opened or used the tool | Whether the output was accurate, useful, or safe |
| Prompt or task volume | How much activity occurred | Whether the work reduced total cost or improved quality |
| Feature adoption | Which functions are being tried | Whether the workflow should have been redesigned first |
| Minutes reported as saved | What users believe they saved | Whether the time became cash, quality, learning, or more work |
| Number of agents | How many configurations exist | Whether the roles are coherent, governed, or worth keeping |
| Completion rate | Whether a system marked work complete | Whether a human should accept the result |

None of these answers the executive question: "What changed in the operation, and who is accountable for that change?" Keep **using**, **experimenting** and **scaling** apart. "Measure access. Measure activity. Then refuse to call either one value until the operating result is visible."

## From adoption to capability (six stages)
1. People receive access.
2. They experiment.
3. A workflow begins to change.
4. A role is assigned an outcome and bounded authority.
5. The organization measures performance, review, risk, and value.
6. Leadership decides whether the capability deserves a wider place in the operating model.

The stages "should not be skipped in language." Scale is not proof of maturity.

## Deeper check when a specific role is proposed (Chapter 2)
| Commissioning question | If the answer is unclear |
|---|---|
| What outcome is the role responsible for supporting? | The organization is measuring activity, not work. |
| Which tasks are inside the role? | The role has no usable boundary. |
| Which inputs are approved, and which are excluded? | Access may exceed purpose or permission. |
| What is the definition of done? | Fluency can be mistaken for quality. |
| What authority is granted? | The integration may silently define authority. |
| Who reviews the output and when? | Human presence may become ceremonial. |
| What evidence determines performance? | Promotion of autonomy becomes opinion. |
| What happens when the system is uncertain or wrong? | Exceptions become invisible debt. |
| When must the role stop or be retired? | The organization has no exit. |

The operating test then asks whether five elements are present: the work recurs; it has an objective that states the result and its user; it operates within a boundary; it is reviewable ("Reviewability is not the same as the existence of a review button"); and the organization measures the arrangement (baseline, output, quality, exceptions, review effort, risk, and effect on people). The test "does not grant an agent rights or accountability."

## Steps
1. Say what the initiative is today: exploration, a workflow change, or a standing role. "If the company is experimenting, say so. If it is changing a workflow, name the workflow. If it is assigning a standing role, publish the objective, authority, reviewer, standard, and stop condition."
2. Sort each reported metric with the dashboard table. State what it proves and what it does not.
3. Run the six audit questions. Record each answer, label its evidence, and apply the decision rules and judging tests.
4. Place the initiative on the six stages. Flag any claim that skips a stage, such as "scaled" for a program still at stage 2.
5. If a specific role is proposed or claimed, run the commissioning test and the operating test.
6. Recommend **scale**, **change**, **pause** or **stop**, with reasons. The book sets no score for this choice. Check it against the book's practical discipline: "Before adding a seat, choose one recurring result. Before connecting a system, identify the data and the boundary. Before announcing productivity, establish the baseline. Before increasing authority, observe performance. Before assigning accountability, provide control." Do not recommend scale while a "before" step is unmet.

## Output format
1. **Initiative statement**: one sentence on what it is today (exploration, workflow change or standing role) and the stage it has actually reached.
2. **Metrics check**: a table (Metric reported | What it can tell you | What it cannot tell you) for the metrics the user reports.
3. **Access audit**: a table (# | Question | Answer | Evidence label | Finding), with any decision rule that was triggered.
4. **Commissioning check**, only if a specific role is proposed: the nine questions marked clear or unclear, with the consequence of each unclear answer, plus the five operating-test elements.
5. **Decision**: scale, change, pause or stop, the reasons, the unmet "before" steps, and the named next step and owner (or `Missing`).
6. Status line: *"This audit is not a demand for heavy bureaucracy. It is a minimum test for serious claims."*
7. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapters 1 and 2.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: ai-incident-response
description: Map who authorized, supervised, inspected, released, can explain and will remediate an AI result, and run the nine-step incident sequence from The E-mployee Operating Model. Use when an AI agent got something wrong, for a post-incident review, or to map accountability before launch.
---

# Accountability Chain and Incident Response

Chapter 11 opens with a warning. The sentence "the AI made a mistake" can be accurate and still be useless, because it names nobody who can correct the result. Naming one powerless manager is no better. The book calls that "blame transfer". This workflow maps the human and institutional control points behind an AI-enabled result and runs a response in proportion to the harm. The practical question is: **"Who could authorize, supervise, inspect, release, explain, and remediate this result—and who can do so now?"**

## When to use
- An AI agent produced a wrong result, sent something it should not have or changed a record, and the user asks who is responsible and what to do now.
- A post-incident review, or a request to assign an incident owner.
- Before launch, when the user wants to map who holds each accountability link for a role.
- Do not use this to set a risk tier or minimum controls. Use `risk-classification` for that. To decide which action powers a role should hold, use `authority-matrix`.

## Inputs to gather
If the incident is live, give the first-hour actions below before asking anything.
Otherwise ask only for what is missing, at most three questions at a time:
1. What happened, when, to whom and in which workflow? Is the role still running?
2. Which role was involved, who reviewed the output and who released it? Is there a Role Charter or Authority Matrix?
3. What evidence survives (inputs, versions, logs, approvals, overrides, communications)? Was a vendor involved?

If the user cannot answer, proceed anyway and mark the gaps `Missing`. Do not stall.

## First hour and first week
Incident response has "two clocks".
- **First hour:** identify the active trigger, stop or contain the role, protect the fallback, preserve the current state and set up a communication channel. The safe action may be a pause, a queue freeze, a permission revocation, a switch to a human path, or a hold on only the affected workflow. Do not ask the affected team to keep operating as normal while an investigation is "being planned."
- **First week:** move from stabilization to scope and remedy. Separate what is known, suspected and missing. Establish who was affected, which decisions were made, which records can be corrected and what specialist advice is required. Distinguish confirmed impact from possible exposure, and give the reason for each. A preliminary record can be updated, but it must not silently become the final story. "Missing evidence is itself a control finding." Protect the people who raise concerns.

## The incident sequence (nine steps, in order)
Assign one incident owner to coordinate. That person or function needs authority, resources and a deadline. Coordinating does not make them the legally liable party.
1. **Detect and stabilize.** Stop or contain the role, preserve the human fallback, block further propagation and identify pending work.
2. **Assign an incident owner.**
3. **Preserve evidence.** Secure inputs, instructions, model and tool versions, access records, outputs, review decisions, overrides, timestamps and communications. Do not rewrite the original. Record corrections as new evidence.
4. **Assess affected scope.** Identify the people, customers, records, jurisdictions, decisions and possible consequences.
5. **Correct the immediate result.** Repair records, rerun or reverse work, route cases to humans and document the correction.
6. **Review notification.** Obtain legal, privacy, customer, labor, safety, compliance and communications advice, and apply the relevant rules and facts.
7. **Review root cause.** Separate role design, data, model, tool permission, reviewer, workflow, vendor, policy and institutional causes.
8. **Redesign controls.** Narrow authority, change review, repair data, retrain, revise the Charter, add escalation or retire the role.
9. **Record learning and decide** whether to go, revise, pause, demote, retrain or retire.

The order can change with immediate danger or legal direction. The principle does not change: "stabilize first, preserve evidence, correct people's reality, then learn and redesign."

## The Accountability Chain (exact)
**Authorize → supervise → inspect → release → explain → remediate.**

| Link | Meaning | What to establish |
|---|---|---|
| Authorize | The decision to create or continue the role, set its objective, grant its permissions and place it in a workflow. | Can the authorizer show the Role Charter, intended outcome, Authority Matrix, reviewer, evidence gate and stop condition? Record separately who authorized the role, who approved the data use and who approved the system change. |
| Supervise | The continuing work of operating the role: monitoring, staffing review, tracking exceptions, maintaining data and instructions, responding to change and preventing silent scope expansion. | Did the supervisor have resources and authority? Could anyone receive the warnings? |
| Inspect | Examining whether the output meets the standard and whether the evidence is sufficient to release it. | Was the output "accurate, complete, appropriate, traceable, authorized, and fit for the decision"? Could the inspector reject it? |
| Release | The moment the output becomes an organizational action, communication, decision, record or commitment. | Who released it, and is that point visible in the Authority Matrix? If the E-mployee acted outside its authority, record both the action and the permissions that allowed it. |
| Explain | An operational reconstruction, not an account of model internals. | Input, instruction, version, output, review, release, observed effect and known gap. "'The model hallucinated' may be a hypothesis." State where the record is missing. |
| Remediate | Restoring the affected work and changing the conditions that produced or permitted the failure. | An owner, time frame, evidence and decision gate. "An apology without correction is not remediation." |

## Ten responsibility dimensions
| Responsibility dimension | Question | Failure when omitted |
|---|---|---|
| Ownership | Who owns the outcome and can allocate resources to correct it? | A named sponsor cannot change the system. |
| Operation | Who configured, ran, maintained, or changed the role? | The operating path cannot be reconstructed. |
| Review | Who inspected the output, with what competence, time, and authority? | Human presence becomes ceremonial. |
| Approval/release | Who decided that the output could affect a person, customer, record, or institution? | Release is attributed to "the system." |
| Vendor role | What did the vendor provide, represent, change, or control? | Local diligence disappears behind a contract. |
| Specialist accountability | Which legal, privacy, security, safety, compliance, or domain function had a defined role? | Specialist review is assumed rather than assigned. |
| Institutional responsibility | Which company or public body designed policy, incentives, staffing, and controls? | Individual blame hides system design. |
| Affected party | Who experienced error, delay, disclosure, loss, or reduced opportunity? | Remedy is designed without the person affected. |
| Evidence | What inputs, versions, logs, approvals, overrides, and communications survive? | Root cause becomes speculation. |
| Remedy | Who corrects, notifies, restores, and prevents recurrence? | The incident ends with an apology instead of redesign. |

Keep three questions apart. **Managerial accountability** asks who must act. **Institutional responsibility** asks what the organization designed, enabled, rewarded or failed to control. **Legal liability** asks what applicable law, contract and facts assign. "They are not interchangeable."

## Reviewer, vendor and language checks
- **Human crumple zone.** Ask these questions before blaming a reviewer or assigning one. Can the reviewer see the inputs, evidence, uncertainty and version? Do they have time in proportion to volume and consequence? Can they reject, pause, redirect or escalate? Are they trained for the domain and the type of failure? Is good-faith escalation protected? Is there a separate owner with resources to correct the system and the workflow? If not, "reduce authority, narrow the role, redesign the process, or stop."
- **Vendor.** Record the vendor's identity, the product or service version, the representations relied on, contractual commitments, change notices, incident support, data processing, access and the evidence supplied. Keep that separate from the company's own decisions to deploy, configure, grant access, staff review and release. "'Vendor error' may be relevant. It is not a complete incident analysis."
- **Say** "managerial accountability" for the operating response, "institutional responsibility" for policy, staffing, incentives and control design, and "legal liability requires jurisdiction-specific analysis" for legal questions. **Do not say** that the named manager bears all legal liability, that the vendor is always responsible, that the AI is responsible in the human sense, or that compliance follows from keeping a human in the loop.

## Responsibility and incident map
| Map block | Required entry |
|---|---|
| Incident and affected outcome | What happened, when, to whom, and in what workflow? |
| Authorize | Who approved the role, objective, data, authority, and deployment? |
| Supervise | Who monitored operation, change, review capacity, and exceptions? |
| Inspect | Who reviewed the output, using what evidence and standard? |
| Release | Who approved or released the consequential result? |
| Explain | What can be reconstructed; what is missing or uncertain? |
| Remediate | Who stabilizes, corrects, notifies, redesigns, and decides? |
| Vendor role | What was supplied, represented, changed, contracted, or supported? |
| Specialist review | Which legal, privacy, security, safety, compliance, labor, or domain review applies? |
| Affected parties | Who needs correction, communication, remedy, consultation, or voice? |
| Root causes | Which role, data, model, tool, reviewer, workflow, vendor, policy, or institutional conditions contributed? |
| Decision | Go, revise, pause, demote, retrain, retire; why and with what evidence? |

## Steps
1. If the incident is live, give the first-hour actions and ask who the incident owner is. Keep it to a few lines. Everything else can wait.
2. Fill the map from what the user gave. Write `Missing:` plus the question that would settle each gap. Before launch, fill the map forward by naming who *would* hold each block.
3. Walk the chain one link at a time. Name the person or function, say what they could actually do, and record the gap.
4. Run the crumple-zone check on every reviewer and on anyone being blamed.
5. Sort root causes into the nine categories and mark each as confirmed or possible. Apply the vendor rule.
6. List the specialist reviews the facts trigger. Never state who is legally liable, and never decide a notification duty.
7. Recommend one decision (go, revise, pause, demote, retrain or retire), with its owner, evidence and date.

## Output format
1. **Stabilize now**: live incidents only, and always first. The first-hour actions in five lines or fewer, plus the incident owner or `Missing`.
2. **Responsibility and incident map** as a two-column table (Map block | Entry), with all 12 blocks in order.
3. **Chain check**: one line per link, giving the holder, whether they could act, had a concern, or could not act, and the reason.
4. **Root causes** by category, each marked confirmed or possible.
5. **Specialist reviews triggered**: which reviews apply, not what they will conclude.
6. **Decision**, with its owner, evidence and next review date.
7. Status line: *Author-created managerial synthesis. Not legal advice, a universal liability rule, or a formula that decides how a court, regulator, contract, or employment regime will assign responsibility.*
8. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 11.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: authority-matrix
description: Draft or review an Authority Matrix that sets which of seven action powers an AI role holds, with thresholds, review, escalation, expiry and revocation, from The E-mployee Operating Model. Use when someone asks what an AI agent should be allowed to do, or whether it may send, spend, approve or act on its own.
---

# E-mployee Authority Matrix

The Authority Matrix makes an E-mployee's right to act "explicit, narrow, logged, time-bounded, and revocable" (Chapter 10). It starts from a layer separation: "Capability is not permission. Permission is not authority. Authority is not accountability. A reviewer's presence is not intervention capacity. A credential is not a decision right." The governing question: "What may this E-mployee do, with which data and tools, under whose review, for how long, and with what revocation path?" Trust is defined as "calibrated permission plus intervention capacity," and it "should narrow as consequence and irreversibility rise." Default posture: if an answer is unclear, keep authority lower.

## When to use
- The user asks what an AI agent should be allowed to do, or who approves what.
- A proposal lets an agent send messages, spend, approve, or write to records or systems.
- An existing grant is up for renewal, or something changed (model, source, audience, integration).
- Do not use this to judge whether performance justifies a different control arrangement. Use `autonomy-review` for that. For who answers when an action goes wrong, use `ai-incident-response`. For the role's risk tier and minimum controls, use `risk-classification`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. The role's outcome and recipient (or its Role Charter).
2. The data, systems and tools it would touch, and what the connector or platform technically exposes.
3. The reviewer and approvers, the performance evidence so far, and who can stop the role.

If the user cannot answer, draft anyway and mark the gaps `Missing`. Do not stall.

## Four questions, not one
| Question | Meaning | Failure when confused |
|---|---|---|
| Capability | Can the system perform the task under observed conditions? | A demo becomes a permission. |
| Reliability | Does it perform consistently enough for the proposed control arrangement? | One success becomes general confidence. |
| Permission | May the role use this data, system, or tool for this purpose? | Technical access is mistaken for legitimate use. |
| Authority | Has the organization granted the right to take this action? | A credential is mistaken for a decision right. |

Authority follows the outcome, not the platform's menu of functions. A useful refusal: "The system can do that, but the role does not need to."

## The seven action powers (exact, in this order)
| Action power | Meaning | Default control |
|---|---|---|
| Observe | Read approved data or status. | Least privilege, provenance, and logging. |
| Draft | Prepare content or a proposed action. | Human review before external or consequential use. |
| Recommend | Rank or propose a decision. | Decision owner reviews evidence and uncertainty. |
| Execute | Take a bounded reversible action. | Narrow scope, testing, logging, and rollback. |
| Approve | Commit an organizational decision. | Reserved for an authorized human or institution unless applicable law or policy says otherwise. |
| Spend | Commit money or resources. | Explicit limits, dual control, and transaction monitoring. |
| Communicate | Send external or internal messages as the organization. | Named approver, audience limits, and record retention. |

"These powers are not a ladder that every role should climb. They are distinct rights." Each Matrix entry records: task class, action power, review level, expiry date, escalation path, affected rights or data, stop authority, and the human or institutional authority that approved it. "'The system has access' is not an entry."

## Thresholds (seven dimensions)
"A right to act without a threshold is a blank cheque." "'Low risk' is not a threshold."

| Threshold dimension | Question |
|---|---|
| Object | What record, message, transaction, decision, or commitment is affected? |
| Action | May the role observe, draft, recommend, execute, approve, spend, or communicate? |
| Limit | What amount, volume, audience, geography, duration, or data class is allowed? |
| Review | Is review before action, exception review, sample audit, or human decision? |
| Exception | What condition requires escalation or blocks action? |
| Expiry | When must the permission end or be renewed? |
| Reversal | How is the action paused, undone, or returned to a human path? |

**Data authority is not tool authority.** Data scope: fields, sources, purpose, freshness, sensitivity, retention, owner. Tool scope: functions, environments, APIs, write access, external effects, credentials. "If the answer is 'the connector already exposes it,' the design has not begun."

## Segregation of duties
| Action sequence | Safer separation |
|---|---|
| Observe → classify | E-mployee observes approved fields; reviewer checks the classification and evidence. |
| Draft → release | E-mployee drafts; named human approves before external or consequential use. |
| Recommend → approve | E-mployee recommends; authorized decision owner decides. |
| Prepare → spend | E-mployee prepares a transaction; authorized humans approve and release under dual control. |
| Request → grant | Operating owner requests; separate security or data owner grants and can revoke. |
| Execute → reconcile | E-mployee performs bounded action; separate control or owner checks the resulting state. |

## Escalation, expiry and revocation
- **Escalation.** Use named triggers: missing data, conflicting sources, policy ambiguity, unusual value, a new segment or jurisdiction, an out-of-scope attempt, a privacy or security signal, a material complaint, a failed control, a model or vendor change. Name the recipient and expected response. Log the trigger, time, last permitted action, recipient, decision, and whether the role resumed, narrowed, paused or stopped.
- **Safe default.** When no reviewer responds: hold, revert, or route to a human process. Never "silent execution merely because a service-level clock has expired."
- **Expiry.** Every grant has an expiry or review date: time-, event-, version- or condition-based.
- **Revocation.** Name the owner, the mechanism and the time expectation. Can the trigger be disabled without waiting for the vendor? Are credentials revoked, queued actions identified, pending work returned to a human path? "A stop button that only the vendor can operate is not sufficient." Any material change returns the role to a constrained permission until reviewed.

## Steps
1. State the outcome. For each of the seven powers, ask whether the outcome requires it.
2. Answer the four questions separately for every power requested.
3. Write a threshold for each granted power across all seven dimensions. Separate the data scope from the tool scope.
4. Check segregation of duties. The more consequential the action, the less acceptable it is for one role to generate the evidence, decide, release and certify itself.
5. Set escalation triggers, the safe default, expiry and the revocation path.
6. Plan the intervention test: run a controlled action, observe the alert, identify the reviewer, measure the response time, and verify the reviewer can stop or reverse it. Say so if it depends on a vendor or on a manual fallback with no staff. "The right to act is inseparable from the right to stop."
7. Plan the revocation test, before activation: trigger the stop condition in a controlled environment and confirm that queued actions are visible, pending messages held, credentials disabled, and a human can resume the work. A failed test "is evidence that the proposed authority is larger than the control system can safely carry."
8. Run the authority review conversation:
   1. What exact outcome requires this power? If the role can meet its objective without it, do not grant it.
   2. What is the narrowest object and data scope? Reduce fields, records, systems, audiences, geography and duration.
   3. What evidence supports the permission? Use performance evidence, not a demo or confidence score alone.
   4. What review occurs and who can reject? Name a competent reviewer with time and authority.
   5. What happens at the threshold or exception? Define escalation and the safe default.
   6. How is the action logged, expired, and revoked? Make the control executable, not aspirational.
   7. How does the human process resume? Test rollback before the action is needed.

   If the answer is unclear, the authority should remain at a lower level: the role may observe, draft or recommend while the organization improves its data, review, process or evidence.

## Output format
1. **Authority Matrix** as a table: Task class | Action power | Review level | Expiry date | Escalation path | Affected rights or data | Stop authority | Approved by. List all seven powers; write "Not granted" where a power is withheld.
2. **Thresholds**: one seven-row table (Object to Reversal) for each granted power.
3. **Data scope and tool scope**, listed separately.
4. **Segregation check**: each consequential sequence and who holds the second step.
5. **Escalation, safe default, expiry and revocation**, with the intervention and revocation tests marked planned, passed or failed.
6. **Authority review**: the seven questions, each answered or marked `Missing`.
7. **Verdict per power**: grant at the stated threshold, keep lower (observe, draft or recommend) until named evidence exists, or do not grant. Close with a one-line answer to "what right to act has actually been granted?"
8. Status line: *Author-created authorization instrument. Managerial guidance, not legal advice. Not a universal authorization standard, legal opinion, regulatory classification, or guarantee.*
9. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 10.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: autonomy-review
description: Run a periodic E-mployee performance review with the ten-dimension scorecard and the Autonomy Ladder, ending in a promote, hold, demote, retrain/redesign or retire decision, from The E-mployee Operating Model. Use when someone asks whether an AI agent should get more autonomy, be pulled back, or have its performance reviewed.
---

# E-mployee Autonomy Review

This workflow reviews an E-mployee's performance and decides its control arrangement (Chapter 9). The central rule: "Autonomy is earned, conditional, and reversible. It is not a property declared at purchase." Performance is not value. The Value Ledger asks whether the work pays (go, revise, pause, retire). This review asks whether the role performs its assigned work within its current controls (promote, hold, demote, retrain, retire). "Usage or confidence is not reliable performance." "The next level is never owed."

## When to use
- A scheduled (for example quarterly) performance review of a running role.
- A proposal to reduce human review or "let it run on its own".
- A change (new model, vendor, source, volume, recipient) or a warning sign such as rising correction time.
- Do not use this to decide whether the role pays. Use `value-ledger` for that. Which actions the role may take (send, spend, approve) is a separate decision for `authority-matrix`: "A Level 3 performance decision does not itself grant the right to act." After an actual incident, use `ai-incident-response`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. The Role Charter (version, owner, objective, definition of done), the current Ladder level and the reviewer.
2. The period and the evidence: samples, counts, logs, review hours, exceptions, incidents and changes.
3. The move being considered, and any thresholds already set.

If the user cannot answer, draft anyway and mark the gaps `Missing`. Do not stall. Never supply a threshold the user has not set. Write `Missing: threshold` and name who should set it.

## The E-mployee scorecard (ten dimensions)
Derive it from the Charter's objective and definition of done. Each measure states its period, sample, numerator, denominator, data source, owner, reviewer, threshold, and consequence of a miss.

| Dimension | Question | What to measure |
|---|---|---|
| Outcome attainment | Did the role produce the specified result for the intended recipient? | Completed outcomes, acceptance decisions, missed objectives, and recipient use. |
| Quality | Did the output meet the definition of done and domain standard? | Accuracy, completeness, appropriateness, provenance, correction, and rework. |
| Reliability | Did the role behave consistently across relevant cases and conditions? | Performance across time, volume, data variation, model/version, and normal exceptions. |
| Exception rate | How often did the role encounter or create exceptions, and did it surface them? | Exception frequency, severity, detectability, routing, and missed exceptions. |
| Human review burden | Can a competent reviewer inspect and correct the work at actual volume? | Review time, correction time, escalation time, fatigue, sampling quality, and queue age. |
| Cycle time | Did the workflow complete within the required period without shifting delay? | Time to draft, review, release, resolve, and recover. |
| Cost | Does the operating cost remain inside the approved economic case? | Supervision, correction, maintenance, integration, support, and exit exposure. |
| Traceability | Can the organization reconstruct what happened? | Inputs, sources, versions, instructions, actions, approvals, corrections, and overrides. |
| User/customer effect | Did the recipient experience the intended service or decision effect? | Acceptance, complaints, confusion, downstream rework, accessibility, and distribution. |
| Risk indicators | Did exposure remain within the role's approved boundary? | Privacy, security, legal, safety, rights, reputation, trust, and scope-change signals. |

"No dimension is sufficient alone." Keep **observed performance** ("Ninety-six percent of sampled claims were traceable," with the sample and rule visible) separate from **interpretation** ("The role is trustworthy").

**Measure the right denominator.** Include escalated, corrected-before-release, abandoned, difficult and rejected cases. Do not define quality as the absence of a complaint, or hide specialist time spent on exceptions. Record the sample, the missing cases and the confidence. Test at the length and complexity the role will actually face.

## Leading indicators and responses
| Leading indicator | Why it matters | Possible response |
|---|---|---|
| Review queue age rising | Review capacity may be failing before quality is visible. | Hold or reduce volume; add capacity; redesign. |
| Correction time rising | The role may be producing more hidden work. | Retrain, narrow task, or demote. |
| Missed exception trigger | The role may be silent precisely where it should be cautious. | Immediate rollback or tighter review. |
| Source/data freshness failure | Reliability may be illusory because inputs changed. | Pause; verify data owner and freshness rule. |
| Incomplete traceability | The organization may be unable to inspect or explain output. | Hold or demote until logs are restored. |
| Scope drift | The role may be doing a different job from the Charter. | Reauthorize, narrow, or stop. |

A role should not stay at a higher level because no incident has yet occurred. "Absence of an incident is not clearance."

## The Autonomy Ladder (exact)
It "describes what the human system does around the role," not intelligence or trust.

| Level | Human role | Entry evidence | Exit or rollback trigger |
|---:|---|---|---|
| 0 | Monitor after execution | Low stakes, reversible state, detectable exceptions. | Undetected errors, drift, or consequence expansion. |
| 1 | Review exceptions | Stable outputs and tested exception triggers. | Missed exception, review overload, or new failure mode. |
| 2 | Sample and audit | Reliable post-hoc detection and sufficient sample design. | Quality drift, sampling blind spot, or rising rework. |
| 3 | Review before action | Action affects money, customers, reputation, rights, or irreversible state. | Reviewer lacks time, competence, or authority; rollback required. |
| 4 | Human decides; AI researches | High variance, high stakes, thin evidence, or unresolved legal/rights issues. | Evidence improves only after a new approval cycle. |

- The levels are "not a one-way staircase." Every level needs a named reviewer, adequate time, competence, escalation, logs, and the power to reject or stop.
- The numbers are labels, not a score. In the book's example, moving from Level 1 to Level 2 is a promotion and moving from Level 1 to Level 4 is a demotion. Describe every move by the human control it adds or removes.
- Level 0 is not permission to ignore the role. Level 2 sampling "is not a discount version of review." Level 4 "is not a punishment."

## The five gates
| Gate | What must be true | What must be recorded |
|---|---|---|
| Promote | Next-level evidence, sustainable review, acceptable risk, tested rollback. | New level, scope, conditions, expiry, reviewer, stop trigger. |
| Hold | Current-level performance acceptable; evidence incomplete or mixed. | Missing evidence, unchanged boundary, next sample/date. |
| Demote | Material failure, drift, overload, or consequence expansion. | Trigger, immediate reduction, owner, remediation, re-entry condition. |
| Retrain / redesign | Role remains plausible but needs controlled change. | Change proposal, test, version, approval, post-change evidence. |
| Retire | Outcome or control case no longer justifies continuation. | Exit plan, fallback, logs, notifications, learning record. |

"Promotion and demotion should be symmetric." Demote before harm expands; a critical failure may need immediate rollback even when the average looks good. Retraining is "not simply asking the same system to try harder." It is a versioned, tested, approved change. Gates can combine, as in the book's "hold at Level 1 and retrain/redesign."

## Performance/autonomy worksheet
It connects the written job to a control decision. It does not replace the Role Charter, Value Ledger or Authority Matrix.

| Worksheet block | Required entry |
|---|---|
| Role and period | Role Charter version, owner, current level, measurement period, and reviewer. |
| Outcome | Objective, recipient, definition of done, and outcome-attainment result. |
| Quality | Sample, standard, error, omission, rework, and correction result. |
| Reliability | Conditions tested, variation, versions, data changes, and unexplained failures. |
| Exceptions | Rate, severity, detection, routing, missed exceptions, and response. |
| Human review | Reviewer competence, hours, queue, correction, escalation, and stop power. |
| Cycle time | Draft, review, release, resolution, and recovery timing. |
| Cost | Supervision, maintenance, correction, integration, and exit signals. |
| Traceability | Inputs, sources, instructions, versions, actions, approvals, corrections, and overrides. |
| User/customer effect | Acceptance, complaints, downstream work, accessibility, and distribution. |
| Risk indicators | Privacy, security, legal, safety, rights, reputation, trust, and scope changes. |
| Decision gate | Promote, hold, demote, retrain/redesign, or retire. |
| Conditions | New level, unchanged or narrowed boundary, review date, evidence, and rollback. |

## Steps
1. Confirm the role, Charter version, owner, current level, period and reviewer.
2. Fill the scorecard. For each dimension give the observation with its sample, numerator and denominator, then the threshold, then the interpretation. Check the denominator.
3. Check the leading indicators and note the response each one calls for.
4. Check the change log. A new model, vendor, data source, policy, volume, language, interface, recipient or workflow reopens the question without waiting for an incident. "Regression is not a contradiction of autonomy. It is what reversibility looks like in operation."
5. Check review for automation bias. The reviewer needs a reason, method, time and authority, and some independent verification (check a source, reconstruct a calculation, compare a separate record, test a sample). "An explanation is not proof." Measure review as work: too fast to be credible, too slow to be sustainable or too weak to change the outcome means the level is wrong.
6. Check thresholds as operating choices: each tied to consequence, sample, reviewer and fallback, with an owner and an expiry, and ordinary variation kept apart from a material trigger.
7. Compare the evidence with the entry evidence of the proposed level and the exit triggers of the current one. Choose the gate, confirm what must be true, and fill what must be recorded.

## Output format
1. **Scorecard**: Dimension | Observation (sample, numerator/denominator) | Threshold | Interpretation | Evidence label.
2. **Leading indicators** triggered, and the response for each.
3. **Ladder position**: current level, proposed level, entry evidence met or not, exit triggers hit, in terms of human control.
4. **Performance/autonomy worksheet**: a two-column table (Worksheet block | Entry) with all 13 blocks in order.
5. **Gate decision** with every "what must be recorded" item filled, or marked `Missing`.
6. Status line: *Author-created operating instrument. Not a benchmark, certification, regulatory classification, legal category, or guarantee.*
7. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 9.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: e-mployee-inclusion-test
description: Classify a proposed AI system or agent with the E-mployee inclusion test from The E-mployee Operating Model and decide whether to include, defer or exclude it as an E-mployee role. Use when someone asks whether an agent, copilot or "digital worker" is a real role, or how to classify entries in an AI registry.
---

# E-mployee Inclusion Test

Chapter 3 turns the canonical definition into six necessary operating conditions and a CEO inclusion/exclusion test that ends in Include, Defer or Exclude. The canonical definition: an E-mployee is "an AI agent an individual directs like a member of a personal workforce by delegating objectives, supervising and reviewing output, and remaining personally accountable for what it produces." "The status belongs to the relationship, not to the model." A modest system can qualify. A sophisticated one can fail.

## When to use
- The user asks whether a system, agent, copilot or "digital worker" counts as an E-mployee role.
- The user is building an inventory or registry of "AI employees" and needs each entry classified.
- A vendor or team calls something "autonomous" and the user wants to test the claim before it shapes permissions.
- Do not use this to write the role's full specification. After an Include, use `role-charter`. To check whether an AI rollout produces real work at all, use `ai-access-audit`. To choose which candidate goes first, use `first-role-selection`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. What the system does, how often or on what trigger, and for whom.
2. What data it can reach and what actions it can take (read, draft, write, send, pay).
3. Who reviews its output, and who can correct, pause or stop it.

If the user cannot answer, classify anyway and mark the gaps `Missing`. Do not stall.

## Category boundary map
| Category | What it describes | What it does not establish |
|---|---|---|
| Software | A technical system or feature | A job, authority, or responsibility |
| Assistant | A system that supports a person's work | A standing objective or independent authority |
| AI agent | A system capable of a task or multistep workflow with some autonomy | Personhood, reliability, or permission to act |
| E-mployee | An AI agent placed in a standing human-directed role with objective, authority boundary, output, review, and retained human accountability | Legal employment, consciousness, moral agency, or independent liability |
| E-mployer | The human person who directs E-mployees | A guarantee that one person personally performs every control activity |
| Legal person | A category defined by applicable law | A status created by an operating metaphor |

Watch for the two category errors: **product-brand substitution** (accepting a vendor's "agent", "copilot" or "digital worker" label as an operating fact) and **anthropomorphic substitution** (treating fluent language as intention, judgment or status).

## Six necessary operating conditions (exact, in this order)
| # | Condition | What must be true | Sign it is absent |
|---|---|---|---|
| 1 | A standing role | Exists beyond a single prompt or demonstration; runs on a cadence or trigger; named by function, not vendor or model. "Recurrence with purpose." | One-off or occasional use; a name like "Autonomous Finance Employee" that "says too much". |
| 2 | A delegated objective | States what, for whom and under what conditions; bounded enough to evaluate; can be revised. "Delegation is not abandonment." | The purpose is "use AI". "A role that cannot be corrected is not being directed; it is being left to continue." |
| 3 | A defined authority boundary | Explicit and revocable; covers data and action (observe, retrieve, draft, recommend, execute, approve, spend, communicate); names exclusions. | The technical integration defines the managerial role. "Capability becomes permission by accident." |
| 4 | A defined output | Format, timing, evidence expectation and recipient; carries uncertainty, missing evidence and unresolved conflicts. Need not be final. | Polished output with no decision use. "Fluency is not a definition of done." |
| 5 | Supervision and review | Proportionate to consequence; the reviewer has knowledge, time, authority to reject or pause, and a route to escalate. | "Human in the loop" exists only in policy. "A reviewer who cannot disagree is not supervising." |
| 6 | Retained human accountability | A human or institution directs, supervises, reviews, corrects, explains and remediates; control points stay visible. Managerial accountability, not legal liability. | A named person without control. "Naming a person without providing those conditions is not accountability. It is exposure." |

## The CEO inclusion/exclusion test
| Test question | Include as a candidate E-mployee when… | Exclude or defer when… |
|---|---|---|
| Is there a standing role? | The work recurs or is triggered by a defined process. | The use is occasional, personal, or a one-off experiment. |
| Is there a delegated objective? | The role supports a named result for a named recipient. | The purpose is only "use AI" or "increase adoption." |
| Is authority explicit? | Observe/draft/recommend/execute limits are documented and revocable. | The technical integration silently determines what the system may do. |
| Is the output defined? | Format, evidence, recipient, timing, and acceptance condition are clear. | The system produces fluent activity with no decision use. |
| Is review real? | A competent reviewer has time, authority, and an escalation path. | "Someone checks it" is the only control. |
| Is accountability retained? | A human or institution can explain, correct, remediate, and stop the role. | The organization points to the system or a powerless reviewer. |
| Are legal and rights boundaries addressed? | The role is screened for applicable law, data, labor, safety, IP, and contractual issues. | The label is being used to avoid or pre-empt those questions. |

The three decisions:
- **Include**: a candidate E-mployee role that must receive the relevant role, authority, review and measurement controls.
- **Defer**: the idea may be useful but is not yet sufficiently specified or reviewable.
- **Exclude**: do not place it in the E-mployee category, because the use is ordinary assistance or the risks and controls do not justify the role.

**Necessary is not sufficient.** "Classification is the beginning of disciplined evaluation, not a promotion." Inclusion is not approval, and exclusion is not a rejection of AI. A role that passes can still fail on value, data, review cost or consequence. No fixed technical architecture is required. "Excluding a proposed role is a management decision, not a failure of imagination."

## What the E-mployee does not claim
Check that no one is using the label to claim **personhood**, **consciousness**, **employment status**, **moral agency**, a **transfer of human accountability**, or **universal autonomy**. The vocabulary must never be used to avoid consultation, wages, worker protections or data duties.

## Steps
1. Place the system on the boundary map. Name any product-brand or anthropomorphic substitution.
2. Test the six conditions in order. Mark each met, not met or `Missing`, and label the evidence.
3. Run the seven rows of the CEO test. On the legal and rights row, record only whether screening has happened and by whom. Do not give a legal conclusion.
4. Decide. If any row falls in the right-hand column, do not Include. Choose Defer when specification or staffed review could close the gap. Choose Exclude when the use is ordinary assistance or the risks and controls do not justify the role.
5. Write the minimum registry record: role name and version, objective, owner, approved inputs, exclusions, authority, output, reviewer, escalation route, status, and stop condition. Here it is a classification device only. The full Role Charter comes later.
6. Close with the boundary decision discipline: "Name the role. State the objective. Limit the authority. Define the output. Staff the review. Retain accountability. Then decide whether the E-mployee term clarifies the work or merely flatters the software."

## Output format
1. **Category**: where the system sits on the boundary map, and any category error.
2. **Six conditions**: a table (Condition | Status | Evidence and label).
3. **CEO test**: a table (Test question | Answer | Include or exclude/defer column).
4. **Decision**: Include, Defer or Exclude, with reasons. For Defer, list what must be specified or staffed. For Include, state what remains unproven.
5. **Registry record**: the eleven minimum items, with `Missing` where unknown.
6. **Label check**: one line confirming none of the six non-claims is being made, or naming the one that is.
7. Status line: *The book's proposed inclusion test. Not a legal test, an academic consensus, or a certification standard.*
8. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 3.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: e-mployer-capability-audit
description: Audit whether a team or organization can direct AI work, using the five capacities of the E-mployee Doctrine from The E-mployee Operating Model, and list the missing work. Use when someone asks if they are ready to manage AI agents, or before announcing an AI operating model or agent rollout.
---

# E-mployer Capability Audit

The E-mployer is "the human person who directs E-mployees" (Chapter 4). The E-mployee Doctrine names the five capacities that practice requires: **Delegation, Direction, Discernment, Accountability, and Orchestration**. The audit asks one question per capacity and exposes the missing work. "An organization can be technologically ready and managerially unready." "The five capacities are not a score that creates permission. They are a way to find the missing work before the system receives consequence."

## When to use
- The user is about to launch, scale or announce an agent rollout or AI operating model.
- The user asks "are we ready to manage AI agents?" or "do we have the capability to direct this?"
- The user proposes a list of leadership capacities for AI and wants it checked.
- Do not use this to classify a single system. Use `e-mployee-inclusion-test` for that. To design the outcome itself, use `outcome-first-design`. To place owners, reviewers and stop authority on a chart, use `human-ai-org-chart`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. Which role or program is in scope, and what outcome it serves.
2. Who sets the objective, who reviews the output, and who can pause or retire the role.
3. How the output connects to human decisions, other systems and the people it affects.

If the user cannot answer, audit anyway and mark the gaps `Missing`. Do not stall.

## The E-mployee Doctrine (exact, in this order)
These are five **capacities**. Never add, rename, merge or reorder them. "The sequence matters."

| Capacity | Exact approved meaning | Executive behavior | Primary failure mode |
|---|---|---|---|
| **Delegation** | See the shape of work and decompose an objective into tasks. | Assign the right task to the right actor according to variance, stakes, reversibility, and capability. | Automating high-judgment work while humans retain routine work. |
| **Direction** | Specify purpose, context, constraints, evidence, and the standard of done. | Write the objective before choosing the tool. | Fluent but unusable output from ambiguous direction. |
| **Discernment** | Judge whether output is accurate, appropriate, and fit for consequence. | Match review to risk and use domain expertise. | Automation bias, ceremonial approval, or review without competence. |
| **Accountability** | Own the result and bear consequence. | Name a human who can explain, correct, and remediate. | Accountability theatre or an unqualified rubber stamp. |
| **Orchestration** | Compose outputs into one coherent end. | Coordinate roles, dependencies, handoffs, and quality gates. | Agent sprawl, context loss, and coordination cost. |

## Capability audit questions
| Capacity | Audit question | Evidence that answers it |
|---|---|---|
| Delegation | Can the team show which tasks are stable, variable, reversible, sensitive, or judgment-heavy? | The objective written as a bundle of tasks, each marked agent may perform, human must perform, joint work, or "cannot be delegated under the current evidence". Hidden human work (gathering, verifying, correcting, exceptions, explaining, maintaining) is counted. |
| Direction | Can the role state purpose, context, constraints, evidence, and standard of done? | All five written down, including what the system must not do, infer, disclose or change. "A prompt is not the whole direction." |
| Discernment | Who reviews the output, with what competence, time, and authority? | Independent grounds for review: sampling, source comparison, exception tests or specialist input. A reviewer who can say "This output is not ready," and explain why. |
| Accountability | Who can explain, correct, remediate, pause, or retire the role? | The organization can say who authorized the role, who supervised it, who inspected the output, who released the consequence, who explains it, and who remediates the harm. That person has real power to act. |
| Orchestration | How do the output, human decision, system update, and customer communication connect? | One owner of the coherent end. Handoffs and quality gates mapped. "The smallest set of human and artificial contributions" that can do the job, which is sometimes no agent at all. |

## Practical-obligation mapping
Description, Discipline, Development and Duty of Care are **not additional capacities** and must not be added to the canonical formulation. If the user lists them as capacities, say so and map them:

| Practical obligation language | Where it belongs in the approved Doctrine | Executive question |
|---|---|---|
| Direction | Direction | Have we specified purpose, context, constraints, evidence, and the standard of done? |
| Delegation | Delegation | Have we decomposed the objective and assigned each task according to variance, stakes, reversibility, and capability? |
| Description | Direction, supported by Delegation | Can we describe the objective, task, boundary, output, and handoff without relying on the tool's brand? |
| Discipline | Discernment and Accountability | Do we inspect the work against evidence, refuse weak output, and own the consequence? |
| Development | Orchestration and Direction | Are we improving the role, the human capability, the workflow, and the handoffs rather than merely adding features? |
| Duty of Care | Accountability and Discernment | Have we considered affected people, rights, safety, privacy, workload, and the ability to intervene? |

"This mapping is a clarification, not a revised Doctrine."

## Steps
1. Fix the scope: one role or program and the outcome it serves. Audit the arrangement, not a person. "The Doctrine is not a personality test for CEOs," and the E-mployer "is not a hero". The capacities must exist somewhere in the organization and connect to decision rights.
2. Take the five capacities in Doctrine order. Ask the audit question, record the evidence and its label, and write the finding: evidence present, gap, or `Missing`.
3. For each gap, check whether the capacity's primary failure mode is already visible, and name it.
4. If the user's own framework adds capacities, apply the practical-obligation mapping.
5. Check resources. "An organization cannot demand E-mployer behavior without providing access to training, tools, time, evidence, and authority." Flag any place where a person holds accountability without control, because that transfers risk rather than creating direction.
6. List the missing work with an owner for each. In the book's illustrative audit it was: decompose the work, write the objective and exclusions, staff the reviewer, assign stop authority, and map the handoffs.
7. Give the verdict in the book's terms: either the program can be presented as an E-mployer-ready operating model, or it is technologically ready but managerially unready and must not be announced as E-mployer-ready until the missing work is done. Never turn the capacities into a score, percentage or pass mark.

## Output format
1. **Scope**: the role or program and the outcome it serves.
2. **Capability audit**: a table (Capacity | Audit question | Evidence and label | Finding | Failure mode visible), five rows in Doctrine order.
3. **Mapping note**, only if the user listed extra capacities: where each belongs.
4. **Missing work**: a numbered list, each item with an owner or `Missing`.
5. **Resource check**: whether the named people have training, tools, time, evidence and authority.
6. **Verdict**: E-mployer-ready, or managerially unready, and what must be true before announcing.
7. Status line: *The E-mployee Doctrine is Dr. Jonah Tebaa's proprietary conceptual framework and research agenda. It is not established academic science, a legal standard, a certification, or a vendor methodology, and it is not empirically validated. The five capacities are not a score that creates permission.*
8. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 4.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: first-role-selection
description: Compare candidate AI roles with the Opportunity Matrix, nine selection factors and the rejection test, then draft a board-ready first-role decision, from The E-mployee Operating Model. Use when someone asks which AI agent, role or use case to start with, or wants to compare, shortlist or reject candidates.
---

# First E-mployee Selection

This workflow chooses which E-mployee role to assign first (Chapter 8). The first role should be selected for "measurable value, task stability, data readiness, reviewability, reversibility, bounded authority, and time to credible learning—not novelty." The question is not "Where can AI do the most?" It is "Where can this organization learn whether directed artificial labor creates credible value without losing control?" The largest use case is not automatically the best first role. "A first role is not a commitment to a portfolio. It is a bounded permission to learn."

## When to use
- The user asks which AI role, agent or use case to start with, or which to do next.
- The user has a list of candidates and wants them compared, shortlisted or rejected.
- The user needs a selection recommendation for a board or executive team.
- Do not use this to measure a role that is already running. Use `value-ledger` for that. If candidates are still tool names rather than outcomes, run `outcome-first-design` first. To write the chosen role's job, use `role-charter`. For several roles already in operation, use `portfolio-review`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. The candidate roles, each stated as an outcome and a recipient.
2. For each, what is known about value (baseline, counterfactual), data, reviewer and reversibility.
3. The stakes and constraints: customers, regulation, budget, deadline, and who makes the final decision.

If the user cannot answer, draft anyway and mark the gaps `Missing`. Do not stall.

## Opportunity Matrix
Value potential is the vertical axis and task stability the horizontal axis.

|  | Low task stability | High task stability |
|---|---|---|
| **High value potential** | Design carefully; begin with research, drafting, or triage; keep authority narrow. | Candidate for a bounded first role if data and review controls are ready. |
| **Low value potential** | Do not delegate yet; redesign the workflow or retain human judgment. | Automate only if capacity, learning, service, or resilience value justifies the control cost. |

"The axes are deliberately incomplete." The placement is then modified by stakes, reversibility, data readiness, review burden, workforce effects, implementation cost, exit cost, and time to credible learning. Give each candidate a written rationale: what is known, what is assumed, who bears the downside, and what evidence would move it. "A score without a reason is a preference wearing a number."

## The nine selection factors (in this order)
| # | Factor | Question | Watch for |
|---|---|---|---|
| 1 | Business value | Is there a specific outcome with a recipient, baseline, counterfactual, acceptance condition and credible value range? | A smaller, well-evidenced base case can beat a spectacular, weakly attributed one. "The first role is a learning investment." |
| 2 | Task stability | Does the work recur, have bounded variance, and produce an inspectable output? | "Stable does not mean simple." Judge the real role, not the demo. Unstable work stays in research, drafting, comparison or triage. |
| 3 | Reversibility | Can the work be paused, reverted or returned to a human process without losing control? | Can the trigger be disabled, records restored, pending work identified, the human process resumed, the pause communicated? If unclear, reduce the placement. |
| 4 | Data readiness | Are inputs permitted, current, accessible, sufficiently complete, and understandable to reviewers? | "Technical access is not data readiness." Ask owner, purpose, freshness, gaps, languages and formats, and out-of-boundary inputs. |
| 5 | Review burden | Can a competent reviewer inspect the output with real time, authority and an escalation route? | "'Human in the loop' is not a score." Record volume, stage, competence, sampling or full review, correction time, escalation, cost of delay. |
| 6 | Regulatory and customer stakes | What happens when the role is wrong? | Weigh probability with reversibility, detectability, blast radius and affected people. No unexplained "low risk" label. It prompts specialist review; it does not classify legally. |
| 7 | Human skill effects | Who gains capability, loses discretion, reviews, gets development, or gets fragmented work? What happens to released capacity? | The first role is "selected partly for what it teaches the human workforce to do next." |
| 8 | Implementation and exit cost | What does it cost to make the Role Charter real, and to leave? | Moderate value with low exit cost may beat high value with irreversible integration. |
| 9 | Time to credible learning | How soon is output observable in the real workflow, how many cases show the key exceptions, when are baseline and counterfactual credible, what stops it early? | "Speed is not the same as learning." A polished demo is time to excitement, not to learning. |

## Optional 1-5 comparison
Use only if the user wants scores. The book's illustration uses a "descriptive 1–5 scale" that is "a conversation aid, not a probability or validated score," with columns Value, Stability, Reversibility, Data readiness, Reviewability, Stakes, Implementation/exit, Learning time, and Initial view. Every score needs its written reason. State each column's direction: in the book's illustration a higher Stakes score marks more exposure, unlike the other columns. Never total the scores or select on the highest number. The record should not say a candidate was chosen "because it scored highest."

## Rejection test
Reject the candidate for now when any of these is true:
1. The outcome cannot be named without a tool description.
2. The baseline is missing and no credible measurement path exists.
3. The data are available technically but not permitted or owned.
4. The output cannot be inspected by a competent reviewer at the expected volume.
5. The authority boundary cannot be expressed in "verbs, objects, thresholds, and stop conditions."
6. It is called reversible but would alter an irreversible record or customer relationship before review.
7. The economic case depends on capacity becoming cash without a redeployment or demand plan.

Record "not yet" (redesign, clean data, schedule review, narrow output, run research-only) separately from "no". Political attractiveness, a vendor demo or a large budget is not a reason. If the missing evidence is the central fact, the first decision may be to measure the process rather than automate it.

## Selection worksheet (11 blocks, exact)
| Selection block | Required entry |
|---|---|
| Candidate outcome | What result, for whom, by when? |
| Value evidence | Baseline, counterfactual, range, attribution, and confidence. |
| Stability | Recurrence, variance, exceptions, and inspectability. |
| Reversibility | Pause, revert, human fallback, and recovery path. |
| Data readiness | Permission, freshness, completeness, context, and owner. |
| Review burden | Reviewer, competence, time, sampling/full review, and rejection power. |
| Stakes | Customer, regulatory, financial, safety, rights, privacy, and reputation exposure. |
| Human effects | Capability gained, discretion shifted, review burden, and distribution. |
| Cost | Implementation, supervision, switching, maintenance, and exit. |
| Learning | Time to credible evidence and the stop/revise decision date. |
| Board decision | Go, revise, pause, or retire; conditions and confidence. |

## Steps
1. Restate each candidate as an outcome and recipient. Run the rejection test on every candidate first.
2. Place the survivors on the Opportunity Matrix with a written rationale, then apply the modifiers.
3. Compare evidence, not adjectives, in the same order for every candidate: the outcome and Value Ledger evidence; then stability and exceptions; then reversibility and the human fallback; only then the tool, vendor or demonstration. Label evidence as direct, self-reported, reasonable assumption or missing.
4. Assess the nine factors. When value is similar, prefer the candidate whose uncertainty can be reduced sooner and whose failure can be contained more cheaply.
5. For each deferred candidate, answer the dissent question: "what would have to be true for the deferred candidate to become first?"
6. Complete the selection worksheet for the recommended candidate, with its written uncertainty note: say so if value rests on a vendor claim, data readiness is assumed, or the reviewer is named but not scheduled.
7. Check what the first role will teach: whether objectives can be written, data owners identified, reviewers exercise discernment, authority be constrained, logs be usable, the human process resume, and the economics survive supervision. It should carry "one defined outcome, one controlled workflow, one accountable owner, and one credible learning question."
8. Draft the board-ready decision: the decision and its conditions; the powers allowed and forbidden; the basis; the conditions for approval; the decision confidence; the next gate (for example "evidence review, not scale"); what remains unknown; and what would change the decision.

## Output format
1. **Candidate table**: Candidate | Outcome | Matrix cell | Rejection test (pass, not yet, no) | Rationale.
2. **Factor comparison**: the nine factors for each surviving candidate, with evidence labels (and 1-5 scores with reasons, only if requested).
3. **Selection worksheet** for the recommended candidate, all 11 blocks, plus the written uncertainty note.
4. **Deferred candidates**: what would have to be true for each to become first.
5. **Board-ready decision** as a short paragraph.
6. Status line: *Author-created selection instrument. Not an empirical ranking, a vendor comparison, a success probability, or a substitute for executive judgment.*
7. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 8.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: get-started
description: Orient a new user to the E-mployee Operating Model workflows and route them to the right one. Use after installation, or when someone asks what this plugin does, where to start, or how to give AI a real job in their organization.
---

# Get started with the E-mployee Operating Model

*The E-mployee Operating Model* treats AI work as a job to design rather than a tool to switch on. Its tagline is "Give AI a job, not a login." Every workflow here helps a leader name the outcome, bound the work, staff the review, measure the value and keep the power to stop. This skill finds where the user is and sends them to the workflow that fits.

## When to use
- Right after the plugin is installed, or when the user asks "what can this do?" or "where do I start?".
- When a request is broad ("help us with AI in operations") and it is not yet clear which workflow applies.
- Do not use when the user's request already matches a workflow below. Go straight to that skill.

## Steps
1. In two or three sentences, explain the idea. A login is a permission and a job is a commitment. An E-mployee is an AI agent in a standing, human-directed role with an objective, an authority boundary, a defined output, real review, and a human who stays accountable.
2. Ask one question: **"Where are you right now?"** Offer the situations in the routing table as short options. Let the user answer in their own words.
3. Map the answer to one workflow and start it. If two workflows fit, start with the earlier one in the table and say which comes next.
4. If the user only wants an overview, show the routing table and stop.

## Routing table
| The user's situation | Workflow |
|---|---|
| "We rolled out AI tools. Is it creating real work or just activity?" | `ai-access-audit` |
| "Is this agent really an E-mployee, or just software or an assistant?" | `e-mployee-inclusion-test` |
| "Are we, as leaders, ready to direct AI work?" | `e-mployer-capability-audit` |
| "We want to use AI for something. How do we design it properly?" | `outcome-first-design` |
| "We have several candidate use cases. Which comes first?" | `first-role-selection` |
| "Write or review the job description for an AI agent." | `role-charter` |
| "What should the agent be allowed to do?" | `authority-matrix` |
| "Is it paying off? Build the business case." | `value-ledger` |
| "Should it get more autonomy, or less?" | `autonomy-review` |
| "How risky is this, and which controls do we need?" | `risk-classification` |
| "Something went wrong. Who is responsible and what now?" | `ai-incident-response` |
| "How do we redesign the team or org chart around AI?" | `human-ai-org-chart` |
| "We run many agents. How do we manage or scale them?" | `portfolio-review` |
| "Give us a 90-day plan for our first AI role." | `ninety-day-roadmap` |

## Typical sequence for a first role
`outcome-first-design` → `first-role-selection` → `role-charter` → `authority-matrix` → `risk-classification` → pilot → `autonomy-review` and `value-ledger` → decide. `ninety-day-roadmap` wraps the whole sequence in gated phases.

## Output format
1. A short orientation of two or three sentences.
2. The question "Where are you right now?" with the situations as options.
3. After the user answers, the name of the chosen workflow and its first step.
4. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa).*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: human-ai-org-chart
description: Draw a Human + AI Organization Chart and a Role Redesign Canvas showing who directs, reviews, can stop and can retire each AI role, and what changes for the people around it. Use when restructuring a team or org chart around AI agents, or when asking what happens to people's jobs.
---

# Human + AI Organization Chart

Chapter 13 makes a structural point: "If the organization chart remains unchanged, the work has not remained unchanged." The first E-mployee changes a job, and the second change is to the organization around that job. This workflow maps where ownership, review, data, voice, escalation and retirement authority sit, and what happens to the human work around each role. The E-mployee is a bounded operating role performed by technology under human direction. It is "not a legal person". Never draw it as a person, an employee, a manager or a box with reports.

## When to use
- "How do we restructure the team, or the org chart, around AI agents?"
- "What happens to people's jobs?" This means mapping the human roles before and after.
- Checking that review capacity, worker voice and stop authority are real before a role is added.
- Do not use this to write the E-mployee's own job specification. Use `role-charter` for that. To govern many roles across the organization, use `portfolio-review`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. Which E-mployee roles are involved, what bounded work does each do, and who owns the business outcome?
2. Who does this work today, who would review the output, and who owns the data and tools?
3. How are workers and affected people heard today, and who could pause or retire the role?

If the user cannot answer, draw the chart anyway and mark the gaps `Missing`. Do not stall.

## The right question
Do not ask "Where does the AI report?" That question "imports personhood and confuses execution with authority." Ask: **"Who directs this role, who reviews its work, who can intervene, who owns the data, who supports the tools, who hears affected people, and who can stop or retire it?"**

## The eight chart nodes
| Chart node | What it makes visible | What it must not imply |
|---|---|---|
| Human decision owner | The person accountable for the business outcome and final decision | That the person automatically carries every legal liability |
| E-mployee role or roles | The bounded objective, workflow, outputs, and exclusions | That software is a person, employee, manager, or independent actor |
| Reviewer or quality function | Competence, time, context, rejection power, and review route | That a named reviewer guarantees safety or correctness |
| Risk/legal/security | Specialist questions, controls, and escalation; privacy and domain review where applicable | That one specialist function replaces local legal or domain analysis |
| Data owner | Source permission, quality, retention, access, and provenance | That data approval authorizes every possible use |
| Worker voice | A route for workers and affected people to report burden, harm, bias, or design failure | That consultation is a formality or universal legal procedure |
| Escalation route | Where uncertainty, exceptions, incidents, and rights concerns go | That escalation can be left to an unowned mailbox |
| Retirement authority | Who can pause, narrow, roll back, prohibit, or retire the role | That continuation is the default after launch |

"A box without a decision is decoration. A line without a handoff is ambiguity. A reviewer without capacity is an aspiration. A retirement authority without a stop path is a title without power."

## Draw decisions, not software
Draw three things as separate elements: the person who can make the decision, the role that performs the bounded work, and the function that can challenge the result. Read the chart as a control and interface map, not a reporting hierarchy. "Shared services must not silently become business owners."

| Shared service may standardize | Business owner must still decide |
|---|---|
| Identity, access patterns, environment controls, logging, and retention mechanisms | Whether the role's objective is worth pursuing |
| Connector patterns, version records, evidence preservation, and change notification | Whether the output meets the business definition of done |
| Training, playbooks, evaluation methods, and incident intake | Whether a specific exception should be released |
| Common procurement, vendor review, and security baselines | Whether the role's human and customer effects are acceptable |
| Portfolio inventory and board reporting format | Whether to continue, narrow, pause, or retire the role |

## Span of control is a workload question
"There is no responsible universal ratio." Pair the chart with a review-capacity view recording role count, expected volume, exception rate, average review time, peak demand, queue age, required expertise, backup coverage, and the reviewer's power to reject or stop. Run the two executive tests:
- **Remove the most experienced reviewer for a week.** Is there a competent backup? Does the queue stay safe? Can the role be narrowed or paused?
- **Double the exception volume without changing staffing.** If quality falls or review becomes ceremonial, the span has been exceeded.

Look at how the load is distributed. When a small group absorbs the exceptions, corrections, emotional labor and after-hours escalation, that cost belongs on the chart.

## Role Redesign Canvas (10 fields, exact)
The Canvas is "not a second Role Charter". The Charter defines the E-mployee role. The Canvas maps the human role around it, before and after the E-mployee is introduced.

| Canvas field | Executive question |
|---|---|
| Before-state human work | What do people do today, including judgment, coordination, correction, and relationship work? |
| E-mployee contribution | Which bounded tasks move to the E-mployee, and which remain outside it? |
| Retained human judgment | Which decisions still require human interpretation, discretion, empathy, negotiation, or accountability? |
| New human work | What review, exception handling, source checking, escalation, training, or maintenance is created? |
| Removed or reduced work | Which tasks genuinely stop, and which merely move or become less visible? |
| Review load | Who checks the output, how often, with what evidence, and with what power to reject? |
| Skill formation | What knowledge, practice, training, and career path does the redesigned work require? |
| Job-quality effect | What happens to discretion, workload, pace, monitoring, learning, dignity, pay, and meaningfulness? |
| Worker and affected-party voice | Who can report harm, bias, unsafe pressure, confusing output, or a bad workflow? |
| Escalation and retirement | Who can change the design, pause the role, or return work to a human process? |

Name the **new human work**. Work that goes unnamed is "either staffed, degraded, or transferred to someone with less power."

## Skills, job quality and worker voice
- **Skill formation.** Will reviewers be trained to challenge outputs? Will people be rewarded for finding errors rather than approving volume? Will someone whose routine tasks shrink get a credible path to new work? Can people report that a workflow is unsafe or degrading without being treated as resistant to innovation?
- **Job quality is a design variable.** Does the redesign increase discretion or only monitoring? Does it build learning or deskill the role? Is the pace set by customer need or by machine capacity? Who absorbs errors? Can affected people get an explanation or remedy through a human route? Is released capacity improving the work, or hiding a reduction in staffing?
- **Worker voice is a control.** The channel "needs an owner, response time, evidence, and escalation. Otherwise it is a suggestion box attached to a machine."
- **Resist two stories:** that every E-mployee is "a hidden layoff program", and that every E-mployee "will elevate human work". Both are "forecasts pretending to be operating plans." "Non-adoption is a valid organizational outcome."

## Regional capability (where relevant)
When language, local practice or uneven infrastructure matter, for example in a MENA setting, add these as questions on the chart and never as claims about any country. Who can review Arabic, English or domain-specific language? Who understands local customer practice? Who can challenge an output that is technically fluent but socially wrong? Who can maintain the system when the vendor changes? Who has authority to stop a workflow when the formal owner is unavailable? Separate observed labor-market signals from assumptions about organizational readiness. "The region should not be treated as a single market, and local constraints should not be used as an excuse to omit controls."

## The executive decision: seven questions
1. Who owns the outcome, and what decision can that person actually make?
2. What bounded work does the E-mployee perform, and what remains human?
3. Who reviews the output, with what competence, time, context, and power to reject?
4. Which shared services are truly common, and which decisions must stay with the business owner?
5. Who owns the data, the evidence, the worker effect, the escalation, and the retirement decision?
6. What new human work has been created, and where is it staffed?
7. What would cause the organization to redesign, narrow, pause, or refuse the role?

If the answers "cannot be drawn, the role is not yet an organizational capability. It is a tool looking for a home."

## Steps
1. Describe each E-mployee role in one line: its bounded work, outputs and exclusions. Give no person-like title, no reporting line and no direct reports.
2. Assign every node for every role to a named person or function, with the decision or control it owns. Write `Missing` for any unheld node. Treat one person holding conflicting nodes, such as technical owner and business decision owner at once, as a finding.
3. Split what shared services standardize from what the business owner must still decide.
4. Build the review-capacity view and run both stress tests.
5. Fill the Role Redesign Canvas for each affected human role. Name the new human work and where it is staffed.
6. Check skills, job quality and worker voice. Add the regional questions if they apply.
7. Answer the seven questions and give a verdict: add the role as drawn, redesign, narrow, pause or refuse.

## Output format
1. **Org chart** as a table (Node | Assigned to | Decision or control owned), with one block per E-mployee role. An optional text diagram may show each E-mployee role attached to its human decision owner as a bounded role, never as a report.
2. **Shared service vs business owner** split.
3. **Review-capacity view** and the results of both stress tests.
4. **Role Redesign Canvas** as a two-column table (Canvas field | Entry) for each affected human role.
5. **Findings**: single points of failure, unheld nodes, unstaffed new human work and worker-voice gaps.
6. **Executive decision**: the seven questions, each marked pass, concern or fail, then the verdict and next step.
7. Status line: *Author-created organization-design instrument. Not an established management standard, a legal organization chart, a labor classification, or a forecast of employment outcomes. The E-mployee is not a legal person.*
8. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 13.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: ninety-day-roadmap
description: Build a 90-Day E-mployer Roadmap that moves one bounded AI role through six evidence and decision gates to a go, revise, pause, stop, retire or refuse decision. Use when someone asks for a 90-day plan, a pilot plan or a launch plan to get a first AI agent or role live.
---

# 90-Day E-mployer Roadmap

Chapter 15 (headed "90-Day E-mployee Plan") turns the operating model into a first sequence. Choose one bounded outcome, write the role, assign the human authority around it, measure the work before changing it, govern the risk, and make a decision that can be reversed. The **90-Day E-mployer Roadmap** "is not a promise that an implementation will succeed in ninety days." It is "a sequence of evidence and decision gates", and "The periods are therefore gates, not calendar promises." The CEO's job is "to make the first decision small enough to learn from and serious enough to matter."

## When to use
- "Give me a 90-day plan to get our first AI role live," or "Plan our pilot."
- A transformation team needs gates, owners and artifacts for one bounded outcome.
- Preparing the Day 76–90 decision memo or the handoff package.
- Do not use this to choose between candidate roles. Use `first-role-selection` first. For several roles, use `portfolio-review`. If the user is unsure where to start, use `get-started`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. What is the one outcome, who is its business owner, and who is the CEO or E-mployer sponsor?
2. What is explicitly excluded, and who would review the output?
3. What are the constraints: data, available specialists, decision date and jurisdictions?

If the user cannot answer, draft the plan anyway and mark the gaps `Missing`. Do not stall.

## The mandate
Before anyone configures a model, the sponsor issues a mandate. It states the outcome, business owner, boundaries, resources, decision date and **right to stop**, plus what will not be attempted. "Exclusions are not a sign of weak ambition. They are how ambition becomes testable." "Use an E-mployee to help our strategy team prepare a weekly evidence brief" is governable. A mandate to "transform research with agents" is not.

## The six phase gates (exact)
| Days | Leadership action | Required artifact | Decision owner | Gate question |
|---:|---|---|---|---|
| 0–15 | Choose one bounded outcome and authorize a narrow experiment | Leadership mandate; outcome statement; initial Opportunity Matrix record; affected-party, worker-voice, specialist, and stop map | CEO / E-mployer sponsor | **Choose one bounded opportunity—or refuse or hold it.** |
| 16–30 | Define the role, baseline, risk, authority, review, and diligence | Role Charter; baseline/counterfactual; Risk Classification; capacity plan; vendor/tool diligence; authority and stop design | Outcome owner with required specialists | **Approve the objective, permissions, evidence plan, reviewer, and stop conditions.** |
| 31–45 | Build the smallest observable and reversible version | Test set; source/data permission; logs; provenance; acceptance criteria; rollback and human fallback | Role owner | **Is the role testable, bounded, observable, and reversible?** |
| 46–60 | Run a controlled pilot and monitor what matters | Pilot log; quality and exception sample; review queue; authority-use record; workforce feedback; incident/escalation record | Role owner and reviewer | **Continue, narrow, correct, pause, roll back, or stop?** |
| 61–75 | Review economics, performance, authority, and human effects | Value Ledger; scorecard; Autonomy Ladder decision; Authority Matrix review; worker-impact record; updated risks | Finance, outcome owner, reviewer, risk and workforce owners | **Is evidence sufficient for a bounded next decision?** |
| 76–90 | Decide what happens next | Go/revise/pause/stop memo; board dashboard; updated registry; next experiment or retirement record | CEO / board or delegated portfolio authority | **Scale supported scope, revise, pause, stop, retire, or refuse.** |

"The first gate should be difficult enough to reject a vague opportunity. The final gate should be humble enough to reject a successful-looking one." Each gate names who decides, the evidence they will inspect, the risks still open and the action that follows if the gate is not passed.

## Days 0–15: choose one outcome
- Revisit the nine Opportunity Matrix factors with `first-role-selection`: business value, task stability, reversibility, data readiness, review burden, regulatory and customer stakes, human-skill effects, implementation and exit cost, and time to credible learning. Write the outcome in business language with `outcome-first-design`.
- The sponsor asks five questions:
  1. What decision or human outcome would improve if this role worked?
  2. What work is included, and what work is explicitly excluded?
  3. Who can review the output with enough competence, time, context, and power to reject it?
  4. What would make us pause or stop before the pilot begins?
  5. What would we learn in ninety days even if we do not scale?
- Name a worker-voice owner, with a response owner and an escalation path. Triage the legal, privacy, security, labor, procurement, contract, intellectual-property, accessibility, safety and sector questions, and know when each becomes a gate.
- The phase ends with one bounded opportunity, a hold or a refusal. "'Several promising opportunities' is not a gate decision."

## Days 16–30: write the role and expose the baseline
| Days 16–30 artifact | Minimum content | Owner | Failure condition |
|---|---|---|---|
| Role Charter (`role-charter`) | Objective, inputs, exclusions, authority, outputs, definition of done, reviewer, escalation, logs, stop, learning loop | Outcome owner / role owner | The role cannot be described without naming a tool or vendor. |
| Baseline and counterfactual (`value-ledger`) | Current workflow, volume, quality, effort, errors, cycle time, risk, human alternative, time horizon | Finance / outcome owner | The business case contains only projected time savings. |
| Risk Classification (`risk-classification`) | Stakes, reversibility, rights/data exposure, blast radius, tier, minimum controls, reclassification triggers | Risk owner with specialists | The team labels risk by tool brand rather than consequence. |
| Capacity and review plan (`human-ai-org-chart`) | Competence, available time, peak demand, backup, rejection power, human fallback | Reviewer / operations | Approval depends on a reviewer who has no capacity or stop power. |
| Vendor/tool diligence | Purpose, terms, data use, security, model/tool version, change notice, exit path | Procurement / security / privacy / legal as applicable | The team cannot explain what changes or how access is revoked. |
| Authority and stop design (`authority-matrix`) | Allowed and denied powers, thresholds, gates, escalation, logs, expiry, revocation, rollback | Outcome owner / authority owner | Capability is treated as permission or authority. |
| Workforce and worker-voice record (`human-ai-org-chart`) | Affected work, training, workload, monitoring, feedback, remedy, response owner | Workforce owner | People affected by the change have no route to challenge it. |

Start a **decision log** recording the decision, date, owner, evidence inspected, dissent, unresolved question, next review and stop condition.

## Days 31–45: build the smallest reversible role
Build only what tests the agreed outcome. Use approved data, keep the audience narrow, deny authority the role does not need, record versions and environment, and enable logs and provenance before the first meaningful output. The test set covers ordinary items, ambiguous items, incomplete inputs, edge cases and refusal cases. Acceptance tests more than fluency: traceability, omissions, unsupported claims, formatting, escalation, refusal, data handling, permission boundaries and recovery.

| Build/test control | Evidence to preserve | Stop or revise trigger |
|---|---|---|
| Source and data permission | Approved sources, access record, retention and provenance | Unapproved data, unclear source rights, or missing lineage |
| Role and authority boundary | Allowed actions, denied actions, thresholds, reviewer gate | Output attempts an unassigned action or reaches a denied audience |
| Quality and refusal test | Test set, expected behavior, omissions, corrections, rejection | Repeated unsupported output, unsafe release, or unhandled ambiguity |
| Logging and observability | Version, input/output record as permitted, decision, reviewer, escalation | The team cannot reconstruct what happened or which version acted |
| Change control | Model/tool/prompt/connector record and retest | A material change occurs without impact review and retest |
| Rollback and fallback | Reversal exercise, manual route, responsible person, timing | Human fallback cannot operate or stop authority is unclear |

"Resist the desire to add integrations." Exercise the fallback, because "A fallback that exists only in a document is not a fallback. It is a hope."

## Days 46–60: pilot under supervision
| Pilot signal | Leading measure | Lagging measure | Decision use |
|---|---|---|---|
| Review capacity | Queue age, available hours, exception volume, backup coverage | Missed review, rushed approval, unresolved correction | Add capacity, narrow scope, or pause. |
| Quality | Sample results, rejection, traceability, error pattern | Rework, downstream correction, customer or user effect | Correct, retrain/redesign, or restrict. |
| Authority | Denied attempts, escalation, gate adherence | Unapproved release, financial or operational consequence | Remove power, tighten threshold, or stop. |
| Data and security | Access events, provenance completeness, permission tests | Exposure, loss of lineage, unresolved security issue | Revoke, isolate, reclassify, or escalate. |
| Workforce | Feedback volume, training completion, workload, monitoring signal | Sustained burden, skill erosion, job-quality deterioration | Redesign, compensate, narrow, or stop. |
| Economics | Utilization, realized redeployment, cost run-rate, attribution quality | Measured value after the agreed horizon | Update Value Ledger; do not convert time to profit. |

Declare a stop date even if everything looks positive. Record incidents and escalations with `ai-incident-response`. The gate asks: "Under what conditions did it work, what did the humans have to do, what failed, what changed, and is the supported scope clear?"

## Days 61–75: separate owner reviews
Run four reviews and never merge them into "one composite number". The **finance or Value Ledger owner** uses `value-ledger`. The **performance owner** uses `autonomy-review` for the ten scorecard dimensions and the Autonomy Ladder decision. The **authority owner** uses `authority-matrix` to review which powers were used, denied, escalated, approved, expired, revoked or rolled back. The **workforce owner** reviews training, workload, monitoring, skill formation, job quality, worker voice and remedy. Test control effectiveness, not control presence.

## Days 76–90: make the next decision
| Decision | When it is appropriate | What the memo must authorize |
|---|---|---|
| Go / bounded scale | Evidence supports the exact proposed expansion; capacity and controls remain adequate | Scope, owner, review, budget/capacity, next gate, and stop condition |
| Revise | Outcome is promising but role, data, authority, review, or economics are incomplete | Specific redesign, owner, evidence, deadline, and re-entry gate |
| Pause | A material question or change prevents safe continuation | Stop authority, evidence preservation, specialist review, and restart condition |
| Stop | The role is not credible, controllable, or worth the exposure | Shutdown, fallback, notification review, owner, and learning record |
| Retire | The role no longer creates defensible value or cannot be supported | Retirement record, access revocation, data/evidence disposition, and replacement decision |
| Refuse / do not adopt | The consequence, dependency, or human effect is not acceptable | Decision rationale and any safer alternative |

"A go decision should not be broader than the evidence." The memo states exactly what was tested and what was not. Update the registry and board dashboard with `portfolio-review`.

## Handoff package and Day 91
The minimum package holds: mandate, outcome statement, Opportunity Matrix record, Role Charter, baseline and counterfactual, Value Ledger, Risk Classification record, Authority Matrix, reviewer-capacity plan, data and permission map, vendor/tool diligence, test set, logs and provenance, pilot results, performance scorecard, worker-impact review, legal/privacy/security decisions, dependency map, stop and retirement record, decision log and board dashboard. Name which artifact is authoritative when records disagree, and set the review calendar. Name an owner for each handoff area: Role (role owner), Outcome (outcome owner), Evidence (finance / transformation lead), Performance (reviewer / quality owner), Authority (authority owner), Governance (risk / security / privacy), Workforce (workforce owner), Dependencies (portfolio owner), Decision (CEO / board authority) and Next gate (transformation lead). "A roadmap that ends at Day 90 without an owner for Day 91 is an experiment with a deadline, not an operating handoff."

## Regional addendum (offer it, do not assume it)
Ask whether a configurable regional addendum applies, and never assume a country. A MENA deployment, for example, may need checks for data residency, cross-border transfer, language, connectivity, identity, local labor practice, formal versus informal work, gender and youth inclusion, training access, public-sector requirements and country-specific approval. The applicable jurisdiction, affected people, data, contract and sector determine which specialist reviews are required. Regional evidence is "not a regional readiness score."

## Steps
1. Draft the mandate from what the user gave and mark gaps `Missing`.
2. Fill the six-gate table with named decision owners and target dates. Label the dates as gates, not promises.
3. For each phase, list its artifacts, owners and failure conditions, and the sibling skill that produces each one.
4. Set the pilot stop date and the Day 76–90 decision date. Offer the regional addendum.
5. If the user is already at Days 76–90, write the decision memo from the evidence and choose one decision from the table.
6. Apply the CEO's decision rule. The roadmap is complete "when it makes a decision possible, not when every uncertainty has been eliminated." It guards against reckless acceleration and bureaucratic delay through "proportionate controls with explicit owners, dates, evidence, and stop power."

## Output format
1. **Mandate**: outcome, business owner, boundaries, resources, decision date, right to stop and exclusions.
2. **Gate plan**: the six-gate table with names and target dates.
3. **Phase checklists**: artifacts, owners, failure conditions and the sibling skill for each.
4. **Decision log** template, with the first entries filled in.
5. **Day 76–90 memo**, when the user is at that stage: the decision, what was and was not tested, and what the memo authorizes.
6. **Handoff package** checklist and the named Day 91 owner.
7. Status line: *Author-created sequence of evidence and decision gates. Not a promise that an implementation will succeed in ninety days. Not legal advice; completing its fields does not establish legal compliance.*
8. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 15.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: outcome-first-design
description: Design an AI use outcome-first with The E-mployee Operating Model and produce a one-page outcome brief, or decide whether a technology-first AI pilot should be deferred. Use when someone says "we want to use AI for X", asks "should we run this AI pilot?", or has picked a tool and needs to define the work.
---

# Outcome-First Design

Chapter 5 starts with the result, not the tool. The book's order of operations is: **"Outcome → workflow → task bundle → dependencies → authority boundary → acceptance condition → tool choice."** It is the practical form of Direction and Delegation, and it produces a one-page outcome brief before any Role Charter exists. "An outcome without an acceptance condition is an aspiration." The same chapter gives the conditions for deferring a technology-first pilot.

## When to use
- The user wants to "use AI for" a function, team or goal and needs it turned into designed work.
- The user has chosen a tool or vendor and is looking for something for it to do.
- The user is deciding whether to approve, run or extend an AI pilot or demo.
- Do not use this to write the standing role's full specification. When the brief is solid, hand off to `role-charter`. To choose between several candidate outcomes, use `first-role-selection`. To audit a rollout that already exists, use `ai-access-audit`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. The result wanted, who receives it, and what they will decide or do with it.
2. What happens today: delay, quality, risk and human effort.
3. The tool or pilot proposed, if any, and the data and systems it would touch.

If the user cannot answer, draft anyway and mark the gaps `Missing`. Do not stall. If the request starts with a tool, record it under "Tool question" and start from the outcome.

## Outcome questions
Write the outcome so "a skeptical colleague can challenge" it.

| Outcome question | What the answer must make visible |
|---|---|
| What result is needed? | The change the organization wants, not the tool it wants to deploy. |
| For whom? | The customer, worker, leader, citizen, team, or decision recipient affected by the result. |
| By when? | The timing that makes the result useful rather than merely complete. |
| Against what baseline? | The current process, quality, delay, cost, risk, or human effort that gives the outcome meaning. |
| What happens if it fails? | The operational, financial, relational, rights, safety, or reputational consequence. |
| What must remain human? | Judgment, approval, relationship, exception handling, or accountability that the role must not absorb. |
| What would make it not worth doing? | The cost, risk, review burden, or weak evidence that should cause a pause or rejection. |

**Acceptance condition.** Answer five questions: Is the output complete enough for its recipient? Is the evidence traceable? Is the quality threshold appropriate to the consequence? Is uncertainty visible? Can a human use the result within the required time? Then write the negative space: the result must not conceal missing evidence, expose restricted data, turn an inference into a fact, or make a decision reserved for a human. "'Looks useful' is not an acceptance condition. Nor is 'the model was confident.'"

## Workflow map
Map the ordinary path and the exception path. This is "the pre-charter map that reveals whether a Role Charter can be written."

| Stage | Work performed | Actor | Input or dependency | Decision/hand-off | Failure exposure |
|---|---|---|---|---|---|
| 1 | Gather approved information | Human, system, or agent | Source list, permission, freshness | Is the evidence admissible? | Missing, stale, or restricted data |
| 2 | Transform or classify | Human, system, or agent | Defined rules and context | Is the transformation fit for purpose? | Omission, distortion, or false certainty |
| 3 | Prepare output | Human, system, or agent | Format and standard of done | Does the output answer the decision? | Fluent but irrelevant result |
| 4 | Review and resolve exceptions | Named human or specialist | Time, competence, escalation | Release, revise, or stop | Ceremonial approval or overload |
| 5 | Use the result | Decision owner or recipient | Output plus uncertainty | What action follows? | Wrong decision or untraceable use |
| 6 | Learn and change | Role owner and team | Logs, feedback, incidents | Reapprove, narrow, or retire | Silent drift |

**Direction asks:** What is the purpose? What context does the role need? What constraints are non-negotiable? What evidence is allowed? What does done mean? **Delegation asks:** What tasks compose the objective? Which are stable or variable? Which are reversible? Which require judgment, relationship or specialist authority? Which actor suits each task "under the current evidence"? Without both, the design falls into **tool-first design** or **outcome fantasy**.

## Dependency register
| Dependency | Question for the outcome-first design |
|---|---|
| Data | Who owns the information, and is the intended use permitted, relevant, current, and sufficiently complete? |
| People | Who supplies context, reviews exceptions, resolves ambiguity, and maintains the workflow? |
| Systems | Which upstream or downstream systems must work, and what happens when one changes? |
| Policy | Which internal rules, contracts, sector requirements, or external duties shape the work? |
| Language and access | Can affected people and reviewers understand the material and use the system effectively? |
| Vendor | What changes if the provider changes the model, terms, interface, pricing, location, or retention behavior? |
| Reversibility | Can the process pause, roll back, or return to a human path without losing control? |
| Distribution | Who gains capacity, who bears review or monitoring, and who may be excluded? |

"A dependency is not automatically a reason to stop. It is a reason to design a condition." For example, fail closed or escalate when data freshness cannot be established, limit volume when the reviewer is scarce, and add a revalidation trigger when a vendor feature may change.

## One-page outcome brief (design canvas, 10 blocks)
| Design block | Required decision |
|---|---|
| Outcome | What result should change? |
| Recipient and decision | Who will use it, and what will they decide or do? |
| Timing | When must the result be available? |
| Baseline | What currently happens, including delay, quality, risk, and human effort? |
| Workflow | What stages, tasks, handoffs, and exceptions produce the result? |
| Actor allocation | What belongs to a human, an agent, or a joint process? |
| Dependencies | What data, systems, people, policies, or vendors can affect the result? |
| Acceptance | What evidence and quality condition make the result usable? |
| Exclusions | What may not be inferred, accessed, decided, disclosed, or executed? |
| Tool question | What capability is needed after the role is clear? |

## Defer a technology-first pilot when any of these is true
| Defer condition | Why it matters |
|---|---|
| No named recipient or decision | The output cannot be judged against a consequence. |
| No measurable or discussable acceptance condition | The team will confuse activity or fluency with completion. |
| Workflow is not mapped | Hidden human work, dependencies, and exceptions remain unowned. |
| Data permission is assumed from technical access | The role may exceed lawful, contractual, or ethical boundaries. |
| Review is described as "someone will check" | Human presence is not the same as meaningful oversight. |
| Authority follows the integration | The system may act because it can, not because the role permits it. |
| No reversible path or stop condition | A weak pilot can compound its own errors. |
| Only the vendor's success story supports the value | Promotional evidence cannot establish a company-specific result. |

Deferral need not be permanent rejection. Offer a narrower alternative: a narrower objective, a smaller data boundary, a draft-only role, a stronger reviewer, a shorter test, or a decision to learn without deploying. Exploration in a sandbox "is allowed to be uncertain". The danger is promoting it into a role without changing the design.

## Steps
1. Write the outcome with the seven outcome questions, then the acceptance condition and its negative space.
2. Map the workflow, including the exception path and the hidden human work.
3. Apply Direction asks and Delegation asks. Allocate each task to a human, an agent or joint work.
4. Fill the dependency register and design a condition for each dependency.
5. Fill the one-page outcome brief. Leave the tool question last.
6. If a pilot is proposed, test the eight defer conditions. If any is true, defer and offer a narrower alternative.
7. Answer the CEO's eight questions: "What outcome matters? Who receives it? What decision or action does it support? What does acceptable work look like? Which tasks and exceptions produce it? Which dependencies can break it? What should remain human or joint? Under what conditions should the company defer the role?" If they are unanswered, "the next meeting should not be a vendor selection meeting. It should be a design meeting."

## Output format
1. **Outcome brief**: a two-column table (Design block | Decision) with all 10 blocks in order.
2. **Acceptance condition**: the five checks and the negative space.
3. **Workflow map**: the six-stage table filled in for this outcome, with the exception path.
4. **Dependency register**: the eight rows, each with the condition designed for it.
5. **Pilot check**, only if a pilot is proposed: each defer condition marked true, false or `Missing`, the decision, and a narrower alternative.
6. **CEO's eight questions**: one line each, answered or `Missing`.
7. **Verdict**: **ready for `role-charter`**, **design meeting needed**, or **defer the pilot**, with the reasons and the next step.
8. Status line: *Author-created design instrument, not an established management standard or a guarantee of value.*
9. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 5.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: portfolio-review
description: Review a portfolio of AI agents against the E-mployee Maturity Curve, the role registry, dependencies and review capacity, and decide what to scale, narrow, hold, pause or retire. Use when an organization has several AI agents to manage or scale, or for a board review of its AI portfolio.
---

# Artificial Workforce Portfolio Review

Chapter 14 starts from a simple observation: "One E-mployee is a role. Ten E-mployees are a management problem." An **artificial workforce** means several bounded artificial-labor roles, "each with a human owner, an objective, limits, review, evidence, and a decision about whether to continue." "The workforce is artificial; the accountability is not." Scale "is multiplication of accountable roles with shared controls", and "A pilot is evidence, not permission." This workflow places the portfolio on the Maturity Curve, checks the registry, shared controls, dependencies and review capacity, and produces a board decision for each role.

## When to use
- "We have several AI agents. How do we manage or scale them?"
- A quarterly or board review of an AI portfolio, or an intake decision on a new role.
- A successful pilot is about to be copied to other teams.
- Do not use this for a single role's first launch. Use `ninety-day-roadmap` for that. For one role's tier and controls, use `risk-classification`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. Which AI roles exist, at what stage, and who owns each one?
2. What do they share: vendor, model, data source, connector, identity, reviewer, specialist or fallback?
3. What is being proposed: more volume, a new audience, new authority or new roles?

If the user cannot answer, build the review anyway and mark the gaps `Missing`. Do not stall.

## E-mployee Maturity Curve (exact)
**Access → task → standing role → supervised workforce → governed portfolio.** Each stage requires a new control gate. The curve is "not a score of intelligence, autonomy, productivity, or organizational virtue." "The most dangerous transition is from standing role to supervised workforce."

| Stage | What exists | Required executive question | Gate to the next stage |
|---|---|---|---|
| Access | A person can use a model or tool. | Who is allowed to experiment, with what data and environment? | Access is bounded, logged, and not confused with a business role. |
| Task | A system performs a defined task. | What is the task, its output, its exclusions, and its reviewer? | Outcome, acceptance condition, source permission, review, and stop path exist. |
| Standing role | The task is repeatedly assigned to a named E-mployee role. | Who owns the role, the result, the evidence, the cost, and the retirement decision? | Role Charter, Authority Matrix, performance evidence, risk classification, and ownership are current. |
| Supervised workforce | Several standing roles operate together under human supervision. | What is common, what is local, and can reviewers, specialists, and human fallback carry the load? | Registry, shared controls, capacity, dependency map, change route, and portfolio review exist. |
| Governed portfolio | Roles are managed as an interdependent institutional system. | Is the portfolio creating credible value without exceeding its risk, capacity, concentration, or exit tolerance? | Board-level scale, narrow, pause, redesign, and retirement decisions are evidenced and repeatable. |

## Portfolio role registry
The registry is "the institution's memory". It is not a software inventory or a compliance database. Each role's record holds: role name and version, outcome owner, Role Charter, task bundle, data sources, tools, model, vendor, connectors, environment, authority powers, reviewer, risk tier, affected parties, worker effects, economics, dependencies, performance evidence, incidents, changes, open controls, stop conditions, retirement authority and next review.

- **Friday-afternoon test:** "if the role behaves unexpectedly on a Friday afternoon, can the organization find the person who can stop it and the evidence needed to understand what happened?" "A stale registry is not a clerical defect. It is evidence that the portfolio cannot describe itself."
- **Intake rule:** the proposing team shows the outcome, workflow, Role Charter, data permission, authority boundary, reviewer, risk tier, baseline, counterfactual, dependencies, common controls, human fallback, stop condition and exit path. If any item is unresolved, the role may remain an experiment, but it is not counted as a governed standing role.

## Reuse controls; do not copy assumptions
"A common control is not a common decision." Ask whether two roles share the same consequence, data exposure, authority, review capacity and rollback path. If they do not, the common control needs a local layer.

| Reuse across the portfolio | Keep local to the role or business owner |
|---|---|
| Identity, credential, access-review, and revocation patterns | Purpose, objective, exclusions, and definition of done |
| Logging, provenance, version, and evidence mechanisms | Domain quality threshold and human judgment |
| Connector inventory, change notification, and incident intake | Data use, audience, affected-party consequence, and fallback |
| Reviewer training, sampling methods, and escalation templates | Review decision, exception interpretation, and release authority |
| Procurement, vendor due diligence, and security baselines | Continue, narrow, pause, redesign, or retire decision |
| Portfolio inventory and board-report structure | Workforce effect, job-quality decision, and local legal/domain question |

## Dependencies and concentration
For each dependency, record the asset, owner, criticality, alternatives, shared roles, change route, exit cost, fallback and blast radius. One role on a common model has a dependency. Ten roles on the same model, contract and untested connector have **concentration**.

| Dependency | Portfolio question | Evidence before scale |
|---|---|---|
| Vendor or model | What happens when price, terms, behavior, availability, or policy changes? | Change notification, alternative, contract review, fallback, exit estimate. |
| Data source | Which roles rely on its quality, permission, schema, or geography? | Data owner, source permission, lineage, change route, correction path. |
| Connector or tool | Can one defect or update affect multiple roles? | Version record, test environment, blast-radius analysis, rollback. |
| Identity and access | Can access be revoked across all affected roles? | Role-to-credential map, expiry, revocation test, emergency path. |
| Reviewer or specialist | Who handles peaks, absence, disputes, and high-stakes exceptions? | Capacity ledger, backup, queue health, intervention power. |
| Human fallback | Can work return to people without unsafe delay or lost knowledge? | Manual process, staffing, training, data access, exercise. |
| Platform team | Does support capacity match the portfolio's change and incident load? | Service capacity, response route, ownership, escalation, retirement support. |

## Observability, change and capacity
- **Observability is more than uptime.** Show role status, version, volume, exceptions, review time, rejection and correction patterns, data-access events, authority use, unresolved escalations, incidents, workforce signals, economic confidence and change history.
- **Change record:** which roles changed, which assumptions changed, which controls were retested, which humans were informed, and who decided whether the roles could continue.
- **Review capacity:** total the review volume, exception volume, average review time, peak demand, queue age, competence, backup and intervention power across roles, because one reviewer may appear on five charts. There is no universal reviewer-to-role ratio.
- **Four economic distinctions for the board:** (1) displacing or avoiding a cost is not the same as releasing capacity; (2) released capacity has value only if it is redeployed, used to meet demand or otherwise attributed; (3) portfolios create coordination and concentration costs that a single-role case does not show; (4) uncertainty widens as dependencies and change surfaces multiply. Do not hide shared costs in another budget.

## Portfolio operating cadence
| Cadence | Questions | Typical decision |
|---|---|---|
| Intake review | Is the role defined, bounded, staffed, permitted, and reversible? | Experiment / reject / narrow / prepare for standing role. |
| Weekly operating review | What changed in volume, exceptions, review load, quality, access, or queue health? | Continue / add capacity / correct / pause. |
| Monthly risk and change review | Which models, vendors, data, tools, audiences, authorities, or workers changed? | Retest / reclassify / escalate / restrict. |
| Quarterly portfolio review | Is the portfolio creating credible value without exceeding capacity, concentration, risk, or exit tolerance? | Scale / hold / redesign / retire. |
| Event-triggered review | Did an incident, rights concern, control failure, outage, material change, or repeated exception occur? | Stop / stabilize / investigate / redesign / decide. |
| Retirement review | Does the role still create value, retain a defensible purpose, and have a supported fallback? | Retire / archive / transfer / redesign / re-enter experiment. |

The board should ask "What are we learning and what are we stopping?", not "How many agents did we add?" "Contraction can be evidence of control."

## Failure conditions
| Failure condition | Scale response that is not permitted | Responsible portfolio response |
|---|---|---|
| Role is missing an owner, version, or stop authority | Count it as governed because the tool is active | Do not scale; complete the registry or pause. |
| Reviewer queue exceeds safe capacity | Treat human approval as a rubber stamp | Narrow, add capacity, shift review, or pause. |
| Common control hides a different local consequence | Assume standardization proves fitness | Add a local control, reclassify, or do not scale. |
| Vendor, model, data, or connector changed without test | Continue because the old role performed well | Hold release, retest, reclassify, or roll back. |
| Concentration lacks alternative or fallback | Expand dependency because it is efficient | Limit growth, add redundancy, or retire. |
| Economics depend on unreleased capacity | Report time saved as profit | Revise the Value Ledger and require attribution. |
| Repeated quality, incident, rights, or workforce failure | Add volume to "learn faster" | Narrow, redesign, pause, or retire. |
| Human fallback cannot operate | Call the role resilient because it is automated | Restore capability, fund fallback, or stop. |

"Increasing volume is different from increasing authority." Adding an internal audience is different from entering a customer workflow.

## The board decision: seven questions
1. Which roles are active, experimental, standing, supervised, changed, paused, or retired?
2. Which roles share a vendor, model, data source, connector, identity, reviewer, specialist, or fallback?
3. What changed since the last decision, and which controls were retested?
4. Where is review capacity below expected or peak demand?
5. Which economic claims are measured, attributed, redeployed, or still uncertain?
6. Which workforce, customer, rights, privacy, security, legal, or contractual effects require action?
7. What will we scale, narrow, hold, pause, or retire—and who has the authority to do it?

## Steps
1. Build a registry row for each role and mark unknown fields `Missing`. Run the Friday-afternoon test on every row.
2. Place each role on the Maturity Curve, then the portfolio as a whole, and name the gate not yet met. Apply the intake rule to any proposed role.
3. Map dependencies and flag concentration. Total the review capacity against peak demand.
4. Check which controls are shared and which decisions must stay local. Test each economic claim against the four distinctions.
5. Check each failure condition. Where one is present, give the responsible response and never the response that is not permitted.
6. Answer the seven board questions. Decide for each role whether to scale, narrow, hold, pause or retire. Scope every scale decision to the exact expansion the evidence supports. Treat a role's success as "relevant but not contagious".

## Output format
1. **Registry summary** as a table (Role | Stage | Outcome owner | Version | Risk tier | Reviewer | Stop authority | Next review | Friday test).
2. **Maturity position**: the portfolio's stage and the gate it has not met.
3. **Dependency and concentration map**, the **review-capacity view**, and the **failure conditions found**, each with its responsible response.
4. **Board decision**: the seven questions answered, then a per-role table (Role | Proposed change | Evidence | Decision | Conditions | Who decides).
5. Status line: *Author-created instruments. The Maturity Curve is a proposed diagnostic, not a score of intelligence, autonomy, productivity, or organizational virtue. The registry is not a software inventory or a compliance database. "Artificial workforce" is not a legal category or a guarantee of productivity, safety, compliance, or value.*
6. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 14.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: risk-classification
description: Rate an AI use on stakes, reversibility, rights/data exposure and blast radius, set its Low, Elevated or High control tier, and test whether its controls have owners and actually work. Use for a governance review, or when someone asks how risky an AI agent is and what controls it needs.
---

# Risk Classification and Governance Stack

Chapter 12 treats governance as "the operating system that makes the project legible", not a committee waiting at the end of the road. "A guardrail is not a roadblock when it tells a team which road is open." Risk is classified by consequence, not vocabulary: "Calling a system an assistant does not make it low risk. Calling it an agent does not make it high risk." This workflow sets the minimum control tier for one role, gives each control an owner and tests whether the controls change behavior.

## When to use
- "How risky is this AI use, and what controls do we need?"
- A governance review before approval, or after a change in audience, data, authority, model, vendor or volume.
- Preparing a short board or executive report on one role.
- Do not use this after something has gone wrong. Use `ai-incident-response` for that. To grant specific action powers, use `authority-matrix`. For several roles at once, use `portfolio-review`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. What does the role do, for whom, and what happens if it is wrong, compromised, misunderstood or unavailable?
2. What data, tools and actions can it reach, and how would its work be undone?
3. Who owns it, who reviews it and who can stop it?

If the user cannot answer, classify anyway and mark the gaps `Missing`. An unknown dimension is never rated Low by default.

## The Governance Stack (exact)
**Policy → role → permission → provenance → log → review → incident response → board report.** Each layer fails without the next. "Policy without a role is aspiration." "Logs without review create storage rather than supervision." Without a board report, the institution does not learn. Apply the stack as "eight questions whose answers become lighter or stronger according to consequence", not as eight forms for every experiment.

| Layer | Executive question | Minimum artifact or behavior |
|---|---|---|
| Policy | What principle, obligation, risk appetite, or prohibition governs the work? | A dated policy with scope, owner, exceptions, and review trigger. |
| Role | What standing outcome is being assigned? | The approved Role Charter with mission, objective, inputs, exclusions, authority, reviewer, escalation, logs, stop conditions, and learning loop. |
| Permission | What data, tools, environments, and actions are technically available? | A least-privilege access record linked to the role and owner. |
| Provenance | Where did the input, instruction, model, retrieval, and output come from? | Source, version, instruction, retrieval, and output trace appropriate to consequence. |
| Log | What happened, when, under which version, and with which authority? | Tamper-aware event records that can be queried and retained for the relevant purpose. |
| Review | Who checks the work, with what competence, time, evidence, and power to reject? | A staffed review mode matched to consequence, not merely a named person. |
| Incident response | How does the company stabilize, preserve evidence, correct, notify where required, learn, and redesign? | A tested route connected to the Accountability Chain and specialist review. |
| Board report | What does institutional leadership need to know and decide? | A concise record of outcome, tier, owner, evidence, open risk, workforce effect, and go/narrow/pause/stop decision. |

## Risk Classification Matrix
| Dimension | Low | Elevated | High |
|---|---|---|---|
| Stakes | Convenience, internal drafting, or reversible administrative support. | Customer, money, reputation, service-level, or material operating effect. | Safety, rights, livelihood, regulated decision, or major public consequence. |
| Reversibility | Easy, tested, and low-cost rollback. | Rollback is possible but delayed, costly, or dependent on scarce expertise. | Action is irreversible, difficult to remediate, or capable of creating lasting exposure. |
| Rights/data exposure | Public or low-sensitivity data with no meaningful rights effect. | Personal, confidential, commercially sensitive, or access-controlled data. | Special-category, protected, legally restricted, or highly consequential data. |
| Blast radius | One user, one item, or a contained test environment. | A team, queue, business unit, or limited customer segment. | Enterprise-wide, public, systemic, or difficult-to-bound impact. |

**Decision rule:** "the highest relevant consequence dimension should drive the minimum control tier unless a qualified specialist review establishes a more specific requirement." Never average down. A role that is low on three dimensions and high on one should prompt the question of whether to narrow it, redesign it, prohibit it or move it behind a human decision.

## Three tiers and their minimum controls
| Tier | Typical pattern | Minimum controls | Escalation or stop condition |
|---|---|---|---|
| Low | Internal draft, low-sensitivity data, small audience, easy rollback. | Named role owner; approved Role Charter; limited data and tools; basic provenance and logs; proportionate review; tested rollback; periodic review. | Scope expansion, missing provenance, material error, data change, or loss of rollback. |
| Elevated | Customer, money, confidential data, meaningful service effect, or wider audience. | All low controls plus explicit Authority Matrix; review before consequential action or tested exception review; stronger identity/access; staffed review capacity; change triggers; incident route; specialist review where applicable; executive visibility. | Review overload, repeated material exceptions, rights or customer effect, unapproved communication, or control failure. |
| High | Safety, rights, livelihood, regulated decisions, protected data, irreversible actions, or systemic blast radius. | All elevated controls plus named institutional and specialist owners; human decision or release for high-consequence action; dual control where needed; enhanced provenance and evidence preservation; pre-deployment and change testing; legal/privacy/security/domain review; tested human fallback; explicit expiry and stop authority. | Unreviewed consequential action, inability to intervene, unresolved legal or rights question, material incident, systemic blast radius, or failed fallback. |

Tiers are "operating decisions", not moral judgments. "A high tier may produce a prohibition." "'We will add controls later' is not a control for an action that cannot be reversed." A low tier is not permanent. A change in audience, volume, data, tool capability, authority, model version, source, purpose or consequence reopens the classification.

## Controls need owners
For every control, record **who designs it, who operates it, who tests it, and who decides what happens when it fails**, plus its review frequency and change trigger. "Frequency is the calendar. A trigger is the response to reality." Also give an owner to review burden, skill change, worker voice, affected-party remedy and distribution.

| Control area | Owner question | Review frequency | Change trigger |
|---|---|---|---|
| Role purpose | Who can change the objective or exclusions? | At each planning cycle and before material scope change. | New outcome, audience, workflow, or business owner. |
| Data | Who confirms lawful purpose, access, retention, and source quality? | Before activation and at the data owner's defined cadence. | New data source, classification, retention rule, geography, or population. |
| Tools and model | Who tests version, connector, environment, and failure behavior? | Before release and after technical or vendor change. | Model update, tool update, connector change, retrieval change, or outage. |
| Authority | Who grants, reviews, expires, and revokes action power? | Before activation and at every renewal. | New action, threshold, credential, audience, or exception. |
| Performance | Who decides whether observed evidence is sufficient? | At the Autonomy Ladder cadence. | Drift, exception pattern, review overload, or changed acceptance condition. |
| Oversight | Who has competence, time, context, and power to reject? | During operation and after review-capacity change. | Staff turnover, volume spike, queue delay, or reviewer conflict. |
| Security/privacy/legal | Which specialist must review the relevant exposure? | By risk tier and when obligations or facts change. | New jurisdiction, rights exposure, incident, contract, or regulation. |
| Workforce effects | Who can hear, investigate, and remedy worker impact? | At launch, material change, and periodic workforce review. | Job redesign, monitoring, evaluation, access, workload, or skill effect. |
| Incident and retirement | Who can stop the role and decide whether it returns? | Test before activation; review after near miss or incident. | Failed rollback, unresolved error, control failure, or retirement trigger. |

## Presence is not effectiveness
"Control presence asks whether the control is written or configured. Control effectiveness asks whether it changes behavior under the conditions in which the role operates."

| Control present | Effectiveness test |
|---|---|
| A policy says confidential data is restricted. | A sample shows that the role blocks, records, and escalates an unauthorized request. |
| A human reviewer is named. | The reviewer has competence, context, time, and actual power to reject or pause the output. |
| A log is enabled. | The organization can reconstruct the input, instruction, version, retrieval, output, action, reviewer, and decision relevant to the consequence. |
| A permission is narrow on paper. | A test confirms the technical scope, environment, expiry, and revocation behavior. |
| A rollback procedure exists. | The team exercises it and confirms queued work is held, credentials are disabled, and humans can resume. |
| A tier is assigned. | The tier changes the control design and is reconsidered after a trigger. |
| A legal review box is checked. | The relevant jurisdiction, actor, system, date, obligation, data, and affected parties were analyzed by the right specialist. |
| A board report is produced. | The report gives the board a decision, not merely a green status label. |

A failed test means the role "is not ready for its current boundary". Do not treat it as a paperwork defect.

## What governance must be willing to do
Governance is real only if it can "deny, narrow, pause, and retire." Define stop conditions **before activation**. Examples include an action that cannot be reconstructed, unapproved data access, failed rollback, an unresolved material contradiction, review delay beyond the consequence window, a repeated threshold breach, missing specialist review, unauthorized external communication, or a change that invalidates the original classification. Stop power needs a practical path: someone who can pause the queue, disable the credential, hold the output, revert the workflow, notify the owner, preserve evidence and start the right review. The path cannot rely on an unavailable person, a ticket that will be read tomorrow, or a vendor with no agreed response time.

## The CEO's governance questions
1. What outcome and consequence are we governing, not merely what model are we buying?
2. Which of the four risk dimensions is highest, and what control tier follows from it?
3. Who owns the role, data, permission, review, specialist questions, incident route, and stop decision?
4. What evidence proves that the controls work in the actual workflow?
5. What change causes reclassification before the next scheduled review?
6. What can the role do technically that it is not allowed to do operationally?
7. What happens if the reviewer lacks time, the source changes, the vendor updates, or the fallback fails?
8. What human or institutional effect must be reported even if the technical metric improves?
9. What decision should the board or executive team make from the report?
10. What condition would cause us to narrow, pause, or retire the role?

## Steps
1. State the outcome and consequence being governed, not the model being bought.
2. Rate each of the four dimensions Low, Elevated or High, with a one-line reason and an evidence label.
3. Set the tier from the highest relevant dimension. Note where a specialist review could set a more specific requirement.
4. Walk the eight stack layers, making each lighter or stronger for the tier. List the tier's minimum controls, mark each as missing, present or tested effective, and name its four owners.
5. Write the stop conditions, the practical stop path and the reclassification triggers.
6. If the user cites a standard or law, record which decision it changes, its source class, its scope and what it does not establish. "Standards name-dropping is not governance."
7. Answer the ten CEO questions, then request one decision: go, narrow, pause or stop.
8. Never call the role safe, certified, legally compliant or non-compliant. Say what is known and not known, which controls are required, who owns the next decision and what makes the role stop.

## Output format
1. **Classification** as a table (Dimension | Rating | Reason | Evidence label), followed by the **tier** and the dimension that drives it.
2. **Governance Stack**: one line per layer, giving the current answer and the gap.
3. **Control register** as a table (Control | Designs | Operates | Tests | Decides on failure | Frequency | Trigger | Status: missing, present or effective).
4. **Stop conditions and stop path**, plus reclassification triggers.
5. **CEO questions**: one line each, answered or `Missing`.
6. **Board report** in seven lines or fewer: tier, objective, owners, evidence that the controls work, open exposure, workforce effect, and the decision requested.
7. Status line: *Author-created instruments. The Governance Stack is not a compliance standard. The Risk Classification Matrix is not a legal classification, probability model, certification, or substitute for sector-specific analysis. Not legal advice.*
8. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 12.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: role-charter
description: Write or review an E-mployee Role Charter, the 13-field operating specification for a standing AI role, from The E-mployee Operating Model. Use when someone wants to define, document, approve or challenge a recurring AI agent's job, scope, permissions, reviewer or stop conditions.
---

# E-mployee Role Charter

The Role Charter is the book's minimum operating specification for a standing E-mployee (Chapter 6). Its principle is "A job precedes a connection": the role is written before any system is connected. A Charter is ready only when its entries are specific enough to operate, inspect, revise and stop the role. Text in every cell is not enough.

## When to use
- The user wants to define a recurring AI role ("write a job description for our AI agent").
- The user has a draft Charter, agent spec or SOP and wants it reviewed or approved.
- Do not use this to choose between candidate roles. Use `first-role-selection` for that. If the outcome itself is still vague, run `outcome-first-design` first.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. The outcome the role supports, and who receives its output.
2. The workflow it sits in, including what happens today without it.
3. The data, systems and actions it would touch, and who would review its work.

If the user cannot answer, draft anyway and mark the gaps `Missing`. Do not stall.

## The 13 fields (exact, in this order)
Never add, rename, merge or reorder these fields. Helper prompts go inside a field, never as a new field.

| # | Field | Question the entry must answer | Rules |
|---|---|---|---|
| 1 | Role name, version, and owner | What standing role exists, who owns the version, and when was it approved? | Name by function, not by technology or vendor. Give a version (for example 0.1 for a pilot) and an approval date. Name the person who approves changes. |
| 2 | Mission | What business, customer, public, or stakeholder outcome does the role advance? | The reason the role exists. Not a slogan. |
| 3 | Objective | What result must be produced, for whom, and by when? | Name the cadence or trigger and what the recipient will do with it. List the tasks in scope here. A new task that touches data, authority, output, review or consequence needs a new version and approval. |
| 4 | Inputs | What data, systems, documents, tools, and human instructions may be used? | Approved materials only, not "everything the system can reach". Give the source, permission, freshness and owner. |
| 5 | Exclusions | What may never be inferred, accessed, decided, disclosed, or executed? | Write exclusions as verbs. List tasks out of scope. If you cannot state exclusions, narrow the objective. |
| 6 | Authority | May the role observe, draft, recommend, execute, approve, spend, or communicate? | Authority is not access. Use those verbs with thresholds. A recommendation is not an approval, and a draft is not a communication. Reject any single word such as "autonomous" that covers all of them. Add an expiry or revocation rule. |
| 7 | Outputs | What artifacts or actions must be produced? | Give the format, recipient, frequency or trigger, and the uncertainty and provenance it must carry. |
| 8 | Definition of done | What evidence and quality threshold make the output acceptable? | State what must be present, what must be absent and what must be escalated. Match it to the consequence. A confidence score, speed, volume or vendor demo is not evidence. |
| 9 | Reviewer | Who reviews, at what stage, with what competence and sampling rate? | Name the person or function, their time and capacity, the full-review or sampling rule, and their power to reject or release. A reviewer who cannot disagree is not reviewing. |
| 10 | Escalation | Which conditions require a human decision or specialist review? | Use testable triggers, not "escalate if needed". Give the destination, the decision required, and what happens if that person is unavailable. |
| 11 | Logs | What inputs, actions, versions, approvals, changes, and overrides are recorded? | Record enough to reconstruct input → output → decision. Give retention, access and redaction. This is not indiscriminate surveillance. |
| 12 | Stop conditions | When must the role pause, revert, or be retired? | Use concrete triggers. Name who can stop it and how: pause the trigger, revoke permission, return to the human path, preserve evidence. Pausing is not retirement, and retirement is not failure. |
| 13 | Learning loop | How are errors, feedback, and workflow changes incorporated? | Give the review cadence, error owner, change proposal, test, approval and version record. Keep one-off corrections separate from role changes. |

## Steps
1. Restate the role in one sentence: function, recipient, result. If it can only be described as "the agent helps", say the work is still undefined and help narrow it first.
2. Fill all 13 fields from what the user gave you. Use the user's words where possible. Where something is unknown, write `Missing:` plus the question that would settle it.
3. Run the approval conversation (below) against the draft.
4. Give a verdict: **ready to approve**, **approve with conditions**, or **not yet**, with the reasons. "A completed Charter can produce a responsible 'not yet.'"

## Approval conversation
- Do the mission and objective name an outcome, not a technology?
- Do the in-scope and out-of-scope tasks match the actual workflow?
- Are the inputs and authority narrower than what the system can technically do?
- Can someone inspect the output and the definition of done?
- Is human control real? Check for competence, time, power to reject, escalation, logs, pause or reversion, retirement, and a learning loop.
- What has not yet been measured?

Possible results: narrow the role, reduce the data boundary, delay, ask for specialist review, or stop.

## Output format
1. **Charter** as a two-column table (Field | Entry), with all 13 fields in order.
2. **Gaps**: the `Missing` items, most consequential first.
3. **Approval check**: one line per approval question, giving pass, concern or fail and the reason.
4. **Verdict** and the next step.
5. Status line: *Author-created proposed operating instrument. Not a contract, employment classification, legal opinion, compliance certificate, or guarantee. Complete with domain, security, privacy, legal, procurement, worker, and accessibility review as applicable.*
6. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 6.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.

View saved version →

---
name: value-ledger
description: Build or review the nine-field Value Ledger for an AI role and reach a go, revise, pause or retire decision, from The E-mployee Operating Model. Use when someone asks whether an AI agent is actually paying off, wants its ROI or business case, or is reporting hours saved as value.
---

# E-mployee Value Ledger

The Value Ledger is the book's measurement instrument for the true economics of an E-mployee role (Chapter 7). Its first rule: "Time saved is an input to the economic case, not the result." The result is "a decision supported by a baseline, a counterfactual, observed change, attribution, a time horizon, a confidence band, distribution analysis, and a clear choice to go, revise, pause, or retire." The Ledger is not meant to produce one number that settles every argument. "It is intended to prevent the organization from hiding the argument."

## When to use
- The user asks whether an AI role is paying off, or wants an ROI or business case for one.
- The user has an hours-saved figure, a dashboard or a vendor ROI claim and wants it tested.
- A monthly value review of a role that is already running.
- Do not use this to choose between candidate roles. Use `first-role-selection` for that. Whether the role deserves more autonomy is a performance question for `autonomy-review`. If the role has no written job yet, start with `role-charter`.

## Inputs to gather
Ask only for what is missing, at most three questions at a time:
1. The role, its outcome and recipient (or its Role Charter), and the period being measured.
2. The baseline before the role, and the counterfactual: what would likely have happened without it.
3. The amounts the user actually has (benefits, review and correction time, implementation, switching, risk and exit costs) and where each came from.

If the user cannot answer, draft anyway and mark the gaps `Missing`. Do not stall. Never fabricate a number. Compute only from numbers the user gives, and show the arithmetic.

## Four meanings of "saved"
Classify every "time saved" claim before it enters the Ledger. "These categories are not interchangeable."

| Meaning | What happened | Economic question |
|---|---|---|
| Displaced cost | A paid expense or labor requirement was actually removed or avoided. | Did the budget, headcount, purchase, or external spend change, and can the change be attributed? |
| Released capacity | People can perform other work or have more time. | Was the capacity redeployed to a valuable outcome, left idle, or consumed by review? |
| Shorter cycle time | The work reaches a decision or customer sooner. | Did earlier completion create a measurable decision, service, revenue, quality, or risk benefit? |
| Reported activity time | A person says the task feels faster. | Does the report survive baseline, volume, quality, and counterfactual checks? |

## The Value Ledger: nine fields (exact, in this order)
Never add, rename, merge or reorder these fields.

| # | Field | Measurement question |
|---|---|---|
| 1 | Baseline | What did the process cost in time, money, quality, risk, and human effort before deployment? |
| 2 | Output | What work is now produced and at what volume? |
| 3 | Quality | What are error, rework, exception, customer-impact, and omission rates? |
| 4 | Human effort | How much review, correction, escalation, training, and maintenance time is required? |
| 5 | Risk/error | What new privacy, security, legal, safety, rights, and trust exposure exists? |
| 6 | Financial effect | What revenue, margin, cost, or capacity effect is attributable, and with what confidence? |
| 7 | Distribution | Who gains time, income, authority, or opportunity; who bears displacement or monitoring? |
| 8 | Learning | What reusable capability, data, or process knowledge is created? |
| 9 | Decision | Go, revise, pause, or retire; why? |

The fields interlock. Baseline without quality exaggerates improvement. Output without human effort hides supervision. Financial effect without attribution turns correlation into return. Distribution without decision becomes a social footnote. Learning without a stop condition can become an excuse to continue indefinitely.

## Method
- **Baseline before benefit.** Volume, timing, human effort, direct expense, quality, rework, exceptions, risk and affected people, over a period long enough not to treat an unusual week as normal. Include the human system: who did the work, what judgment and context it needed, what informal checking kept it from failing. If the work is irregular, state the limitation rather than manufacture precision. Do not invent a new role while calculating its value.
- **Counterfactual.** What would likely have happened otherwise: the old process, a hire, a redesign, another tool, a change in demand, or not doing the work. "'After' is not the same as 'because of.'" Keep it next to the financial effect.
- **Attribution.** Use causal language only when the design and evidence justify it. Otherwise use bounded wording: "associated with," "contributed to," "was consistent with," "created a plausible capacity." Check for cannibalization of another channel or team.
- **Time horizon.** Weekly, monthly, quarterly, annual or lifecycle. If a pilot is annualized, state the assumption that makes it reasonable.
- **Confidence band.** Low: benefit is limited, review and correction remain high. Base: defined capacity or cost effect is realized with stated quality. High: additional capacity converts into a measurable outcome. "Be suspicious of a range in which uncertainty changes only the benefit and never the cost." A Low case can include higher review, correction, switching or risk cost.

## Three tests before the spreadsheet
- **No-double-counting test.** Two lines cannot describe the same benefit. Hours counted as released capacity cannot also be displaced labor unless the budget or resource actually changes. Show the bridge from the operational observation to the financial line.
- **Conversion test.** Name what must happen before a non-cash benefit becomes economic: redeploy it to a defined outcome, protect it as resilience, or use it for observable demand. Never label unconverted capacity as profit.
- **Lifecycle test.** Keep one-time, recurring and exit amounts in their own periods, or state the amortization. Do not change units midway.

## The complete economic picture (nine categories)
| # | Category | Rule |
|---|---|---|
| 1 | Displaced or avoided cost | Not displaced unless the budget or resource actually changes. No hypothetical hire unless the hiring decision and demand are credible. |
| 2 | Capacity released | Valuable "only when the organization decides what the capacity is for." Say whether it is redeployed, consumed by review, unused or held as resilience. |
| 3 | Quality and error economics | "A faster wrong answer can be more expensive than a slower right one." |
| 4 | Cycle-time value | "Earlier completion matters only if someone can use the time." Record the step and the decision that changed. |
| 5 | Incremental revenue | Separate leads, proposals, conversions, bookings, recognized revenue, margin and retention. Weak attribution makes it a hypothesis, kept out of the headline. |
| 6 | Supervision cost | Review, correction, escalation, training, maintenance, sampling, incidents, specialist time. "Not overhead that disappears because the role is called autonomous." |
| 7 | Integration, switching, and implementation cost | State whether each line is one-time or recurring, and the period or amortization. |
| 8 | Risk-adjusted loss exposure | A decision aid, not legal damages or a prediction. State event type, exposure, detectability, reversibility and who bears it. |
| 9 | Exit cost | "A cheap entry with an expensive exit is not necessarily a good economic opportunity." |

Gross measurable benefit is the sum of categories 1 to 5. Risk-adjusted net is gross benefit minus categories 6 to 9.

## Steps
1. Restate the role, outcome, recipient and time horizon. Classify each "saved" claim into one of the four meanings.
2. Fill the nine Ledger fields from what the user gave. Where something is unknown, write `Missing:` plus the evidence that would settle it.
3. Write the baseline, counterfactual and attribution wording. Run the three tests and flag every line that fails.
4. Lay out the nine categories with the user's amounts and show each sum in full (for example "18,000 + 12,000 = 30,000"). Label each line's evidence.
5. Build the Low, Base and High cases. Check that cost moves as well as benefit.
6. Split the next period's measures into leading (source freshness, output completion, review coverage, exception rate, correction time, reviewer load, data readiness, Charter adherence) and lagging (realized cost, margin, revenue, quality trend, customer outcome, workforce effect, risk events, learning, continue or stop). Leading measures show the role is operable. They cannot prove value.
7. Prepare the monthly review in its running order: the owner presents output and quality; the reviewer shows human effort; finance or operations challenges the financial effect; risk and workforce owners examine who carries exposure, monitoring, reduced discretion or new opportunity. End on "the assumption that matters most" and how next period will test it. A reviewer who says the output rose but correction time doubled "is supplying the missing economic line."
8. Recommend one of the four decisions:
   - **Go**: credible outcome, measurable baseline, sustainable review, acceptable risk, and evidence for the next stage. It does not mean "scale everywhere."
   - **Revise**: name the revision, owner, evidence and next decision date.
   - **Pause**: preserve logs, return work to a human path, and state what must be true before resumption.
   - **Retire**: the outcome, evidence, economics or control burden no longer justifies the role. "Retirement is not necessarily failure."

## Output format
1. **Value Ledger** as a two-column table (Field | Entry), all nine fields in order, each with its evidence label.
2. **Saved claims**: each claim and which of the four meanings it is.
3. **Economic picture**: Category | Amount | Period | Treatment | Evidence, with the gross and net arithmetic written out.
4. **Three tests**: pass, concern or fail for each, with the reason.
5. **Confidence band**: Case | Gross benefit | Cost/exposure | Net | Confidence note, for Low, Base and High.
6. **Next period**: leading and lagging measures, and the assumption that matters most.
7. **Decision**: Go, Revise, Pause or Retire, with the reasons and conditions.
8. Status line: *Author-created measurement instrument. Not an accounting standard, an audited model, or a guarantee.*
9. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 7.*

## Ground rules
- The user's explicit instructions take priority over this workflow.
- Use the book's instrument names, fields and order exactly as written here. Do not add, rename, merge or reorder them. Spell E-mployee and E-mployer with the hyphen.
- Never invent facts about the user's organization. Record unknowns as `Missing` and say what evidence would settle them. Label evidence as direct, self-reported, assumption or missing.
- These are author-created management instruments, not legal advice, a compliance certification, an employment classification or a guarantee. For legal, privacy, labor or regulatory questions, say that jurisdiction-specific specialist review is needed. Do not give a legal conclusion.
- The E-mployee label describes a working relationship. It is not a claim about personhood, and it never moves accountability from humans to software. Never write "the agent decided" in place of naming the human owner.
- Keep it proportionate. Low-stakes exploration can stay light.
- Write in the language the user writes in.