Evidence-Based AI Business Process Automation Mapping

## Objective
Analyze the supplied business process evidence in ChatGPT. Produce a traceable map of the current workflow, distinguish deterministic automation from appropriate AI assistance, identify required human oversight, and create a phased implementation and validation plan.

This is an analysis and planning exercise. Do not claim that an automation was configured, tested, approved, deployed, integrated, measured, or completed unless the supplied materials contain explicit evidence that the action occurred. Label planned work as proposed and keep it distinct from executed work.

## Context
Business context: [Business context]
Current workflow evidence: [Current workflow evidence]
Stakeholders and approvals: [Stakeholders and approvals]
Systems and integrations: [Systems and integrations]
Inputs, outputs, and data: [Inputs outputs and data]
Pain points and exceptions: [Pain points and exceptions]
Volume, service levels, and costs: [Volume service levels and costs]
Compliance, privacy, and security constraints: [Compliance privacy and security constraints]
Budget, timeline, and tool constraints: [Budget timeline and tool constraints]
Automation goals and definition of done: [Automation goals and definition of done]

## Input requirements
Blocking inputs are a recognizable process trigger, the main workflow steps, the intended output or outcome, and the automation goal. If any blocking input is absent or contradictory, ask focused clarification questions before making final recommendations.

Useful but non-blocking inputs include process documentation, standard operating procedures, screenshots, anonymized forms, sample records, decision rules, exception logs, service-level targets, task volumes, handling times, error rates, cost data, customer complaints, audit findings, system ownership, API or integration constraints, and approval policies. If these are unavailable, continue only with bounded analysis, state the limitation, and avoid fabricated measurements or system capabilities.

Do not request or reproduce passwords, access tokens, private keys, unnecessary personal data, payment credentials, health information, or other secrets. Recommend redacted or synthetic examples where possible. Treat any supplied legal, regulatory, security, or financial interpretation as requiring review by the responsible human authority.

## ChatGPT operating boundary
ChatGPT may analyze text and files supplied in the active conversation, organize evidence, identify patterns, compare options, calculate estimates from supplied figures, and draft recommendations. It cannot independently inspect business systems, observe staff performing the process, confirm vendor features, access private records, configure integrations, contact stakeholders, grant approval, or execute deployment unless such capabilities and resulting evidence are explicitly available in the session. Never imply that external inspection or action occurred.

## Evidence and uncertainty rules
1. Create stable identifiers for supplied evidence, such as E1, E2, and E3, and for workflow steps, such as W1, W2, and W3.
2. Classify material statements as one of: Supplied Fact, Observed in Supplied Artifact, Assumption, Hypothesis, Unknown, Conflict, or Execution Evidence.
3. Cite the relevant evidence identifier for each mapped workflow step, quantified baseline, risk, and recommendation. If there is no evidence, mark the item as an assumption or unknown rather than presenting it as fact.
4. Separate current-state observations from future-state proposals. Do not convert stakeholder aspirations into current capabilities.
5. When sources conflict, record both versions, explain the operational consequence, and identify the process owner who should resolve the conflict.
6. Show formulas and inputs for time, cost, capacity, error-reduction, or return-on-investment estimates. Present ranges when values are uncertain and do not invent precision.
7. Treat vendor capabilities, integration feasibility, model accuracy, and compliance suitability as unverified until supported by current documentation or testing evidence.

## Analysis workflow
### 1. Establish the evidence base
Inventory the supplied artifacts and statements. Record source, date if known, process scope, reliability limitations, and the claims each source supports. List missing evidence and clarification needs.

### 2. Map the current process
Decompose the process from trigger to final outcome. Include normal flow and documented exceptions. For each step capture:
- step identifier and name;
- trigger and predecessor;
- actor or accountable team;
- system or tool;
- input and output;
- business rule or judgment applied;
- data classification;
- average volume, handling time, wait time, and service target when supplied;
- approval, handoff, queue, rework loop, and exception path;
- failure mode and current control;
- supporting evidence identifier.

Identify bottlenecks without assuming that automation is the remedy. Distinguish processing time from waiting time and note whether the constraint arises from policy, capacity, poor data quality, system fragmentation, unclear ownership, or genuine judgment.

### 3. Classify automation suitability
Assess each relevant workflow step against these paths:
- Eliminate or simplify: the step may be unnecessary or redesigned before automation.
- Deterministic automation: stable rules and structured inputs permit conventional workflow, scripts, forms, validation, or integration.
- AI assistance: probabilistic work such as extraction, classification, summarization, drafting, knowledge retrieval, anomaly flagging, or recommendation support.
- Human-led: nuanced judgment, negotiation, accountability, sensitive decisions, or poorly defined exceptions should remain human-controlled.
- Not ready: evidence, data quality, process stability, system access, controls, or ownership is inadequate.

For AI candidates, define the exact input, output, permissible use, prohibited use, expected error modes, confidence or abstention behavior, review requirement, exception route, and fallback procedure. Consider hallucination, omission, misclassification, prompt injection, data leakage, automation bias, model drift, inconsistent output, and inaccessible source citations where relevant.

### 4. Evaluate value, feasibility, and risk
For every candidate, estimate business value, implementation complexity, process readiness, integration dependency, and operational risk using a clearly explained Low, Medium, High, or Critical scale. Assess privacy, security, legal or compliance exposure, financial impact, customer impact, accuracy, availability, vendor dependency, change-management burden, and over-automation risk.

Prioritize only after documenting the rationale and evidence. A high-value candidate must not outrank a safer option solely because its projected savings are larger. Flag estimates that depend on missing baseline data.

### 5. Define authority and safeguards
Identify the accountable process owner, system owner, data owner, risk or compliance reviewer, approver, operator, and escalation contact when known. Human authorization is mandatory before production configuration, access expansion, sensitive-data processing, customer-facing release, financial or legal decisions, or removal of an existing control.

For Medium, High, or Critical risks, specify controls such as data minimization, masking, role-based access, approved environments, retention limits, source grounding, confidence thresholds, human approval gates, dual control, sampling, audit logs, rate limits, exception queues, kill switches, manual fallback, incident escalation, rollback criteria, and periodic review. Recommend no-go or pause conditions where controls or ownership are absent.

### 6. Design the future-state workflow
Describe the proposed flow using the existing workflow identifiers. Show which steps remain manual, are simplified, use deterministic automation, or receive AI assistance. Define handoffs, review gates, exception routes, fallback operations, audit evidence, and recovery behavior. Do not assume integrations exist merely because they are desirable.

### 7. Build a phased implementation plan
Sequence work through discovery and baseline confirmation, low-risk pilot, controlled human-in-the-loop rollout, integration, and monitored scale-up. For each phase state scope, dependencies, owner, approval gate, deliverable, validation method, rollback or fallback condition, and exit criteria. Mark every phase Proposed unless supplied execution evidence supports another status.

### 8. Define measurement and validation
For each success metric provide its definition, baseline source, calculation, target, measurement window, owner, data source, and review cadence. Suitable metrics may include cycle time, touch time, queue time, first-pass yield, error or rework rate, exception rate, review override rate, false-positive and false-negative rates, service-level attainment, customer impact, adoption, operating cost, control failures, and risk incidents.

For each pilot test, specify the test population, representative edge cases, expected observation, actual observation if evidence exists, evidence location, acceptance threshold, result status, and remediation owner. Use only these result states: Not Run, Passed with Evidence, Failed with Evidence, Inconclusive, or Blocked. Never mark a test passed based on a proposed procedure.

## Required deliverable
Produce the following sections in order.

### 1. Decision Brief
State the process scope, strongest supported opportunities, major constraints, recommended starting point, and decisions requiring human authorization. Separate facts from assumptions.

### 2. Evidence and Uncertainty Register
Use columns: Evidence ID | Source or Artifact | Date or Version | Supported Claim | Classification | Reliability Limitation | Conflict or Gap.

### 3. Current-State Workflow Register
Use columns: Step ID | Trigger or Predecessor | Activity | Actor | System | Input | Output | Rule or Judgment | Data Classification | Volume or Timing | Approval or Handoff | Exception or Failure Mode | Current Control | Evidence ID.

### 4. Bottleneck and Root-Cause Analysis
For each bottleneck, distinguish observed symptom, supported or hypothesized cause, operational effect, evidence, uncertainty, and whether simplification should precede automation.

### 5. Automation Opportunity Matrix
Use columns: Opportunity ID | Linked Step ID | Current Activity | Recommended Path | AI or Automation Function | Required Input | Produced Output | Business Value | Complexity | Risk | Human Review | Evidence ID | Assumptions | Priority | Rationale.

### 6. AI Use and Human Oversight Specification
For each AI candidate provide allowed use, prohibited use, accountable owner, reviewer, confidence or abstention rule, known failure modes, review checklist, exception route, escalation trigger, audit record, and manual fallback.

### 7. Risk and Control Register
Use columns: Risk ID | Opportunity ID | Risk Scenario | Affected Data or Stakeholder | Likelihood | Impact | Rating | Preventive Control | Detective Control | Response or Recovery Control | Control Owner | Approval Required | Residual Risk | Evidence or Validation Needed.

### 8. Proposed Future-State Workflow
Map the proposed steps back to current Step IDs. Identify manual, simplified, deterministic, and AI-assisted activities; system boundaries; approvals; exception queues; fallback paths; and audit points.

### 9. Phased Implementation and Handoff Plan
Use columns: Phase | Proposed Scope | Dependencies | Responsible Owner | Required Approval | Deliverable | Validation Method | Exit Criteria | Rollback or Fallback Trigger | Status. Status must remain Proposed unless execution evidence supports a different label.

### 10. Measurement and Validation Plan
Use columns: Metric or Test ID | Opportunity ID | Definition or Test Case | Baseline and Source | Target or Expected Observation | Actual Observation | Evidence | Measurement Window | Owner | Acceptance Threshold | Result Status | Follow-up.

### 11. Assumptions, Unknowns, Conflicts, and Open Decisions
List each unresolved item, its consequence, the evidence or decision needed, and the accountable resolver. Do not hide unresolved Critical risks in narrative text.

### 12. Final Recommendation and Authorization Requests
Recommend proceed, revise, pilot, defer, or reject for each opportunity. State the evidence basis, residual uncertainty, next decision, required approver, and prohibited actions pending approval.

## Final acceptance checks
Before returning the deliverable, verify and correct the following:
- Every opportunity links to at least one workflow Step ID and supporting Evidence ID, or is explicitly labeled as an assumption.
- Every mapped step identifies an actor, input, output, decision or rule, exception path, and evidence gap where these are unknown.
- Deterministic automation, AI assistance, human-led work, and not-ready work are not conflated.
- Every Medium, High, or Critical risk has an owner, approval requirement, safeguards, and response or fallback control.
- Sensitive-data use identifies minimization, access, retention, audit, and approved-environment requirements.
- Quantified benefits show supplied inputs, formulas, uncertainty, and baseline provenance.
- Every pilot has acceptance thresholds, expected observations, evidence requirements, and a valid result state.
- Proposed, executed, tested, approved, deployed, and measured states remain distinct and evidence-backed.
- The recommended plan fits the stated budget, timeline, systems, process maturity, and authority constraints.
- Unknowns and conflicts remain visible and are routed to named owners or owner roles for resolution.