# Why a motor claim is a durable case, not an RPA script

Canonical: https://stevenmoriasi.com/blog/insurance-operations-automation-platform
By [Steven Moriasi](https://www.linkedin.com/in/steven-moriasi/).
Source: https://github.com/steven-moriasi/insurance-operations-automation-platform
Date: 2026-09-21

## Context

A motor claim can stay open for days: policy verification, evidence, triage, assessment, approval, settlement, and reconciliation. A CRUD portal records the latest status. An unattended RPA script can click a screen. Neither gives you durable timers, safe retry, compensation, or an audit of who decided when a dependency was down.

[Insurance Operations Automation Platform](https://github.com/steven-moriasi/insurance-operations-automation-platform) is a synthetic Java/Spring reference for that gap. Motor claims are the deepest journey; renewal and intermediary onboarding reuse the same case and workflow primitives.

## Decision

Spring Boot services own business state and authorization. Temporal owns process execution, timers, signals, and recovery. The React application talks only to a web BFF. Python automation and an RPA work-queue contract perform bounded tasks; they do not become the system of record. PostgreSQL stores the case. A synthetic MySQL policy store is an explicit legacy boundary.

first notification of loss → policy verification → evidence → officer triage → authority-based approval → settlement instruction → reconciliation

Human decisions are workflow signals. Activities are idempotent where retry can occur. Incoming callbacks are correlated and amount-checked. Failed deliveries become an operator-visible dead letter, not a silent success.

## What I rejected

Hiding the process in UiPath (or a local robot) so the claim exists only as a queue item, and exposing each Spring service to the browser with a shared JWT. The first makes recovery a desktop problem. The second makes RBAC a UI suggestion.

## Failure scenario

The legacy policy simulator is down, or a settlement callback arrives twice. The case row stays in PostgreSQL. Temporal waits, retries the activity, or escalates. A duplicate callback matches the idempotency key and does not create a second payment. The Python worker can fail; the claim does not.

## Evidence

`docker compose up --build` starts the React app, BFF, Spring services, Temporal, Python worker, PostgreSQL, MySQL simulator, Keycloak, MinIO, and observability. [Architecture](https://github.com/steven-moriasi/insurance-operations-automation-platform/blob/main/docs/architecture.md) and [delivery](https://github.com/steven-moriasi/insurance-operations-automation-platform/blob/main/docs/delivery.md) state what is simulated and that OpenShift/AWS definitions are not proof of a live deploy. Synthetic data only; not affiliated with an insurer and not a compliance certification.

Inspect: [Repository](https://github.com/steven-moriasi/insurance-operations-automation-platform) · [Architecture](https://github.com/steven-moriasi/insurance-operations-automation-platform/blob/main/docs/architecture.md) · [Run locally](https://github.com/steven-moriasi/insurance-operations-automation-platform#run-the-complete-local-system) · [Delivery](https://github.com/steven-moriasi/insurance-operations-automation-platform/blob/main/docs/delivery.md)

_—by [Steven Moriasi](https://www.linkedin.com/in/steven-moriasi/)_