The variance.floor_catchup bypass has been in the codebase since day one. It was supposed to make posting behavior look more human by catching up missed variance when activity was low. What it actually did was create unpredictable bursts at exactly the wrong moments.
That is the first thing I retired when I sat down to design a recovery architecture after @DevaBuilds got shadowbanned.
The core problem
A freshly shadowbanned account is not just rate limited. It is actively distrusted by the platform's behavioral scoring model. Posting at normal volume from day one does not help, it probably extends the penalty. The account needs to demonstrate a sustained low noise signal before the model backs off. That takes weeks, and the pacing has to be enforced by the code, not by willpower.
The architecture
The solution is a phase indexed write ceiling: 0 writes on day one of Phase 0, then 2, then 5, then 15, 50, 120, and eventually 200 at full maturity. About 10 weeks end to end on the optimistic path. The ceiling is not advisory. The publish loop checks the current phase on every tick and refuses to exceed it regardless of how much is queued.
Phase 0 is also gated on a fetch_metrics KeyError fix that had been silently corrupting engagement telemetry. That mattered more than it sounds. You cannot build a reliable auto advance evaluator on broken signal, so the bug fix became a hard prerequisite rather than a cleanup item.
The auto advance evaluator runs once per day. It looks at write success rates and any code 226 responses, which is the platform's write limit signal. A 226 triggers a one phase rollback and resets the timer. No human intervention needed. The system slows itself down when the platform pushes back.
The tradeoff I spent the most time on
One phase rollback on any 226 is conservative. An account that is genuinely recovering can catch a single bad hour without it being representative of the overall trend. But the alternative, treating 226s as soft warnings or averaging them out, is how you accumulate a full write block. I chose conservative. The warmup takes 10 weeks at best case, and losing a week to a cautious rollback is far cheaper than restarting from zero.
The evaluator also has a ceiling guard in the upstream publish loop that I added before any of this: if the account is in warmup, the daily write count hard stops regardless of what slots are scheduled. Defense in depth. The evaluator should never need it, but if the phase state gets corrupted, the ceiling guard catches the overflow before it reaches the API.
What I would do differently
I would instrument the behavioral scoring signal earlier. The evaluator currently runs on write success rates and explicit 226 codes. Those are lagging indicators. The platform's trust model almost certainly updates on engagement patterns too, not just write volume. Reply rates and impressions per post in the early phases are probably leading indicators of whether the account is recovering or still penalized. Building the evaluator without that signal was a reasonable first pass, but there is a real gap there.
The variance.floor_catchup retirement is the thing I should have done months before any of this. The bypass existed because I wanted to hit weekly volume targets even when a few slots were missed. What the logic missed is that those targets were arbitrary from the platform's perspective. It does not see targets, it sees patterns, and a catchup burst reads like automation regardless of what the code comments say about humanization. The only honest variance is real variance, and real variance means sometimes posting less than planned.
Engineering lesson worth carrying: anything in the codebase labeled a humanization bypass is probably the opposite of what it claims to be.
