docs(design): scheduled-publish redesign — sortAt + a pending bitmap (PROPOSAL)

[JustMaier]

Docs-only. A PROPOSAL, not a decision — Justin's, 2026-07-15. Nothing benchmarked, nothing scheduled.

The design

Write Image."sortAt" at schedule time (future for scheduled posts). BitDex holds a pending bitmap it clears locally on a sweep, and the engine — not the caller — excludes it from every query.

The consequence that matters: publish sends BitDex nothing at all. No op crosses the wire at Tf. There is no batch to apply, lose, or verify.

What it answers

"It seems like it's all tied to the queryOpSet, right? Or have we been running into issues unrelated to that as well?"

It is not all queryOpSet. Two distinct data families, plus a third that has cost as much engineering time:

• A — fan-out. One PG row must become N BitDex writes and BitDex works out which N. queryOpSet ships a query, resolves it against its own index at apply time, and never checks what it matched. Confirmed live: 13 of 20 images stuck at publishedAt = 0, invisible, none self-healed at 5.8h — FD #69397's report verbatim. Same family: DocCache evicted by Post id rather than image slots; fan-out dedup collapse; Post fan-out firing pre-insert.
• B — deferred/activation. A special state that isn't a bitmap, isn't durable like the rest, and needs an event replayed at an exact instant. The ~49.7k orphan loss, fix(ops): publish fan-out reaches deferred slots (reschedule-drop) #313 reschedule-drop, the ~1/320 activation-miss, and the entire verifier apparatus built to detect its failures.
• C — instrument failures. The verifier raised false orphans for months; no data was ever lost in that class. And three adversarial passes over PR fix(activation): gate verification on an observed publish (v1.1.49, step 1 of 3) #323 found zero defects in the design and ~10 in the prose around it.

The shared root — and why the design works

Both A and B are a write resolved or replayed LATER, against state that has MOVED, with NO RECORD of what it was supposed to affect. Neither has an error path, because neither knows what correct looks like.

The cure, general: make it a durable VALUE that can be compared, not an EVENT that must fire correctly.

A value can be diffed against the source and repaired. "Did an op fire correctly three hours ago?" has no answer — only consequences. sortAt is a value. publishedAt-via-queryOpSet is an event.

What it deletes

Family B entirely — no batch ⇒ no orphan class. The deferred map (durability domain #4) becomes a bitmap. isPublished. And the whole verifier: #320, #321, PR #323, the barrier, publish_seq, VerifyGate, the ring. All of it verifies a batch that would not exist.

What it does NOT fix — stated so it isn't forgotten

• queryOpSet survives for availability, postedToId, and every other post-level field. One caller removed, not the pattern.
• The fan-out moves rather than disappears — but stops being time-critical, and a stale field is detectable where a missed event isn't.
• A missed reschedule still publishes early — same class, now auditable.

Caveats that travel

n = 3 events. An anecdote, not a rate. The denominator (15,942 images / 3,593 posts, no LIMIT) is the only solid number. Four hypotheses were refuted by one measurement each, and the one true partial (13/7) is n=1 and unexplained — no rule named off it. The hot-path ANDNOT cost is unmeasured, and unmeasured premises died four times in one evening on exactly this subject.

🤖 Generated with Claude Code

[JustMaier]

Closing — not wanted as a PR. Design doc kept locally instead, per Justin.