Transaction reconciliation and assertion layer

The challenge

Incoming and outgoing transactions carried complex expected behaviour. The team needed those expectations made explicit before launch so mismatches could be investigated and system decisions understood.

What Grail built

We mapped the existing .NET system, wrote down the rules governing transaction flows, and implemented reconciliation paths and assertions around incoming and outgoing behaviour.

Impact

The system was mapped, transaction rules became explicit checks, reconciliation paths were covered, and an assertion layer was added for investigation and operational control.

How the work progressed

We started by mapping what the existing platform was expected to do. Those expectations became explicit rules, reconciliation paths and assertions that the team could inspect and test before launch.

1. The existing transaction paths and their dependencies were mapped.
2. Expected behaviour was written as explicit transaction rules.
3. Incoming and outgoing events were checked against those rules.
4. Mismatches were surfaced with the context needed for investigation.
5. The team could review the control layer before platform launch.

Control and review

The control points were specific to the system, so delivery could move faster without taking sensitive decisions away from the people responsible for them.

• Transaction expectations are written down rather than left implicit.
• Assertions make mismatches visible before they become silent failures.
• Investigation context remains available for operational review.

What shipped

The implementation centred on these delivered pieces:

• Map of the existing transaction system.
• Explicit rules for expected transaction behaviour.
• Incoming and outgoing reconciliation paths.
• Assertions for detecting and investigating mismatches.
• Operational controls for pre-launch review.