From process specification → executable BPMN → system integration → failure recovery → measurable improvement
GSB-001 is a Gradensal Signature Build exploring how a manual business process can become an executable, observable, and measurable orchestration system.
The project uses a fictional insurance claims workflow to demonstrate:
- BPMN process modeling;
- Camunda 8 orchestration;
- Python job workers;
- legacy API integration;
- deterministic risk decisioning;
- human-in-the-loop review;
- incident diagnosis and recovery;
- batch process execution;
- measured workflow outcomes;
- deployment and customer handoff documentation.
All data is synthetic.
This is a local technical prototype, not a production insurance system.
Many workflow demos stop once the happy path works.
I wanted to explore a broader deployment question:
What does it take to move from a business process description to a working system that can integrate with external services, involve humans when necessary, fail visibly, recover operationally, and produce measurable evidence?
That became the Process Deployment Loop:
business process
↓
technical model
↓
working system
↓
observable failure
↓
measurable improvement
↓
operational handoff
A fictional insurance company manually reviews every incoming claim.
Baseline:
Claim Received
↓
Human Review
↓
Claim Completed
The prototype introduces orchestration and risk-based routing:
Claim Received
↓
Legacy Policy Lookup
↓
Risk Assessment
↓
Review Required?
/ \
/ \
Automatic Human Review
\ /
\ /
↓
Claim Completed
Routine claims can move straight through.
Claims requiring judgment remain human-controlled.
┌──────────────────────┐
│ Camunda 8 │
│ Process Orchestration│
└──────────┬───────────┘
│
┌─────────────────┴─────────────────┐
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ lookup-policy │ │ assess-risk │
│ Python Worker │ │ Python Worker │
└────────┬─────────┘ └────────┬─────────┘
│ │
▼ │
┌──────────────────┐ │
│ Legacy Policy API│ │
│ FastAPI │ │
└────────┬─────────┘ │
│ │
▼ │
┌──────────────────┐ │
│ Synthetic Policy │ │
│ Data │ │
└──────────────────┘ │
│
┌─────────────────┘
▼
┌──────────────────────┐
│ Review Required? │
└──────────┬───────────┘
│
┌──────────┴──────────┐
▼ ▼
Auto Process Human Review
│ │
└──────────┬──────────┘
▼
Claim Completed
See docs/architecture.md for the detailed system design.
Example process variables:
{
"claimId": "CLM-001",
"policyId": "POL-1001",
"customerName": "Sarah Chen",
"claimType": "vehicle",
"claimAmount": 1250
}The worker:
workers/lookup_policy_worker.py
calls:
GET /policies/{policy_id}
on the simulated legacy policy service.
Examples:
policyStatus
coverageLimit
deductible
riskTier
The worker:
workers/assess_risk_worker.py
calculates:
riskScore
riskReasons
reviewRequired
triageDecision
reviewRequired = false
→ automatic processing
reviewRequired = true
→ human review
Claims requiring judgment pause at the Camunda User Task:
Review Claim
The task is assigned and completed in Tasklist.
The current build does not use an LLM for the risk decision.
That is intentional.
The first objective was to prove that:
process orchestration
+
system integration
+
decision output
+
routing
+
human oversight
work predictably.
Deterministic rules make the prototype reproducible and easy to debug.
An AI-assisted decision layer can be introduced later without changing the fundamental orchestration pattern.
A working workflow is only part of the problem.
GSB-001 deliberately introduced an external integration failure.
The simulated Legacy Policy API returned:
HTTP 503 Service Unavailable
for a test policy.
The resulting sequence was:
Camunda
↓
lookup-policy worker
↓
Legacy Policy API
↓
HTTP 503
↓
JobFailure
↓
Camunda incident
The incident was inspected in Camunda Operate.
The failing dependency was tested independently, repaired, and verified.
The same process instance was then retried.
It recovered and continued to completion without:
redeploying BPMN
starting a replacement process
abandoning the original instance
Full write-up:
The baseline process requires every claim to be manually reviewed.
A controlled batch of 10 synthetic claims was executed through the improved workflow.
Total claims: 10
Manual reviews: 10
Automatically processed: 0
Total claims: 10
Automatically processed: 7
Human reviews: 3
Therefore, within this synthetic experiment:
Manual reviews avoided: 7
Manual-review reduction: 70%
Automatic-processing rate: 70%
Human-review rate: 30%
The calculation is reproducible through:
python -m metrics.calculate_metricsThe results apply only to this controlled synthetic experiment.
They are not claims about production insurance performance.
The build captures evidence across the deployment lifecycle.
Examples include:
assets/screenshots/01-auto-processed-claim.png
assets/screenshots/02-human-review-required.png
assets/screenshots/03-human-review-completed.png
assets/screenshots/04-integration-incident.png
assets/screenshots/05-incident-recovered.png
assets/screenshots/06-experiment-human-review-state.png
assets/screenshots/07-baseline-vs-improved-metrics.png
assets/screenshots/08-experiment-completed.png
Camunda 8 Run 8.9.21
Camunda Desktop Modeler
BPMN
Camunda Operate
Camunda Tasklist
Python 3.12.6
camunda-orchestration-sdk 9.0.1
FastAPI
Uvicorn
HTTPX
python-dotenv
Java 22.0.1
macOS
Apple Silicon / arm64
JSON
synthetic claims
synthetic policies
process-deployment-loop/
├── bpmn/
│ └── claims-triage.bpmn
│
├── workers/
│ ├── __init__.py
│ ├── lookup_policy_worker.py
│ └── assess_risk_worker.py
│
├── legacy_api/
│ ├── __init__.py
│ └── app.py
│
├── synthetic_data/
│ ├── policies.json
│ └── experiment_claims.json
│
├── metrics/
│ ├── baseline.json
│ ├── improved.json
│ ├── experiment-results.json
│ ├── summary.json
│ ├── run_experiment.py
│ └── calculate_metrics.py
│
├── docs/
│ ├── architecture.md
│ ├── deployment-playbook.md
│ ├── incident-report.md
│ ├── customer-handoff.md
│ └── stakeholder-brief.md
│
├── assets/
│ ├── screenshots/
│ └── videos/
│
├── tests/
├── .env.example
├── .gitignore
├── process_spec.md
├── requirements.txt
└── README.md
Detailed instructions are available in:
The normal startup sequence is:
cd /path/to/c8run
./start.shsource .venv/bin/activate
python -m uvicorn legacy_api.app:app --reload --port 8000python -m workers.lookup_policy_workerpython -m workers.assess_risk_workerpython -m metrics.run_experimentpython -m metrics.calculate_metricsExplains the components, process flow, integration boundaries, decision layer, human oversight, and measurement architecture.
Provides the reproducible local setup and operating procedure.
Documents the deliberate HTTP 503 integration failure, diagnosis, repair, retry, and recovery.
Explains the delivered system from an ownership and operational-handoff perspective.
Summarizes the problem, solution, experiment, and limitations for a non-technical audience.
GSB-001 is deliberately scoped as a local prototype.
A production implementation would need additional capabilities including:
authentication
authorization
secret management
durable databases
production observability
structured retries and backoff
idempotency
monitoring and alerting
CI/CD
environment promotion
data governance
privacy controls
auditability
business-rule governance
service-level objectives
disaster recovery
If probabilistic AI is introduced, the system would also need:
model evaluation
confidence handling
fallback behaviour
version tracking
AI observability
cost monitoring
human escalation
GSB-001 is intentionally broader than a workflow diagram.
It demonstrates the complete loop:
business requirement
↓
process specification
↓
executable BPMN
↓
external integration
↓
automated workers
↓
human oversight
↓
failure observation
↓
operational recovery
↓
measured result
↓
handoff
The central idea is simple:
A process is not truly deployed when the diagram runs once. It is deployed when the system can execute, integrate, fail visibly, recover, be measured, and be understood by the next person responsible for it.
Gradensal Signature Builds are end-to-end, role-aligned technical systems built from real industry requirements.
Each build turns a problem statement into:
working software
+
documentation
+
measurable evidence
+
reproducible public artifacts
GSB-001 is the first build in the series.