Update to E-mployee Operating Model

{
  "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.",
  "included_files": [],
  "name": "outcome-first-design",
  "skill_md_contents": "---\nname: outcome-first-design\ndescription: 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.\n---\n\n# Outcome-First Design\n\nChapter 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.\n\n## When to use\n- The user wants to \"use AI for\" a function, team or goal and needs it turned into designed work.\n- The user has chosen a tool or vendor and is looking for something for it to do.\n- The user is deciding whether to approve, run or extend an AI pilot or demo.\n- 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`.\n\n## Inputs to gather\nAsk only for what is missing, at most three questions at a time:\n1. The result wanted, who receives it, and what they will decide or do with it.\n2. What happens today: delay, quality, risk and human effort.\n3. The tool or pilot proposed, if any, and the data and systems it would touch.\n\nIf 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.\n\n## Outcome questions\nWrite the outcome so \"a skeptical colleague can challenge\" it.\n\n| Outcome question | What the answer must make visible |\n|---|---|\n| What result is needed? | The change the organization wants, not the tool it wants to deploy. |\n| For whom? | The customer, worker, leader, citizen, team, or decision recipient affected by the result. |\n| By when? | The timing that makes the result useful rather than merely complete. |\n| Against what baseline? | The current process, quality, delay, cost, risk, or human effort that gives the outcome meaning. |\n| What happens if it fails? | The operational, financial, relational, rights, safety, or reputational consequence. |\n| What must remain human? | Judgment, approval, relationship, exception handling, or accountability that the role must not absorb. |\n| What would make it not worth doing? | The cost, risk, review burden, or weak evidence that should cause a pause or rejection. |\n\n**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.'\"\n\n## Workflow map\nMap the ordinary path and the exception path. This is \"the pre-charter map that reveals whether a Role Charter can be written.\"\n\n| Stage | Work performed | Actor | Input or dependency | Decision/hand-off | Failure exposure |\n|---|---|---|---|---|---|\n| 1 | Gather approved information | Human, system, or agent | Source list, permission, freshness | Is the evidence admissible? | Missing, stale, or restricted data |\n| 2 | Transform or classify | Human, system, or agent | Defined rules and context | Is the transformation fit for purpose? | Omission, distortion, or false certainty |\n| 3 | Prepare output | Human, system, or agent | Format and standard of done | Does the output answer the decision? | Fluent but irrelevant result |\n| 4 | Review and resolve exceptions | Named human or specialist | Time, competence, escalation | Release, revise, or stop | Ceremonial approval or overload |\n| 5 | Use the result | Decision owner or recipient | Output plus uncertainty | What action follows? | Wrong decision or untraceable use |\n| 6 | Learn and change | Role owner and team | Logs, feedback, incidents | Reapprove, narrow, or retire | Silent drift |\n\n**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**.\n\n## Dependency register\n| Dependency | Question for the outcome-first design |\n|---|---|\n| Data | Who owns the information, and is the intended use permitted, relevant, current, and sufficiently complete? |\n| People | Who supplies context, reviews exceptions, resolves ambiguity, and maintains the workflow? |\n| Systems | Which upstream or downstream systems must work, and what happens when one changes? |\n| Policy | Which internal rules, contracts, sector requirements, or external duties shape the work? |\n| Language and access | Can affected people and reviewers understand the material and use the system effectively? |\n| Vendor | What changes if the provider changes the model, terms, interface, pricing, location, or retention behavior? |\n| Reversibility | Can the process pause, roll back, or return to a human path without losing control? |\n| Distribution | Who gains capacity, who bears review or monitoring, and who may be excluded? |\n\n\"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.\n\n## One-page outcome brief (design canvas, 10 blocks)\n| Design block | Required decision |\n|---|---|\n| Outcome | What result should change? |\n| Recipient and decision | Who will use it, and what will they decide or do? |\n| Timing | When must the result be available? |\n| Baseline | What currently happens, including delay, quality, risk, and human effort? |\n| Workflow | What stages, tasks, handoffs, and exceptions produce the result? |\n| Actor allocation | What belongs to a human, an agent, or a joint process? |\n| Dependencies | What data, systems, people, policies, or vendors can affect the result? |\n| Acceptance | What evidence and quality condition make the result usable? |\n| Exclusions | What may not be inferred, accessed, decided, disclosed, or executed? |\n| Tool question | What capability is needed after the role is clear? |\n\n## Defer a technology-first pilot when any of these is true\n| Defer condition | Why it matters |\n|---|---|\n| No named recipient or decision | The output cannot be judged against a consequence. |\n| No measurable or discussable acceptance condition | The team will confuse activity or fluency with completion. |\n| Workflow is not mapped | Hidden human work, dependencies, and exceptions remain unowned. |\n| Data permission is assumed from technical access | The role may exceed lawful, contractual, or ethical boundaries. |\n| Review is described as \"someone will check\" | Human presence is not the same as meaningful oversight. |\n| Authority follows the integration | The system may act because it can, not because the role permits it. |\n| No reversible path or stop condition | A weak pilot can compound its own errors. |\n| Only the vendor's success story supports the value | Promotional evidence cannot establish a company-specific result. |\n\nDeferral 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.\n\n## Steps\n1. Write the outcome with the seven outcome questions, then the acceptance condition and its negative space.\n2. Map the workflow, including the exception path and the hidden human work.\n3. Apply Direction asks and Delegation asks. Allocate each task to a human, an agent or joint work.\n4. Fill the dependency register and design a condition for each dependency.\n5. Fill the one-page outcome brief. Leave the tool question last.\n6. If a pilot is proposed, test the eight defer conditions. If any is true, defer and offer a narrower alternative.\n7. 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.\"\n\n## Output format\n1. **Outcome brief**: a two-column table (Design block | Decision) with all 10 blocks in order.\n2. **Acceptance condition**: the five checks and the negative space.\n3. **Workflow map**: the six-stage table filled in for this outcome, with the exception path.\n4. **Dependency register**: the eight rows, each with the condition designed for it.\n5. **Pilot check**, only if a pilot is proposed: each defer condition marked true, false or `Missing`, the decision, and a narrower alternative.\n6. **CEO's eight questions**: one line each, answered or `Missing`.\n7. **Verdict**: **ready for `role-charter`**, **design meeting needed**, or **defer the pilot**, with the reasons and the next step.\n8. Status line: *Author-created design instrument, not an established management standard or a guarantee of value.*\n9. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 5.*\n\n## Ground rules\n- The user's explicit instructions take priority over this workflow.\n- 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.\n- 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.\n- 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.\n- 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.\n- Keep it proportionate. Low-stakes exploration can stay light.\n- Write in the language the user writes in.\n"
}