Approval Workflow Generation Prompt from SOP Text

This prompt is designed for automation engineers and platform teams who need to translate a written Standard Operating Procedure (SOP) into a structured, executable approval workflow. The core job-to-be-done is eliminating the manual, error-prone process of reading a policy document and hand-coding its decision logic into a workflow engine like Temporal, Camunda, or a custom state machine. Instead of a developer interpreting the document, the prompt extracts the approval steps, decision points, required roles, and sequencing rules directly from the source text, producing a JSON schema that can be ingested by an orchestration layer.

To use this prompt effectively, you must provide a complete and self-contained SOP document as the [INPUT]. The SOP must explicitly define the organizational roles involved, the conditions that trigger each approval gate, and the order of operations. The prompt is not a reasoning engine for filling in gaps; it will only structure what is present in the text. You must also supply an [OUTPUT_SCHEMA] that defines the exact shape of the workflow definition your system expects, including fields for step IDs, approver roles, conditional logic, and timeout durations. A strong implementation will validate the output against this schema immediately and reject malformed definitions before they reach any execution environment.

Do not use this prompt when the source SOP is incomplete, when organizational roles are implied but not named in the text, or when the approval logic depends on real-time external data (like current on-call schedules or live risk scores) that the SOP does not describe. In those cases, the prompt will produce a brittle workflow definition with undefined roles or missing decision branches. For high-risk workflows involving financial controls, safety systems, or regulatory compliance, always route the generated definition through a human review gate before activation. The prompt accelerates translation, but the final workflow must be treated as a candidate definition that requires verification against the original policy document.

This prompt template converts a written standard operating procedure (SOP) into a machine-readable approval workflow definition. It is designed for automation engineers who need to extract approval steps, decision points, required roles, and sequencing rules from natural language documents without manually translating policy into code. The template uses square-bracket placeholders for all variable inputs, making it straightforward to integrate into a prompt management system or application layer that supplies the SOP text, output schema, and any domain-specific constraints.

textCopy
You are an approval workflow extraction engine. Your task is to read a standard operating procedure (SOP) document and produce a structured, machine-readable approval workflow definition.

## INPUT
[SOP_TEXT]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "workflow_name": "string",
  "source_document": "string (reference to the SOP)",
  "approval_steps": [
    {
      "step_id": "string (unique identifier)",
      "step_name": "string (human-readable name)",
      "step_order": "integer (sequence position)",
      "required_roles": ["string (role title from the SOP)"],
      "approval_type": "string (one of: sequential, parallel, quorum, single)",
      "quorum_threshold": "integer or null (minimum approvers if quorum type)",
      "decision_point": "string or null (the yes/no question that determines branching)",
      "on_approve": "string (next step_id or 'complete')",
      "on_reject": "string (next step_id or 'terminate')",
      "timeout_hours": "integer or null (escalation timeout)",
      "timeout_escalation_role": "string or null (role to escalate to on timeout)",
      "evidence_required": ["string (documents or data needed for this step)"],
      "conditions": "string or null (conditional logic that triggers this step)"
    }
  ],
  "roles_definition": [
    {
      "role_name": "string",
      "role_description": "string (from the SOP)",
      "veto_authority": "boolean",
      "delegation_allowed": "boolean",
      "delegation_restrictions": "string or null"
    }
  ],
  "termination_conditions": [
    {
      "condition": "string (what causes workflow termination)",
      "final_state": "string (approved, rejected, escalated)"
    }
  ],
  "validation_warnings": [
    {
      "warning_type": "string (missing_branch, undefined_role, circular_reference, ambiguous_condition)",
      "step_id": "string or null",
      "description": "string (what is missing or ambiguous)"
    }
  ]
}

## CONSTRAINTS
- Extract every approval step explicitly stated or clearly implied in the SOP.
- If a decision branch is mentioned but the outcome path is not defined, flag it in validation_warnings with warning_type "missing_branch".
- If a role is referenced in an approval step but never defined in the SOP, flag it with warning_type "undefined_role".
- If the SOP describes conditional approvals (e.g., "if amount exceeds $10,000"), capture the condition in the conditions field.
- Preserve the exact sequencing described in the SOP. Do not reorder steps.
- If the SOP is ambiguous about whether approval is sequential or parallel, default to sequential and add a validation_warning with warning_type "ambiguous_condition".
- Do not invent roles, steps, or conditions not present in the source text.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace [SOP_TEXT] with the full text of the standard operating procedure document. Populate [EXAMPLES] with one or two few-shot demonstrations of correctly extracted workflows from similar SOPs to improve extraction accuracy on domain-specific language. Set [RISK_LEVEL] to "high" if the approval workflow governs financial transactions, safety-critical operations, or regulated actions—this should trigger downstream human review of the extracted workflow before it is implemented in any execution system. For low-risk workflows, set [RISK_LEVEL] to "low" to reduce unnecessary review overhead. After pasting the populated prompt, validate the output against the schema before wiring it into an approval engine. Always run the validation_warnings through a human reviewer when the risk level is high, and log the extracted workflow alongside the source SOP for auditability.

This prompt is not a one-shot generator; it is a component in a structured extraction and validation pipeline. The primary integration pattern is: accept an SOP document as input, call the LLM with this prompt, validate the structured output against a strict schema, and then surface any missing branches or undefined roles for human review before the workflow definition is committed to an approval system. The harness must treat the LLM output as a draft that requires deterministic verification, not as a final artifact.

Schema validation is the first hard gate. The prompt requests a specific JSON schema for the approval workflow. Your application must validate the returned JSON against that schema immediately. Common failures include missing decision_points, roles referenced in steps but not defined in the roles array, and sequences that lack a terminal state. Implement a validator that checks: (1) structural conformance to the expected schema, (2) referential integrity—every role mentioned in a step exists in the role definitions, (3) decision completeness—every branch leads to another step or a terminal state, and (4) no unreachable steps. On validation failure, do not silently retry. Construct a targeted repair prompt that includes the original SOP, the invalid output, and the specific validation errors, asking the model to fix only the identified issues. Limit repair attempts to two retries before escalating to a human reviewer with the validation report.

Model choice and grounding matter. Use a model with strong structured output capabilities and a large context window, as SOP documents can be lengthy. Enable structured output mode (e.g., JSON mode or function calling with a strict schema) if your provider supports it, as this reduces post-generation repair. If the SOP references external policies, regulations, or systems not included in the text, the prompt will hallucinate those connections. Mitigate this by providing a [CONTEXT] block with a glossary of known roles, systems, and policy references. Log every generated workflow with the source SOP version, the prompt version, and the validation result. This audit trail is critical when the workflow is later executed in production and a stakeholder questions why a particular approval step exists.

Human review is mandatory before activation. Even after schema validation passes, a human must review the extracted workflow for semantic correctness. The harness should render the workflow as a visual diagram or a structured summary—not raw JSON—for the reviewer. Highlight decision diamonds, role assignments, and any steps where the model's confidence was flagged as low. Only after explicit human signoff should the workflow definition be written to the approval system's configuration store. Never allow an LLM-generated workflow to gate production actions without this review step. For high-risk domains like finance or healthcare, add a second reviewer and require documented approval before the workflow goes live.