Status inquiry is a recovery protocol

What the public implementation shows

SIPS Connect implements outgoing and incoming status handlers, status builders and parsers, a StatusOrchestrator, and scheduled timeout recovery.

The inquiry path references stored transaction evidence and uses a separate ISO conversation to determine the original outcome. 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 status inquiry closes uncertainty only when it is correlated to the original financial conversation.

The decision behind the mechanism

Status recovery is isolated from payment initiation so a retry cannot accidentally create another financial instruction.

A loosely correlated status response can update the wrong record, while resubmitting the original payment can duplicate value. 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.

• Build inquiry from the stored original identifiers.
• Persist every inquiry and response message.
• Validate response identity before state mutation.
• Escalate after a bounded recovery policy.

How the control should be operated

The recovery queue should show original identity, inquiry attempts, last response, next action, and the rule that permits terminal closure.

Uncertainty becomes an observable protocol with bounded ownership. 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.