Tracking: reliability, restriction lifecycle, transparency, and ranking proposals

[cmdr-chara]

Purpose

This issue indexes 11 independent pull requests that address correctness, restriction lifecycle, transparency, and ranking behavior in the published codebase.

The changes are intentionally kept separate so each can be reviewed, accepted, revised, or rejected independently. This is not a request to merge them as one feature set. If external contributions are not in scope for this repository, please let me know and I will close or rework them accordingly.

Suggested review order

The smallest correctness-focused changes are the best starting point:

1. Require expiry for recommendation restrictions #10 — require bounded expiry for recommendation restrictions
2. Make restriction expiry effective at serving #12 — make expired restrictions stop affecting serving
3. Make missing DPP embeddings deterministic #21 — make missing DPP embeddings deterministic

Correctness and recovery

PR	Change	Scope / risk
#10	Require expiry for recommendation restrictions — validates a positive, bounded TTL for selected non-severe recommendation labels and repairs checked-in rules missing TTLs.	Focused rule validation. Production dynamic-rule configuration would need the same update.
#12	Make restriction expiry effective at serving — prunes expired post labels before policy evaluation and bounds stale author-label fallback caching.	Serving correctness; complements #10. The bounded fallback retains the existing fail-open behavior after expiry.
#20	Backfill candidates after late filtering — lets Phoenix refill from its ranked reserve after visibility/dedup filtering, while keeping generic pipelines opt-out by default.	Pipeline behavior change, isolated to Phoenix opt-in.
#21	Make missing DPP embeddings deterministic — replaces request-random fallback embeddings with stable ID-derived unit vectors.	Small deterministic bug fix; no change to normal embedded candidates.

Restriction lifecycle and transparency

PR	Change	Scope / risk
#11	Expose restriction scope in Under the Hood reports — adds structured historical restriction scope and impact metadata without exposing internal actors or rule identifiers.	Historical monthly reporting only.
#17	Bound and explain automated NSFW account labeling — uses published 10-of-20 original-post evidence over 60 days, a 7-day TTL, repost exclusion, and transparent reassessment metadata.	Policy change. The public repository does not expose the NsfwAdmin writer/remover path, so that flag cannot be fully migrated here.
#18	Remove credibility-based enforcement bypasses — removes follower-count, PageRank, and UserCred early exits from the checked-in enforcement rules.	Policy-sensitive. The GrowthBook source of truth must remain synchronized with baked YAML.
#43	Expose bounded live restriction status — reports current account labels and recent post restrictions through a bounded authenticated Under the Hood view.	Request-time transparency; limited to the newest 100 timeline edges and 30 days.

Ranking behavior

PR	Change	Scope / risk
#19	Make UserCred teleport prior verification-neutral — removes Premium/verification eligibility from the uniform PageRank prior while preserving engagement blending.	Material ranking-policy change.
#22	Smooth cold-start eligibility thresholds — replaces hard impression/follower cliffs with configurable decay bands while retaining zero-width legacy behavior.	Experimental ranking change.
#44	Default to gated dwell-regret ranking — changes the default value-model mode to the existing gated dwell/negative-feedback objective, with weighted mode retained as rollback.	High-impact product objective change.

Verification and limitations

• All 11 PRs currently show their available GitHub checks passing.
• Each PR documents the formatting, static checks, and focused regression coverage performed.
• Several published components omit Cargo/Bazel/Scala/Strato build targets or depend on internal generated types, so full compilation and integration tests cannot be run from this public snapshot. Those limitations are stated explicitly in the individual PRs.
• The patches were prepared with AI assistance (Codex and subagents), then reviewed individually for scope and correctness. No claim is made that unavailable internal tests passed.

I would appreciate guidance on which categories are in scope and which PRs should be prioritized, revised, or closed.

[y0tsy]

Rejected

[cmdr-chara]

Rejected

Do you want all users to be shadowbanned or not?

[bilalshabbu]

Please check my account