Published, but Not Shown
My social thread engine has a feature that picks one dev blog post and introduces it. The picker is pick_devlog_post, and its candidates are the latest six posts. The selection was simple. It uses the date as a seed, takes the remainder (modulo) by the number of candidates, and picks that post. You get a different post each day and the same post on any given day. It is reproducible and easy to test, so I did not question it for a long time.
But the rotation treated all six candidates the same. A post published this morning had the same weight as one from several days ago. Whether a fresh post made it into that day's thread depended on whether the date remainder happened to point at it. With a pool of size n, the odds were 1/n.
In your own auto-exposure pipeline, where in the code is the guarantee that what you just published shows up before what you published earlier?
In my case there was no such guarantee anywhere. "Publish and it gets featured" was an assumption that lived only in my head.
The Logic Was Fine; a Question Was Missing
The rotation itself had no bug. It cycled evenly as intended, and the tests passed. What was missing was the question "how new is this post?" Even rotation is the right tool for resurfacing an old backlog evenly. It is the wrong tool for getting a new post out right away. One function was serving both purposes, and the code handled only the first.
This kind of problem does not show up well on a dashboard. Something gets published every day, so the pipeline stays green. You only notice something is off when you look directly at what was published.
What Would You Do?
Would you add weight to new posts, or rotate only new posts for a set window?
Inside a Fresh Window, Rotate Only the Latest Batch
I chose the second option. The rule works like this:
- Posts published on the same day as the newest post form the "latest batch."
- If that batch is within FRESH_DAYS (3 days), the rotation candidates narrow to that batch only.
- After 3 days, it falls back to the original rotation over the latest six posts.
Weighting means more values to decide. A window needs only one number, FRESH_DAYS. If several posts go out on the same day, the same date-seeded rotation still runs within that batch.
I was careful about one more thing. The existing latest_devlog_posts function is used elsewhere and has tests on it. So I added a new _latest_devlog_dated wrapper that also returns dates, and left the existing function's signature unchanged. Because of that, test_content passed without any edits. The change touched one file, engine/content.py, with 24 lines added and 7 removed.
Self-Check
- Does your auto-exposure rotation take a candidate's publish time as an input, or does it only look at list order?
- Can you put a number on the chance that something published today gets shown today?
- Are "resurface the old backlog" and "show new items immediately" mixed into a single function?
The Honest Part
I have no data behind setting FRESH_DAYS to 3. I did not compare it with 2 or 5 days. I have not yet measured whether the intro threads perform any differently after this change. While the window is open, posts from the previous batch get pushed out of rotation, and I do not know how much that costs. Only one thing is certain. A post I just published now gets a candidate slot for as long as the window is open, instead of depending on the date remainder.