How the social floor is run

Found by social-daily 2026-08-26 pulling the new 8.26 runs. Subjects read Code 5, Test 53, Cost 41, Speed 41, Tools 80, Effort 78, Process 94, Deliver 67 - composite 75.0. A Code axis of 5 alongside Process 94 and Effort 78 looks like a measurement failure rather than a model result, and it is the same shape as the already-open evals-zeroed-efficiency-root-cause task (pytest collection errors + a metric defaulting True). A TypeScript run is the obvious suspect for a Python-shaped collector. Verify before any post cites this run; the sibling circles__glm-5.3-flash-gemini-3.7-8.26.2026 reads Code 47 on the same day.

Found 2026-09-11 on circles__deepseek-deepseek-v4.1-flash-9.10.2026. The run was interrupted ~02:00Z after 12.8h and resumed with 'favur continue circles' (from [local path]). On resume meta.json set started_at = start_time = continued_at = 02:03:21Z, so total_time_seconds (5,437) and the board's '91 min' cover only the resumed segment; the true wall clock is ~14.3h (events.jsonl continuation_index 0: 13:14Z-02:03Z; 1: 02:03Z-03:34Z). Time is not scored (ci_scripts/metrics.py marks wall clock deprecated; concurrency_factor = request_time/total_time is stored in the DB, not scored), so composites are unaffected - but the published duration and concurrency_factor are wrong for every resumed run. Fix belongs in the harness's meta writer (keep the original started_at, record continued_at separately) or in meta_loader (derive time from the event span). Control: V4 8.18 is one segment and its 15,414 s matches its log span.

Found 2026-09-14 while replaying the rising topical gate over all 55,750 tier-3 authors. The vocabulary's own header warns that a term generic enough to trip ordinary engineering prose 'inflates every thread's count and destroys the gate's whole value', and several single words in it do exactly that. Measured hits on HN generalists with zero agent-dev subject matter: 'span' fired on 'An interactive tour of the spanning tree protocol' (observability); 'forget' on 'Aging Brains Blend Memories Together Instead of Just Forgetting Them' (context-memory); 'debate' on a post about a nation debating its name (orchestration); 'jail' on 'Read Dead Redemption 1 online had a cheater jail' (supervision). Blast radius is all three consumers, not just the new gate: relevance_check.py's three-aspect bar, the engine scorer's favur_aspect_depth ranking feature, and hn_read's topic pre-filter all read this one file. The rising gate works around it with a share threshold rather than a count, but that is a mitigation at one consumer, not a fix at the source. Suggested and NOT applied, because it needs the same must-not-fire measurement the evals-scoring stem got: lengthen the offenders ('span' -> 'span of work'/'tracing span', 'forget' -> 'forgetting curve'/'context forget', 'debate' -> 'debate agent', 'jail' -> 'jailing') and re-measure how many of the last 7d of items change aspect_count before adopting.

The 2026-08-28 rejection of ten pending tier 3->2 transitions was recorded as 'eight generalist HN submitters with zero agent-dev subject matter'. Replaying the new topical gate over their stored items on 2026-09-14 agrees for nine, and disagrees for one: [someone] holds 19 of its 50 most recent items on turf - OpenRouter routing ('I don't want to control routing, I want the model to...'), agent harnesses, AGENTS.md support, 'Recreating Minecraft Is Not a Benchmark', 'Headlong: A Microharness for Persistent Agents'. Its term tally is 13 x harness, 4 x evaluat, 3 x agent harness - substantive, not incidental. At the chosen 5/3/0.15 setting the gate PASSES it, so it will be re-proposed. That is the gate working rather than failing, but it was your reject, so the call is yours: confirm the pass (and it becomes a watched author next time the rule fires), or add the handle to the standing exclusion list if the rejection was about something the stored items do not show. The other nine are rejected by the gate and will stop reaching you.

Decision, not a bug: the CAUSE is closed and cannot recur (see the comment now in engine/bridge.py mention_external_id). Measured 2026-09-14: devto holds 992 path-style ids (bridge/Octolens-derived) against 8,733 numeric (native poller), and the newest path-style row is 2026-09-08 - Octolens went unavailable 2026-09-09, so nothing new is being doubled. What remains is 178 duplicate-URL groups, each holding exactly one removable path-style row. THE COST OF DELETING: those 178 rows carry 373 item_metrics rows and 490 scores rows, which is real measurement history that would go with them. Zero queued_items reference them, so nothing operator-facing breaks either way. THE COST OF KEEPING: devto counts read about 2% high wherever items are counted un-deduplicated, and any future per-platform total inherits the skew. NOT APPLIED - deleting stored rows is destructive and the trade is yours. If you want the cleanup, say so and it runs against a fresh backup with the exact id list printed first; if you want them kept, the honest fix is a note wherever devto items are counted. Supersedes the repair half of bridge-devto-dedup-id-mismatch.

Consolidates eval-new-models-0813 and eval-muse-spark-1.2-full-single (both closed 2026-09-14), rewritten as the act rather than the bookkeeping per [[an-unanswered-ask-is-a-badly-written-ask]] - both sat unanswered for weeks because they read as engine notes, not as a run request. RULED 2026-09-14: the RELEASE-WINDOW half of eval-new-models-0813 is retired. Those three models landed 2026-08-12/13 and the hype window [[model-release-reflex]] protects closed a month ago, so DeepSeek V4 Pro and Qwen3.8 are no longer news and no run is proposed for them on novelty grounds. What survives is not time-bound, because a MATCHED ARM does not expire ([[ab-arms-must-match]]). Two runs, each buying one comparison the board is built to make and currently cannot: (1) bytedance-seed/seed-2-1-turbo on circles - we ran and published its predecessor Seed 2.0 Code on the SAME spec (composite 57.8), so this is one vendor, one generation apart, same SoW. (2) meta/muse-spark-1.2 FULL single-model on circles - the board holds the Contributor/budget tier at 65.3, whose only same-spec neighbour is 1.1 from July, a different generation AND a different price tier, so the cheap-vs-full read is an unmatched arm today; the full run makes the Cost Efficiency axis do the one comparison it exists for at a ~12x input / ~21x output price gap. Each run is operator spend and operator-executed - Claude proposes, never starts one. Neither is urgent; both keep their value indefinitely. Do either, both, or neither.

Measured 2026-09-14 while closing engagement-tracking-gaps, off the LATEST item_metrics snapshot per item (not the ingest snapshot - that is the instrument the old audit read, and it understates every lane). X reach by source kind, n = items holding a view figure: ANCHOR n=1438 median 16,474 p90 129,022, 5.35% reach 250k. KEYWORD n=1640 median 6,567 p90 47,470, 1.95% reach 250k. TAG n=12,739 median 45 p90 1,584, 0.10% reach 250k. MENTION n=1330 median 54 p90 1,001, 0% reach 250k. The tag lane is the LARGEST X lane we run and its median post is seen 45 times - roughly 365x below an anchor-sourced one. Mention is the same shape. This does not by itself say kill the lane: tag/mention exist to catch LANGUAGE and to feed engine.pulse terms_rising, which is a question about what is being said rather than about reach, and a cheap post can still carry a rideable phrase. What it does say is that the tag lane cannot be read as a reach or virality signal, and that anything ranking targets by it is ranking near-dead content. The operator decision is whether the lane keeps earning its twitterapi spend at that median, and if so which consumer is allowed to read it ([[buy-the-signal-only-where-it-decides]]: name the consumer that CHANGES a decision). Claude computes, never selects ([[scripts-compute-never-select]]) - no lane was touched. Re-run: latest-snapshot join in the same shape, recorded here per [[a-logged-number-carries-its-query]]. CORRECTED 2026-09-14, same day, by the operator: *"X is the largest because its the platform that is generating the most posts for me to act on."* The framing above had the causation backwards - it read the tag lane's SIZE as a question to answer, when lane size is the EFFECT of X being the only surface whose candidates actually reached the operator (queued_items over 30 days: 45 X against 3 reddit, 3 devto, 0 hn - see [[measure-the-funnel-at-the-step-you-own]]). The MEASUREMENT stands and is unchanged: a tag-lane median of 45 views is real and the lane cannot be read as a reach signal. What is withdrawn is the implied question 'should this lane exist' - the honest question is whether its output ever reaches a decision, and that is the same question the merit-room funnel asks. Do not cut the lane on this row alone.

Measured 2026-09-14 while acting on the operator's correction that merit-room comments rarely get produced. The gate [[three-aspect-relevance-gate]] decides whether a thread earns a comment, and for two of the three merit rooms it is reading text that does not contain the thread. DEV.TO: ingest stores body=article['description'] - median 101 chars, p90 150, max 474 across 1,815 items in 7 days - so the gate judges a blurb. Result: 5 of 25,295 dev.to items (0.0%) ever reached full aspect depth, against reddit's 3.1%. HN: stories are link posts, median body 0 chars, so the gate sees a ~60-char title; the thread's substance is in comments, which we DO ingest but as separate items under the comment:* lanes, never joined to their parent story (story_id is present on 3,000 of 3,000 sampled comments and 99.6% of those parents are already in the store). REDDIT is the control and is fine - median body 787 chars, self-text included, 3.1% at full depth. This is [[a-partial-schema-is-not-the-schema]]: a verdict drawn from part of an artifact is a claim about the part. Note the gate is NOT wrong by design - relevance_check.py is documented to run over a FETCHED thread (--hn-json), which is the correct instrument; what is wrong is that the cheap stored proxy is what gets consulted, and it silently says reject. THREE OPTIONS, operator's call because two of them cost requests: (a) join HN comments to their parent story so a story's aspect depth is computed over its thread - costs nothing, the data is already stored; (b) fetch dev.to body_markdown from the single-article endpoint for items that pass a cheap pre-filter - costs one request per candidate against a 5-per-30s budget; (c) leave the stored depth as a weak hint and require a live relevance_check.py fetch before any merit-room comment decision - costs nothing mechanical but puts the work in the session every time. (a) is free and should probably happen regardless.