Returns need their own safety model

What the public implementation shows

SIPS Connect has separate incoming and outgoing return handlers, return builders and parsers, retry handling, return DTOs, and tests for duplicate and retry behavior.

The return flow references original transaction state while retaining its own identifiers, reasons, statuses, and response contract. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA return is a new controlled instruction whose authority comes from an original transaction.

The decision behind the mechanism

Separating return orchestration makes original-transaction validation and multi-return prevention first-class financial controls.

A generic transfer implementation can return the wrong transaction, reverse twice, or lose the relationship between the return and its original payment. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Require a resolvable original transaction.
• Reserve a distinct return identity before processing.
• Prevent multiple successful returns against the same value.
• Replay prior return outcomes for duplicate instructions.

How the control should be operated

Operations should be able to trace original transaction ID, end-to-end ID, return ID, reason, retry history, and terminal outcome as one linked record.

That lineage supports investigation and reconciliation without treating return traffic as ordinary negative value. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.