Portal contact challenge

The Lifecycle

The diagram summarizes the observed transition rows; declared edges without an observed writer remain outside the operational graph.

Transitions Explained

The challenge proves possession of a candidate contact’s e-mail address or phone number. It is separate from the signed candidate offer and from the eventual contact link.

Delivery occurs after the challenge is stored. Failure attempts to supersede that challenge; the design does not treat the provider send and database state as an atomic operation.

What Cannot Happen

An already linked member cannot open another matching challenge.

An exhausted challenge cannot verify; the member needs a replacement or the decline path.

Concurrency and Timing

Attempts lock their challenge row and transact accounting with verification/linking. Starting challenges supersedes currently visible rows before insertion, while member links check that another claim is absent. The inspected paths do not provide a shared contact/member lock or declared live uniqueness constraint, so simultaneous start and cross-member linking exclusion remain unknown. Failed delivery attempts to spend the created challenge.