BPMN.

POOL: CUSTOMER
  [Submit request] ──message──▶

POOL: AI PRODUCT
  Lane: API
  Lane: Orchestrator
  Lane: Human Reviewer

POOL: EXTERNAL PROVIDER
  [Model/API]

                    ┌── yes ──▶ [Human approval]
[Check risk] ──▶ ◇
                    └── no  ──▶ [Auto continue]

Exactly one outgoing path
should be selected
for a given token.

Use when:
  mutually exclusive conditions.

Do not use parallel gateway
to represent alternatives.

                 ┌──▶ [Retrieve internal knowledge] ──┐
[Prepare task] ─▶ ✚                                  ✚ ─▶ [Synthesize]
                 └──▶ [Fetch external evidence] ─────┘

Split:
  activates all branches.

Join:
  waits for all active branches
  arriving at that synchronization point.

Use when:
  branches are independent
  and all are required.

                  ┌── message: approval received ──▶ [Continue]
[Wait] ────────▶ ◇
                  └── timer: 24h elapsed ──────────▶ [Escalate]

The gateway does NOT inspect data.
It waits for competing events.

This is ideal for:
  human response vs timeout
  external callback vs deadline
  webhook vs cancellation

                     boundary timer
                          ◷
                          │
                          ▼
                 ┌─────────────────┐
sequence ───────▶ │ Wait for Human  │ ───────▶ approved
                 └─────────────────┘
                          │
                          └────────▶ timeout escalation

Interrupting boundary event:
  cancels attached activity.

Non-interrupting boundary event:
  starts side path
  while activity continues.

Use for:
  timeout
  error
  escalation
  message
  compensation-related handling

[Prepare action]
      ↓
[Create approval task]
      ↓
◇ event-based
 ├── message: APPROVED
 │      ↓
 │   [Execute action]
 │
 ├── message: REJECTED
 │      ↓
 │   [Cancel / revise]
 │
 └── timer: SLA EXPIRED
        ↓
     [Escalate / expire]

Important:
  process state is durable;
  worker need not stay alive;
  approval carries exact frozen operation;
  late approvals are checked against current state.

SHORT:
[Call API] → [Use result]

LONG:
[Submit job]
    ↓
[Wait callback]
  ├─ message success → [Consume artifact]
  ├─ message failed  → [Handle failure]
  └─ timer deadline  → [Cancel / fallback]

Process:
  reserve hotel
  reserve flight
  charge card

If later step fails:
  may need compensation:
    cancel hotel
    cancel flight
    refund

Compensation means:
  execute business reverse action
  for already completed side effect.

It is NOT:
  database transaction rollback
  guaranteed exact reversal
  automatic for every task.

Each action needs:
  compensability semantics
  operation identity
  current-state checks.

START: message "new task"
  ↓
[Authenticate / create run]
  ↓
[Formulate task]
  ↓
◇ XOR: evidence required?
  ├─ no ───────────────────────┐
  │                            │
  └─ yes                       │
       ↓                       │
   [Retrieve evidence]         │
       ↓                       │
   ◇ XOR: sufficient?          │
       ├─ yes ───────────────┐ │
       └─ no                 │ │
            ↓                │ │
        [External research]  │ │
            ↓                │ │
            └────────────────┘ │
                              ↓
                         [Generate answer]
                              ↓
                         [Verify result]
                              ↓
                     ◇ XOR: verification
                     ├─ PASS → [Commit output] → END
                     ├─ REVISE → [Revise] ─────┐
                     │                         │
                     └─ HIGH RISK              │
                           ↓                   │
                      [Human approval]         │
                       ◷ timeout               │
                       ├ approved →────────────┘
                       ├ rejected → END rejected
                       └ timeout → END escalated

START:
  webhook OR scheduler

        ↓
[Discover changes]
        ↓
[Fetch source]
        ↓
[Parse / extract]
        ↓
◇ XOR: parse valid?
  ├─ no → [Quarantine / retry policy]
  └─ yes
       ↓
   [Persist source version]
       ↓
   [Update index]
       ↓
   [Write provenance]
       ↓
   [Publish ingestion completed]
       ↓
END

SEPARATE TIMER PROCESS:
  nightly reconciliation
       ↓
  [Compare source vs local checkpoint]
       ↓
  [Repair missed updates]

[Prepare exact operation]
  ↓
[Persist operation_id + immutable args]
  ↓
[Create approval request]
  ↓
◇ event-based
  ├─ APPROVED
  │    ↓
  │ [Re-check permission / current state]
  │    ↓
  │ [Execute once]
  │    ↓
  │ [Verify outcome]
  │    ↓
  │ END success
  │
  ├─ REJECTED
  │    ↓
  │ END rejected
  │
  └─ TIMER EXPIRED
       ↓
    [Expire approval]
       ↓
    END expired

Late approval after expiry:
  ignored/rejected by state check.

BPMN WORKSHEET
=========================================================

PROCESS NAME
→

PURPOSE
→

START EVENT
[ ] none
[ ] message
[ ] timer
[ ] signal
Other:
→

END STATES
1.
2.
3.

PARTICIPANTS / POOLS
1.
2.
3.

LANES / RESPONSIBILITIES
1.
2.
3.

---------------------------------------------------------

HAPPY PATH

1.
2.
3.
4.
5.

---------------------------------------------------------

DECISIONS / GATEWAYS

Gateway:
[ ] XOR
[ ] AND
[ ] OR
[ ] Event-based

Condition/event:
→

Branches:
→

Join behavior:
→

---------------------------------------------------------

WAITS

Human wait:
→
Resume message:
→
Timeout:
→

External callback:
→
Correlation key:
→
Timeout:
→

---------------------------------------------------------

ERRORS

Task:
→

Retryable errors:
→

Permanent errors:
→

Retry count/deadline:
→

Fallback:
→

---------------------------------------------------------

SIDE EFFECTS

Consequential action:
→

operation_id:
→

Can retry safely?
→

Compensation available?
→

Cancellation semantics:
→

---------------------------------------------------------

SUBPROCESSES

Reusable subprocess:
→

Long-running subprocess:
→

---------------------------------------------------------

STATIC CHECK

[ ] every path starts from valid start
[ ] every path reaches end or durable wait
[ ] no sequence flow crosses pools
[ ] all waits have wake-up events
[ ] XOR conditions are exclusive/default exists
[ ] parallel joins cannot deadlock
[ ] consequential retries are idempotent
[ ] timeout/error path exists where needed
[ ] late message handling defined
[ ] diagram maps to real runtime state

You are assisting with BPMN process modeling.

1. Define process scope, start and terminal outcomes.
2. Identify participants as pools and responsibilities as lanes.
3. Build the happy path using activities and sequence flows.
4. Distinguish:
   - sequence flow inside participant;
   - message flow between participants.
5. Use explicit gateway semantics:
   XOR = one branch,
   AND = all branches,
   OR = one or more,
   event-based = whichever event occurs first.
6. Model waits explicitly with message/timer events.
7. Model human approval as a durable wait state.
8. For long external jobs:
   submit → wait callback → timeout/failure/success.
9. For every task with external side effects:
   define idempotency/operation identity,
   retry class,
   cancellation semantics,
   compensation if available.
10. Add boundary events for timeout/error where material.
11. Do not invent missing SLA, approval rule or business condition;
    mark it as a requirement gap.
12. Check every path reaches:
    terminal outcome
    OR explicit durable wait.
13. If functional decomposition rather than timing is the main question,
    recommend IDEF0 instead.
14. If model is intended to execute,
    map every activity/event to a concrete runtime contract.

START
  ↓
DEFINE PROCESS SCOPE
  ↓
WHO PARTICIPATES?

POOL A
POOL B
POOL C

within pool:
  lanes = responsibility

between pools:
  MESSAGE FLOW

within pool:
  SEQUENCE FLOW

────────────────────────────────────────

PROCESS ELEMENTS:

EVENT
  something happens

TASK
  work happens

GATEWAY
  flow decision / synchronization

SUBPROCESS
  grouped process behavior

DATA OBJECT / STORE
  process data context

────────────────────────────────────────

GATEWAYS:

XOR
  exactly one path

AND
  all paths

OR
  one or more

EVENT-BASED
  whichever event happens first

────────────────────────────────────────

WAITING:

human approval
external callback
timer
message
signal

WAIT IS STATE.

A WORKER
DOES NOT NEED TO STAY ALIVE.

────────────────────────────────────────

FAILURE:

service task
  ↓
boundary error
  ├─ transient → bounded retry
  ├─ fallback
  └─ permanent → fail path

timer:
  task waits too long
  ↓
timeout path

business rejection:
  separate from technical error

────────────────────────────────────────

CONSEQUENTIAL ACTION:

prepare exact operation
  ↓
freeze arguments + operation_id
  ↓
approval if required
  ↓
execute once
  ↓
verify
  ↓
if later failure:
  compensation only if defined

────────────────────────────────────────

AI WORKFLOW EXAMPLE:

message start
  ↓
formulate
  ↓
need evidence?
  ├─ no
  └─ yes → retrieve
             ↓
          sufficient?
          ├─ yes
          └─ no → external research
  ↓
generate
  ↓
verify
  ↓
PASS?
  ├─ yes → commit → END
  ├─ revise → revise loop
  └─ high-risk → human wait
                    ├─ approved
                    ├─ rejected
                    └─ timeout

────────────────────────────────────────

WITH OTHER METHODS:

IDEF0
  what functions exist?

BPMN
  how do they unfold over time?

TOC
  where does flow constrain throughput?

KT
  why did a process step deviate?

TRIZ
  how can process conflict be redesigned?

DURABLE WORKFLOW
  how does runtime persist/replay/wake?

QUEUES / BROKER
  how does work/message move?

CONTRACTS
  what exact payload crosses each boundary?

OBSERVABILITY
  what actually happened in each instance?

────────────────────────────────────────

THE CENTRAL BPMN QUESTION:

“WHAT EXACTLY HAPPENS
WHEN THE HAPPY PATH
DOES NOT HAPPEN?”

WHO WAITS?
FOR WHAT?
FOR HOW LONG?
WHAT WAKES THE PROCESS?
WHAT IF THE MESSAGE IS LATE?
WHAT IF THE TASK FAILS?
WHAT IF THE USER REJECTS?
WHAT IF TWO BRANCHES RUN?
WHAT IF ONE SIDE EFFECT
ALREADY COMMITTED?

WHEN THOSE ANSWERS
ARE EXPLICIT,
THE PROCESS
STOPS BEING
A BOX-AND-ARROW STORY
AND BECOMES
AN OPERATIONAL MODEL.