Automated Production Edit-Conflict False-Positive Prevention Automation: Flagged Against Itself

An optimistic-lock check — comparing a row's own last-modified marker against the version a person started editing from — is a genuinely correct, widely used way to prevent one person's save from silently overwriting another's unseen changes. Its entire premise depends on one assumption holding: that the marker being compared only moves when a change worth flagging actually happened. The moment ANY other kind of write — the system's own background process, an automated status update — also advances that same marker, the check stops being able to tell the difference between "a colleague changed this" and "nothing a person needs to know about happened at all," and starts producing a warning that is technically accurate about the timestamp and completely wrong about what it implies.

Atlas's own background production step is designed to work independently, quietly filling in AI-generated content and a status update for each individual asset in a multi-asset item as that asset finishes — deliberately not routed through the same save path a human editor uses, since it is not a human edit and should not require one. The gap was that this background step still updates the row's own general last-modified timestamp, because every database write naturally does, and the editor's own conflict check had no way to distinguish that kind of write from a person's own deliberate edit — both moved the identical field.

Measured on a real, specific item: the background production step's last write landed about one minute before a human editor's own save attempt was rejected with a conflict warning. The system was, in a very literal sense, accusing itself — the only actual change since the editing screen opened was the automation's own, expected, correct behavior, and the human editor had no way to know that from the warning alone.

The fix introduces a second, dedicated timestamp column, stamped ONLY by the specific save path a genuine human edit goes through. The general last-modified timestamp is left completely unchanged in behavior — it still advances on every write to the row, exactly as it always did, because other parts of the system still legitimately depend on knowing when a row was touched at all. What changes is which column the conflict check itself compares against: now the human-only timestamp, a field the background production step has no reason to ever write to and does not. A background write can still update the item's content and status freely, in parallel with a person editing an unrelated field, without ever triggering a false accusation against a process that was never a competing editor to begin with.

A team member opens a multi-asset content item to adjust a brief while its remaining pieces are still finishing production in the background. Before the fix, one of those pieces finishes generating a minute later, advancing the item's general timestamp — and when the team member tries to save their own, unrelated edit moments after that, the system rejects it with "someone else changed this," even though no other PERSON touched the item at all. After the fix, the identical background completion updates the general timestamp exactly as before, but the conflict check compares against the human-only timestamp instead — finds no actual human edit happened in between — and the team member's save goes through without a false warning.

Centriu Atlas's editor now distinguishes a genuine human edit from its own background production system's writes when deciding whether to warn about a conflict — closing a gap where the system's own automated content production could trigger a false "someone else changed this" warning against a human editor, measured occurring about a minute apart on a real item.

This automation governs specifically whether Atlas's own editor correctly distinguishes a human edit from its own background system's writes when checking for a conflict — it does not change how the background production step itself generates content, and it does not remove genuine conflict warnings between two actual people editing the same item.

Reusing a single, general last-modified field for an edit-conflict check is a completely reasonable default right up until something OTHER than a human edit legitimately needs to write to the same row — at which point the check can no longer tell the two apart, and starts producing warnings that are timestamp-accurate and meaning-wrong. Centriu's fix treats "a human made an edit" as its own, specifically tracked event, separate from "this row was written to for any reason at all" — the distinction an optimistic-lock check actually needs to be trustworthy.