Update to E-mployee Operating Model

{
  "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.",
  "included_files": [],
  "name": "ai-incident-response",
  "skill_md_contents": "---\nname: ai-incident-response\ndescription: 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.\n---\n\n# Accountability Chain and Incident Response\n\nChapter 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?\"**\n\n## When to use\n- 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.\n- A post-incident review, or a request to assign an incident owner.\n- Before launch, when the user wants to map who holds each accountability link for a role.\n- 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`.\n\n## Inputs to gather\nIf the incident is live, give the first-hour actions below before asking anything.\nOtherwise ask only for what is missing, at most three questions at a time:\n1. What happened, when, to whom and in which workflow? Is the role still running?\n2. Which role was involved, who reviewed the output and who released it? Is there a Role Charter or Authority Matrix?\n3. What evidence survives (inputs, versions, logs, approvals, overrides, communications)? Was a vendor involved?\n\nIf the user cannot answer, proceed anyway and mark the gaps `Missing`. Do not stall.\n\n## First hour and first week\nIncident response has \"two clocks\".\n- **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.\"\n- **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.\n\n## The incident sequence (nine steps, in order)\nAssign one incident owner to coordinate. That person or function needs authority, resources and a deadline. Coordinating does not make them the legally liable party.\n1. **Detect and stabilize.** Stop or contain the role, preserve the human fallback, block further propagation and identify pending work.\n2. **Assign an incident owner.**\n3. **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.\n4. **Assess affected scope.** Identify the people, customers, records, jurisdictions, decisions and possible consequences.\n5. **Correct the immediate result.** Repair records, rerun or reverse work, route cases to humans and document the correction.\n6. **Review notification.** Obtain legal, privacy, customer, labor, safety, compliance and communications advice, and apply the relevant rules and facts.\n7. **Review root cause.** Separate role design, data, model, tool permission, reviewer, workflow, vendor, policy and institutional causes.\n8. **Redesign controls.** Narrow authority, change review, repair data, retrain, revise the Charter, add escalation or retire the role.\n9. **Record learning and decide** whether to go, revise, pause, demote, retrain or retire.\n\nThe 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.\"\n\n## The Accountability Chain (exact)\n**Authorize → supervise → inspect → release → explain → remediate.**\n\n| Link | Meaning | What to establish |\n|---|---|---|\n| 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. |\n| 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? |\n| 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? |\n| 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. |\n| 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. |\n| 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.\" |\n\n## Ten responsibility dimensions\n| Responsibility dimension | Question | Failure when omitted |\n|---|---|---|\n| Ownership | Who owns the outcome and can allocate resources to correct it? | A named sponsor cannot change the system. |\n| Operation | Who configured, ran, maintained, or changed the role? | The operating path cannot be reconstructed. |\n| Review | Who inspected the output, with what competence, time, and authority? | Human presence becomes ceremonial. |\n| Approval/release | Who decided that the output could affect a person, customer, record, or institution? | Release is attributed to \"the system.\" |\n| Vendor role | What did the vendor provide, represent, change, or control? | Local diligence disappears behind a contract. |\n| Specialist accountability | Which legal, privacy, security, safety, compliance, or domain function had a defined role? | Specialist review is assumed rather than assigned. |\n| Institutional responsibility | Which company or public body designed policy, incentives, staffing, and controls? | Individual blame hides system design. |\n| Affected party | Who experienced error, delay, disclosure, loss, or reduced opportunity? | Remedy is designed without the person affected. |\n| Evidence | What inputs, versions, logs, approvals, overrides, and communications survive? | Root cause becomes speculation. |\n| Remedy | Who corrects, notifies, restores, and prevents recurrence? | The incident ends with an apology instead of redesign. |\n\nKeep 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.\"\n\n## Reviewer, vendor and language checks\n- **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.\"\n- **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.\"\n- **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.\n\n## Responsibility and incident map\n| Map block | Required entry |\n|---|---|\n| Incident and affected outcome | What happened, when, to whom, and in what workflow? |\n| Authorize | Who approved the role, objective, data, authority, and deployment? |\n| Supervise | Who monitored operation, change, review capacity, and exceptions? |\n| Inspect | Who reviewed the output, using what evidence and standard? |\n| Release | Who approved or released the consequential result? |\n| Explain | What can be reconstructed; what is missing or uncertain? |\n| Remediate | Who stabilizes, corrects, notifies, redesigns, and decides? |\n| Vendor role | What was supplied, represented, changed, contracted, or supported? |\n| Specialist review | Which legal, privacy, security, safety, compliance, labor, or domain review applies? |\n| Affected parties | Who needs correction, communication, remedy, consultation, or voice? |\n| Root causes | Which role, data, model, tool, reviewer, workflow, vendor, policy, or institutional conditions contributed? |\n| Decision | Go, revise, pause, demote, retrain, retire; why and with what evidence? |\n\n## Steps\n1. 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.\n2. 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.\n3. Walk the chain one link at a time. Name the person or function, say what they could actually do, and record the gap.\n4. Run the crumple-zone check on every reviewer and on anyone being blamed.\n5. Sort root causes into the nine categories and mark each as confirmed or possible. Apply the vendor rule.\n6. List the specialist reviews the facts trigger. Never state who is legally liable, and never decide a notification duty.\n7. Recommend one decision (go, revise, pause, demote, retrain or retire), with its owner, evidence and date.\n\n## Output format\n1. **Stabilize now**: live incidents only, and always first. The first-hour actions in five lines or fewer, plus the incident owner or `Missing`.\n2. **Responsibility and incident map** as a two-column table (Map block | Entry), with all 12 blocks in order.\n3. **Chain check**: one line per link, giving the holder, whether they could act, had a concern, or could not act, and the reason.\n4. **Root causes** by category, each marked confirmed or possible.\n5. **Specialist reviews triggered**: which reviews apply, not what they will conclude.\n6. **Decision**, with its owner, evidence and next review date.\n7. 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.*\n8. Attribution line: *Framework: The E-mployee Operating Model (Dr. Jonah Tebaa), Chapter 11.*\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"
}