ASHLR NEWSROOM: CONCURRENCY QUALIFICATION
Publisher: Ashlr.AI (AshlrAI, Inc.)
Qualification date: September 18, 2026
Public field note: https://ashlr.ai/news/testing-duplicate-work-in-an-ai-newsroom

METHOD
The application SQL ran against an isolated Neon PostgreSQL database using four
concurrent connections. Simultaneous transactions returned four distinct backend
process IDs. The fixtures used a reserved 1900-01-01 period, random identifiers,
explicit synthetic story labels, and six @example.invalid recipients. The harness
used deliberate transaction locks as well as competing asynchronous queries.

OBSERVED RESULTS
1. Four distinct concurrently connected PostgreSQL backends were verified.
2. One collection claimant won across four connections. An old lease could not
   save evidence; the current lease could.
3. One generation claimant won. Four completion attempts committed one story and
   one completed run; a later replay owned no run and inserted no story.
4. Competing confirmations consumed each token once. While the first creation
   transaction held the edition insert, another creation could not replace it.
   A fresh lookup recovered the same edition. Its original snapshot and six
   eligible recipient records remained unchanged.
5. A worker holding three delivery row locks and a second worker using SKIP LOCKED
   claimed disjoint sets of three. A subsequent claim returned no pending rows.
6. Duplicate synthetic delivery-event updates raced the send-receipt update.
   One event persisted. The final delivery state was delivered, and a stale
   completion could not downgrade it or make it claimable again.

CLEANUP AND BOUNDARIES
The qualification run removed its own synthetic records and verified their
absence. No model, email, or other provider calls were made. The test did not use
the production database. These results were recorded by Ashlr, not independently
certified. The public report is a readable summary of the recorded run; it omits
operational database identifiers and is not a provider delivery receipt.

The test does not establish throughput, latency, behavior under every database
failure, model output quality, source accuracy, live cron execution, or inbox
delivery. Database ownership and replay controls are not an exactly-once guarantee
for an external API. An ambiguous external send still requires reconciliation.

REPRODUCTION
Download reproduction-kit.zip from the same directory and read README.md. It
contains the harness, actual SQL modules, required schema migrations, and guarded
setup instructions. Use an empty isolated Neon validation database. Review the
code before execution. SHA256SUMS.txt identifies the downloadable artifacts.

PostgreSQL explains row skipping for queue consumers and conflict/snapshot
visibility in its own documentation:
https://www.postgresql.org/docs/current/sql-select.html#SQL-FOR-UPDATE-SHARE
https://www.postgresql.org/docs/current/transaction-iso.html