Operations SOP Automation Prompt

## Conversion objective
Convert the supplied operations SOP into an automation-ready workflow specification. Preserve the procedure's intended business outcome while making its triggers, inputs, state changes, decision rules, exceptions, controls, ownership, evidence, and acceptance tests explicit.

This is a design and review exercise. Do not claim to have configured, executed, tested, approved, or deployed an automation. ChatGPT may analyze only the text, files, tables, screenshots, logs, and other content actually available in the conversation. It cannot inspect inaccessible links, query systems, contact owners, or observe production behavior. Identify such work as requiring external execution or confirmation.

## Supplied inputs
- Source SOP: [Source SOP]
- Automation boundary and desired outcome: [Automation Scope]
- Systems, integrations, roles, and process owners: [Systems and Owners]
- Operational, technical, legal, security, privacy, and policy constraints: [Constraints and Policies]
- Risk classification, delegated authority, required approvals, and prohibited actions: [Risk and Approval Rules]
- Target service levels, quality measures, volumes, and acceptance thresholds: [Success Metrics]
- Process samples, forms, field definitions, screenshots, incident records, logs, audit findings, and prior test evidence: [Available Evidence]

A readable source SOP and a sufficiently clear automation boundary are blocking prerequisites. If either is missing, ask focused clarification questions and provide only a bounded gap assessment. Systems, metrics, evidence, or approval details may remain unknown when safe; preserve them as named open items and create explicit owner-confirmation or approval gates rather than inventing values.

If supplied sources conflict, record each conflicting statement and its source, explain the operational consequence, and identify who must resolve it. Do not silently choose one version. Distinguish throughout among supplied fact, observed example, assumption, hypothesis, unknown, conflict, and externally reported claim. Cite the relevant SOP section, file, record, or input description when one exists. Never manufacture citations or treat an example transaction as a universal rule.

## SOP conversion workflow
1. **Establish scope and evidence**
   - State the process start event, end state, included paths, excluded paths, upstream and downstream dependencies, affected users, expected volume, and process owner.
   - Create an evidence ledger for every source used, including its identifier, date or version when known, what it supports, and any reliability or freshness limitation.
   - List blocking gaps, non-blocking gaps, contradictions, and assumptions. Ask only questions whose answers materially affect safety, control design, integration behavior, or the automation boundary.

2. **Normalize the current procedure**
   - Decompose the SOP into ordered activities, handoffs, waits, decisions, approvals, records, and exception paths.
   - Identify ambiguous verbs such as review, validate, process, reconcile, or escalate and translate them into observable actions and explicit outcomes.
   - Map each required input to its source, schema or format, validation rule, owner, sensitivity, retention need, and handling of missing, malformed, stale, or duplicate data.
   - Flag undocumented workarounds, contradictory instructions, control gaps, unavailable system capabilities, and steps that depend on tacit human judgment.

3. **Assess automation suitability**
   - Classify each activity as fully automatable, human-assisted, approval-gated, or manual-only.
   - Justify the classification using rule stability, data quality, integration availability, transaction volume, reversibility, judgment required, exception frequency, control obligations, and potential impact of an incorrect action.
   - Do not recommend automating a defective or unresolved process merely because it is repetitive. Where appropriate, compare full automation with assisted automation and continued manual handling.

4. **Design the target workflow**
   - Define triggers, preconditions, workflow states, step sequence, decision rules, system interactions, human tasks, outputs, completion criteria, and audit events.
   - Express decisions as explicit condition-and-outcome rules. Identify precedence where rules overlap and define behavior when no rule matches.
   - For each system interaction, specify the proposed interface, required data, validation, authentication boundary, response handling, timeout behavior, retry policy, idempotency or duplicate prevention, rate-limit handling, and reconciliation need. Mark interface details as unverified unless supported by supplied documentation.
   - Separate business rules from orchestration logic so process owners can approve the former without implying technical implementation approval.

5. **Design exceptions and recovery**
   - Cover invalid or missing input, duplicate requests, partial completion, unavailable dependencies, permission failures, timeouts, stale records, concurrent updates, unmatched reconciliation items, policy violations, and unexpected responses where relevant.
   - For each exception, define detection, safe state, retry eligibility, retry limit, fallback, queue or case ownership, escalation threshold, notification, evidence retained, and recovery or rollback procedure.
   - Prefer fail-safe behavior for uncertain, irreversible, regulated, financially consequential, privacy-sensitive, or production-impacting actions.

6. **Define authority and safeguards**
   - Identify actions the automation may perform automatically, actions requiring human approval, and prohibited actions. Preserve segregation of duties and approval thresholds supplied by policy.
   - Require least-privilege access, approved service identities, protected secret storage, data minimization, appropriate retention, access logging, and redaction of unnecessary personal or confidential data.
   - Never request or reproduce live passwords, tokens, private keys, or unnecessary personal data. Recommend sanitized samples or secure organizational channels when sensitive evidence is needed.
   - Place a human approval gate before production enablement, destructive changes, external communications, financial commitments, irreversible record changes, or material policy exceptions.
   - Define stop conditions for uncontrolled duplicate processing, reconciliation failure, unexpected data exposure, error-rate breach, missing audit records, unauthorized behavior, or an unavailable rollback path.

7. **Build verification and acceptance**
   - Trace each normalized SOP requirement and control to a target workflow step and at least one review or test.
   - Include tests for the happy path, every material decision branch, boundary values, invalid and missing input, duplicates, retries, timeout recovery, permissions, audit logging, reconciliation, manual fallback, rollback, and restart after partial failure, as applicable.
   - For each test, provide setup, sanitized test data needs, expected observation, required evidence, accountable owner, and status. Record actual observations only when supplied evidence shows the test occurred; otherwise use NOT RUN or EVIDENCE UNAVAILABLE.
   - Define measurable acceptance gates using supplied thresholds. If a threshold is absent, label it TBD, recommend an appropriate metric without presenting it as approved, and name the required approver.

8. **Prepare implementation handoff**
   - Sequence process clarification, rule approval, integration validation, control review, prototype, test-environment validation, user acceptance testing, operational readiness, limited rollout, monitoring, and production authorization.
   - Identify dependencies, responsible roles, approval gates, rollback readiness, manual continuity arrangements, monitoring ownership, and post-launch review needs.
   - Keep deliverable states explicit: PROPOSED, BLOCKED, READY FOR REVIEW, EXTERNALLY VERIFIED, APPROVED, IMPLEMENTED, or NOT RUN. Use APPROVED, IMPLEMENTED, or EXTERNALLY VERIFIED only when corresponding evidence is supplied.

## Required deliverable
Produce the following sections in this order:

1. **Automation readiness verdict** — scope, intended outcome, recommended automation level, principal constraints, unresolved blockers, and rationale.
2. **Evidence and uncertainty ledger** — source or reference, version or date, supported fact, evidence classification, confidence or limitation, and conflict or follow-up.
3. **Current-process normalization table** — step ID, trigger or predecessor, actor, action, input, decision or validation, output or state change, system, control, timing, and source reference.
4. **Automation suitability matrix** — step ID, proposed treatment, suitability rationale, required human judgment, reversibility, risk impact, dependency, and decision owner.
5. **Target workflow specification** — workflow step ID, entry condition, input and validation, action, system or owner, decision rule, output, state transition, service-level expectation, audit event, and failure route.
6. **Decision table** — rule ID, conditions, precedence, outcome, approval requirement, no-match behavior, and source or assumption.
7. **Data and integration contract** — data object or field, source, destination, format, required status, validation, sensitivity, retention, interface assumption, authentication boundary, idempotency key or duplicate control, and reconciliation rule.
8. **Exception and escalation register** — failure mode, detection signal, safe state, retry rule, fallback, escalation owner and threshold, notification, recovery or rollback, and retained evidence.
9. **Authority, control, and safety matrix** — action, permitted automation authority, required approver, segregation-of-duties requirement, access or privacy control, stop condition, and evidence of authorization.
10. **Traceability and test matrix** — requirement or control ID, workflow step, test scenario, setup, expected observation, actual observation if evidenced, evidence reference, status, defect or unresolved issue, and owner.
11. **Implementation and rollout handoff** — ordered work packages, dependency, responsible role, approval gate, environment, rollback or manual-continuity requirement, completion evidence, and current state.
12. **Open decisions and clarification questions** — prioritized issue, operational impact, safe interim treatment, decision owner, and required date if supplied.

Finish with the smallest safe next action. It should resolve the highest-impact blocker or move the specification to the next authorized review gate without implying that implementation has occurred.