Accept the three DISPLAYED values as this run's confirmed Business DNA.

Order: a fast pre-check of the journey revision (409 journey_conflict), then the confirm RPC, which checks the revision again ATOMICALLY with the receipt transition (users row share-locked to commit) and writes edited fields locked and drifted unedited ones unlocked, then the journey records the business step. A 409 applies nothing.

Confirm is idempotent: the same values against an already-confirmed receipt are ok with no writes. So when the receipt committed but the journey step could not be recorded (after its retries), this returns 503 {ok: false, reason: "journey_write_failed"} rather than a success that did not advance setup; the client retries the same confirm once. That repair is honoured even when the revision has moved since (another tab autosaved): the pre-check and the RPC both accept an identical confirmed receipt whatever the revision, and the step is then recorded on the CURRENT journey.