Record the incoming message before business processing

What the public implementation shows

The PostgreSQL package exposes an IncomingRecorder and DedupOutcome model, with safety and concurrency tests around inbound handlers.

The recorder sits before CoreBank processing and returns a typed outcome that tells orchestration whether work is new, completed, or already in progress. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleThe first durable act should establish identity and evidence, not perform the financial side effect.

The decision behind the mechanism

Database uniqueness becomes the concurrency arbiter instead of an application-level check-then-insert race.

Two workers can both pass a pre-check and call the CoreBank before either writes the transaction record. 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.

• Insert under a database uniqueness constraint.
• Return a typed duplicate outcome.
• Keep completed response material for replay.
• Test simultaneous requests against the real persistence boundary.

How the control should be operated

The recorder outcome, constraint, message identity, and stored response should be visible in diagnostics without exposing sensitive payload data.

Duplicate arrival becomes a deterministic state transition rather than a timing accident. 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.