Business Logic

The instruction

Business logic is treated as a security surface, not as a correctness concern that happens to have security consequences. Exact-once behaviour, state machines, accounting truth, retries, and race windows are all in scope.

Use SecHelix to audit business logic, payment/accounting truth, and concurrency.
Model state transitions and invariants for create/update/cancel/refund/approve/claim/redeem/
withdraw/transfer/purchase/webhook operations.
Test replay, idempotency, duplicate execution, partial success, late callbacks, negative/overflow
values, price tampering, stale state, TOCTOU, and double-spend windows in a safe environment.

The combinations that hurt

These defects rarely live in a single function. They live between two individually valid actions, which is why a per-file scan does not find them.

refund + late provider success
delivery + cancellation
cost edit + finalized payout
two admins + one assignment
timeout + retry + delayed callback
partial fulfillment + "mark full"
seller A + seller B's object

Transition questions

For every money, inventory, or fulfillment flow, the workflow enumerates transitions and asks:

• Can the same action happen twice?
• Can a terminal state be reopened incorrectly?
• Can a partial success be represented as full success?
• Can refund and delivery race?
• Can cost edits rewrite finalized payout truth?
• Can a failed insert occur after a destructive delete?
• Can an external timeout later succeed?
• Can retry buy or deliver twice?
• Can a user replay a stale preview?
• Can a seller act on another seller object?
• Can null or unknown be coerced into zero, false, or safe?
• Can a client-provided status overrule stored truth?
• Can an admin UI success message hide a failed second write?

What to record per transition

Preconditions

The states from which this transition is legal.

Actor

Which effective subject may trigger it, including services and provider callbacks.

Source of truth

Which system owns the answer when two records disagree.

Side effects

External provider calls, ledger writes, inventory decrements, notifications.

Idempotency identity

The key that makes a repeat of this transition a no-op.

Retry behaviour

What a client, a queue, and a provider each do on failure.

Terminal behaviour

Whether the state can be left, and by whom.

Partial-success behaviour

What is persisted when the second write fails.

Rollback and reconciliation

How divergence is detected and repaired.

Races and exact-once

The race and idempotency lane owns duplicate callbacks, retries, process crashes, timeouts, outcome-unknown handling, TOCTOU, locks, idempotency keys, duplicate writes, stale preview and apply, and concurrent admins.

• Deterministic reproduction beats load generation. Uncontrolled load is not a verification method.
• Concurrency tests use harmless fixture state in an isolated local environment.
• The canonical fix is usually one exact-once merge rather than several dedupe rules, or an atomic operation rather than delete-then-insert.
• Preserve historical, accounting, and audit evidence during repair. A fix that rewrites ledger history is not a fix.