Original field data · 14 August 2026
4 scheduled posts produced 6 provider objects. The total looked right. The wave was not.
A 36-minute distribution wave crossed Korean Threads, Japanese Threads, Korean Facebook, and English Bluesky. Six provider objects were expected and six appeared. But one Japanese reply was missing while one Korean reply was duplicated, so the matching total concealed two different failures.
Download the observed rows as CSV. Provider-original links are included so the public objects can be inspected independently. Engagement and conversion are intentionally excluded: this dataset measures publication outcomes, not audience response.
The four channel rows
| Channel | Terminal state | Expected structure | Observed structure | Rendered link | Provider evidence |
|---|---|---|---|---|---|
| Korean Threads | Published | 1 root + 1 reply | 1 root + 2 duplicate replies | Clickable | Root, reply A, reply B |
| Japanese Threads | Failed after root write | 1 root + 1 reply | 1 root + 0 replies | No carrier | Root |
| Korean Facebook | Published | 1 root | 1 exact root | Clickable | Post |
| English Bluesky | Published | 1 root | 1 exact root | URL text, anchor absent | Post |
Provider object difference and clickable carrier
Observed minus expected objects across four scheduler rows. The net difference is zero, but the +1 duplicate and −1 missing object cancel each other out.
- Korean Threads Yes
- Japanese Threads No
- Korean Facebook Yes
- English Bluesky No
Why the aggregate passed while the wave failed
The two Threads rows were each designed as a root plus a reply. Facebook and Bluesky each needed one root. That made six intended provider objects. Korean Threads created one extra reply; Japanese Threads created one reply fewer than planned. The errors cancelled out numerically:
expected: 2 + 2 + 1 + 1 = 6
observed: 3 + 1 + 1 + 1 = 6A dashboard that checks only the wave total could report a perfect object count. A row-level ledger exposes the real state: one duplicate-write incident, one partial provider write, one clean clickable Facebook result, and one exact Bluesky post whose URL-shaped text was not a clickable anchor.
Three checks that prevented an unsafe retry
- Keep stable content and job IDs. The Japanese Threads job ended with
provider_unavailable, but its public root already existed. Recreating the whole item could have duplicated that root. - Count structure, not only objects. Root and reply roles matter. Six objects in the wrong rows are not equivalent to six intended objects.
- Inspect rendered links. The Bluesky text matched exactly, yet the provider page exposed no destination anchor. Text equality did not create an acquisition path.
Method and limits
The four scheduler rows were created once and scheduled between 22:25 and 23:01 KST on 14 August 2026. After terminal execution, the same content and job IDs were read again. Public provider originals were then inspected for account, body, root/reply structure, duplicate objects, and rendered link behavior. No manual retry, recreation, edit, deletion, synthetic click, or paid distribution was used.
This is a field observation of one distribution wave, not a platform failure-rate estimate. Unsupported metrics remain unknown. A public object or clickable carrier does not prove a visit, signup, or conversion.
Use the evidence before deciding to retry
For a single post, the browser-local proof checker turns the same evidence into one of four conservative decisions: confirmed, reconcile before retry, wait, or hold unknown. For implementation details, see the ANKK documentation.
See how ANKK tracks scheduled content through terminal provider proof.