A pacs.002 role is not a minor detail

What the public implementation shows

The ISO package defines a Pacs002Role enumeration and separate status parsers, builders, and handlers for incoming reports and transaction status conversations.

Role resolution sits between raw pacs.002 content and the local state transition it is allowed to trigger. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleStatus interpretation requires message role, not only message type.

The decision behind the mechanism

The implementation distinguishes a response to payment initiation from other status exchanges before mapping the ISO status into participant state.

Treating every pacs.002 as interchangeable can complete the wrong conversation or apply a valid status to the wrong local workflow. 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.

• Resolve conversation role before state mutation.
• Validate identifiers expected for that role.
• Differentiate status report and status inquiry flows.
• Test the same status code in each supported direction.

How the control should be operated

Message stores and dashboards should retain definition identifier, direction, role, transaction identity, and the transition produced.

That context makes status-related incidents reconstructable instead of leaving only a final code. 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.