process_spec.md

GSB-001 — Process Deployment Loop

Business Scenario

A fictional insurance company processes incoming claims.

Today, every claim is manually reviewed.

This creates unnecessary manual work because many claims are low-risk and could move through the process automatically.

The goal is to build an executable workflow that:

1. receives a claim;
2. retrieves policy information from a legacy system;
3. evaluates the claim risk;
4. automatically routes low-risk claims;
5. sends higher-risk or uncertain claims to human review;
6. completes the process;
7. records enough information to compare the baseline process with the improved process.

Baseline Process

Every claim requires human review.

Claim Received
      ↓
Human Review
      ↓
Claim Completed

Improved Process

Claim Received
      ↓
Legacy Policy Lookup
      ↓
Risk Triage
      ↓
     Decision
     /      \
Low Risk   Review Required
   ↓             ↓
Automatic     Human Review
   \             /
    \           /
      ↓
Claim Completed

Integration Requirement

The workflow must call a simulated legacy policy system.

The legacy service will be implemented as a local FastAPI application.

Failure Scenario

At least one synthetic claim must deliberately trigger a legacy API failure.

The project must demonstrate:

failure
→ diagnosis
→ correction
→ retry
→ successful recovery

Human Oversight Requirement

Claims that meet either of these conditions should require human review:

• elevated risk;
• low-confidence or uncertain automated assessment.

Measurement Goal

Compare:

Baseline

All claims require human review.

Improved

Only claims requiring human judgment should be routed to human review.

The experiment should report:

• total claims;
• baseline manual reviews;
• improved manual reviews;
• reduction in manual review;
• failed integration attempts;
• recovered process instances.

Constraints

• synthetic data only;
• local development environment;
• no production credentials;
• no production insurance data;
• workflow must remain understandable and reproducible;
• AI should assist the workflow, not obscure the business logic.

Success Criteria

GSB-001 is successful if:

1. the BPMN workflow deploys to Camunda;
2. synthetic claims can be started as process instances;
3. Python workers complete automated tasks;
4. the legacy API integration works;
5. a deliberate integration failure can be observed and recovered;
6. human review is visible in the workflow;
7. baseline and improved metrics can be compared;
8. another developer can reproduce the build from GitHub.

Build Principle

This Signature Build follows the progression:

business process
↓
technical model
↓
working system
↓
observable failure
↓
measurable improvement
↓
customer handoff

The project should begin from the business requirement rather than from implementation code.

That means separating:

WHAT the business needs

from:

HOW we implement it

The purpose of GSB-001 is to demonstrate the ability to translate an ambiguous business process into an executable, observable, measurable, and reproducible technical system.