Paper deep dive
ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model Edits
Zhiqiang He, Zhi Liu
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 8/18/2026, 5:43:16 AM
Summary
The paper introduces ReForge, a continual heuristic learning framework for Adaptive Bitrate (ABR) algorithms that uses Large Language Models (LLMs) to iteratively edit a single page of fuzzy routing rules. Unlike traditional methods that freeze algorithms after design, ReForge adapts to new network scenarios (3G, 4G, 5G) by proposing small, verified edits to a router that selects from a frozen pool of pre-trained policies. The system ensures safety by replaying every edit against all previously served networks, rejecting changes that degrade performance. ReForge significantly improves Quality of Experience (QoE) compared to static policies and generalizes to unseen network families.
Entities (14)
Relation Signals (9)
REFORGE → edits → Fuzzy Rules
confidence 95% · Specifically, what it edits is a single page of fuzzy rules that routes every decision to one of a frozen pool of pre-trained policies.
REFORGE → uses → Large Language Model
confidence 95% · ReForge runs that routine with a large language model (LLM) in the loop.
REFORGE → approaches → Oracle
confidence 90% · past the best single policy at 1.66 and to 94% of an oracle
REFORGE → evaluatedon → 4G
confidence 90% · We evaluate ReForge on nine real-world network families arriving one at a time as 3G, 4G, then 5G.
REFORGE → evaluatedon → 3G
confidence 90% · We evaluate ReForge on nine real-world network families arriving one at a time as 3G, 4G, then 5G.
REFORGE → evaluatedon → 5G
confidence 90% · We evaluate ReForge on nine real-world network families arriving one at a time as 3G, 4G, then 5G.
REFORGE → improves → QoE
confidence 90% · A few edits per arrival lift mean QoE from 1.23 to 1.74
REFORGE → outperforms → RobustMPC
confidence 90% · lift mean QoE from 1.23 to 1.74, past the best single policy at 1.66
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Designing an ABR algorithm for one network scenario takes an engineer months, and large language models now do this work in hours, matching or beating hand-built designs. But either way, the design fits only the world visible at its birth, and fails on the world that arrives after. We ask whether an ABR algorithm can keep pace with the world, redesigned in minutes as each scenario arrives, with every change proven harmless to every scenario already served. In this work, we propose ReForge, a continual heuristic learning framework that adapts to continuously changing scenarios. ReForge runs that routine with a large language model (LLM) in the loop. Each round the LLM reads where the current design falls short and proposes one small edit, and a replay over every network served so far decides. Specifically, what it edits is a single page of fuzzy rules that routes every decision to one of a frozen pool of pre-trained policies. The LLM writes the first page from measurements alone, then keeps improving it on its own. Each round it reads where the current rules fall short and proposes one small edit, and a replay over every network served so far decides whether the edit lands. We evaluate ReForge on nine real-world network families arriving one at a time as 3G, 4G, then 5G. A few edits per arrival lift mean QoE from 1.23 to 1.74, past the best single policy at 1.66 and to 94\% of an oracle, and even repair families the loop never saw, one rising from 0.30 to 0.80. All code, data, and experiment records will be open-sourced upon cleanup.
Tags
Links
- Source: https://arxiv.org/abs/2608.15138v1
- Canonical: https://arxiv.org/abs/2608.15138v1
Trouble viewing inline? Open PDF directly →
Full Text
78,907 characters extracted from source content.
Expand or collapse full text
ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model Edits Zhiqiang He hezhiqiang@ieee.org The University of Electro-Communications Tokyo, Japan Zhi Liu ∗ liu@ieee.org The University of Electro-Communications Tokyo, Japan Prompt Template and Configuration Scientist / Engineer LargeLanguage Model Fuzzy Algorithm Page Evaluation Metric and Loop Code Choice of existing of Large Language Model LargeLanguage Model LargeLanguage Model Auto Research Self Improvement By Scenario Iter Iter Auto Research Figure 1: The Framework of ReForge. Abstract Designing an ABR algorithm for one network scenario takes an engineer months, and large language models now do this work in hours, matching or beating hand-built designs. But either way, the design fits only the world visible at its birth, and fails on the world that arrives after. We ask whether an ABR algorithm can keep pace with the world, redesigned in minutes as each scenario arrives, with every change proven harmless to every scenario already served. In this work, we propose ReForge, a continual heuristic learning framework that adapts to continuously changing scenarios. ReForge runs that routine with a large language model (LLM) in the loop. Each round the LLM reads where the current design falls short and proposes one small edit, and a replay over every network served so far decides. Specifically, what it edits is a single page of fuzzy rules that routes every decision to one of a frozen pool of pre-trained policies. The LLM writes the first page from measurements alone, then keeps improving it on its own. Each round it reads where the current rules fall short and proposes one small edit, and a replay over every network served so far decides whether the edit lands. We evaluate ReForge on nine real-world network families arriving ∗ Corresponding author Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. Conference’26, Vietnam © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-x-x-x-x/Y/M https://doi.org/10.1145/n.n one at a time as 3G, 4G, then 5G. A few edits per arrival lift mean QoE from 1.23 to 1.74, past the best single policy at 1.66 and to 94% of an oracle, and even repair families the loop never saw, one rising from 0.30 to 0.80. All code, data, and experiment records will be open-sourced upon cleanup. CCS Concepts • Information Systems→Multimedia streaming;• Comput- ing methodologies → Sequential decision making. Keywords Video Streaming, Large Language Model, Algorithm design. ACM Reference Format: Zhiqiang He and Zhi Liu. 2026. ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model Edits. In . ACM, Rio de Janeiro, Brazil, 16 pages. https://doi.org/10.1145/n.n 1 Introduction In a single decade, adaptive bitrate (ABR) has gone through three generations. Engineers hand-built controllers from buffer and through- put models [8,24,28] and from fuzzy logic [25]; reinforcement learn- ing then trained policies end to end [7,10,16]; now LLMs write ABR algorithms themselves [6,9]. NADA has an LLM draft candidate de- signs for a learned policy, then trains and filters them [6]; Crucible has an LLM tune the logic and parameters of existing controllers, once by scenario [9]. The designer keeps getting smarter, yet the algorithm it leaves behind still cannot improve itself. The wider field of LLM algorithm design is built the same way [5,11,12,22]. An LLM writes candidates, a search loop scores and refines them, and the budget’s end crowns a winner, delivered as the finished arXiv:2608.15138v1 [cs.AI] 15 Aug 2026 Conference’26, December 2026, VietnamHe et al. artifact. Algorithms designed this way overfit the cases seen during design, and fail on what arrives later [15]. The field softens this with two remedies. Generalization asks one policy to prepare in advance for every network it might meet [10, 16]. In practice the preparation reaches only as far as the training distribution, and performance falls sharply beyond it (Figure 2). Continual learning updates the policy in production instead [17], but each update is a gradient step over shared weights. No signal says the traffic is new enough to need an update, and no test says what an update just changed elsewhere, so forgetting can only be reduced [2,13,21,23,29], never eliminated. Both remedies work around the freeze; neither removes it. The real cure is an algorithm that improves itself as fast as its world changes. Systems that im- prove themselves with LLM agents act at three levels, the artifact the agent produces [19], the harness around the model [30], and the model weights themselves [31]. Our work sits at the artifact level, but on the other side of delivery. Prior systems iterate on the artifact before shipping and freeze it at delivery [9]; ours is delivered first and redesigned in service, each edit verified against every network already served. The algorithm is not prebuilt but produced as its scenarios arrive. To our knowledge, ReForge is the first ABR algorithm that improves itself in the field, with every change proposed, checked, and reversible. A self-improvement loop needs every trial to be cheap enough to repeat [26]. ReForge, the system of this paper, meets that bar by dividing the algorithm by cost. The expensive half is behavior, a pool of five pre-trained policies from classical control to deep reinforcement learning, frozen exactly as trained and never touched again. The cheap half is router, a one-page set of fuzzy IF–THEN rules over throughput and buffer signals. The two halves meet at every chunk of a video. A video plays as a stream of chunks, a few seconds downloaded at a time, and every chunk is one decision, which quality to fetch next. The rule page never makes that call itself but picks which frozen policy does, a tiny router over the pool. Only the rule page is ever redesigned, and the redesign runs as a loop. The page notices when it has fallen behind the traffic it serves, by counting the decisions its rules no longer cover. An LLM reads the evidence of where the page failed and answers with one small edit using six edit languages. Before the edit takes effect, it is replayed against every network the system has served so far, and it lands only if none of them does worse. ReForge completes a round in minutes, rejects harmful edits during replay, and lets a client run only the resulting page of rulesReForge. Knowledge arrives after deployment, and design now continues after deployment as well. We evaluate ReForge by letting network families arrive one at a time, first 3G, then 4G, then 5G. A few edits per arrival lift mean QoE over the nine held-out families from 1.23 to 1.74, past the best single policy at 1.66 and to 94% of an oracle that always picks the right one. The gains are easy to audit. When an arriving family clearly favors some policy, three accepted edits capture nearly all of the improvement, and every edit names the evidence that motivated it. The gains also travel. Two families that never entered any design round rise from 0.30 to 0.80, repaired by an edit meant for others. And on the one family where no policy has an advantage, the loop correctly does almost nothing, and replay keeps it from doing harm. Every LLM call is cached by its hash, so the full design history, and 050100150 training step (M env steps) 1.20 1.25 1.30 1.35 1.40 1.45 mean QoE (train pool) Pensieve PaMoE Merina MPCPaMoEFDASHPens.Merina FCC-16 FCC-18 Oboe Puffer-21 Puffer-22 Lumos4G Lumos5G SolisWi-Fi Norway3G -0.100.00-0.07-0.06-0.03 0.00-0.05-0.29-0.06-0.06 -0.010.00-0.27-0.12-0.08 -0.380.00-0.22-0.13-0.10 -0.200.00-0.12-0.13-0.07 0.00-0.98-7.68-2.34-2.05 -0.45-3.200.00-2.91-3.43 0.00-0.90-19.2-1.86-1.50 -0.60-0.52-5.460.00-0.00 (a) Training(b) Deployment Figure 2: Trained in one world, deployed in many. (a) Train- ing curves of the three learned policies;★marks the frozen checkpoint. (b) QoE each policy gives up against that family’s best; zero, boxed, marks the best. every number in this paper, replays from a clean checkout without spending a token. Our contributions: • Continual algorithm design. We propose that an algo- rithm’s design should continue for as long as it serves, and realize this for ABR. •The ReForge loop. We propose ReForge, which decouples algorithm design into an expensive learned component and a cheap heuristic component. The resulting design loop detects when the algorithm must change, validates every change against all networks served so far, and can undo any change if needed. •Results anyone can replay. Evaluated as the problem is posed, with networks arriving one family at a time, ReForge passes the best single policy, reaches 94% of an oracle, and repairs families it never saw. 2 Motivation Three findings forced the design of ReForge. This section retraces them. 2.1 One policy is not enough, so we route The usual practice is to pick one algorithm, deploy it, and let it face every network. We measured what that costs with five widely used policies. Two are hand-built controllers with nothing to train, Ro- bustMPC [28] and FDASH [25]; the other three are learned policies, Pensieve [16], Merina [10], and PA-MoE [7], which we trained on a pool of 3G traces and froze at their best checkpoints (Figure 2a). Each policy then runs alone on the held-out test split of all nine families, and Figure 2b reports what each gives up against the best policy for that family. No policy wins everywhere. Four different policies take first place, and a wrong choice costs at most 0.30 QoE inside a policy’s training distribution but up to 19.24 outside it. Every family, however, has at least one strong policy in the pool. An oracle that always picks that policy reaches a mean QoE of 1.854, with no new training at all. This is what pushed us to a router. The missing piece was not a better policy but a dispatcher. Routing is also safe by construction. Every action comes from some trusted ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model EditsConference’26, December 2026, Vietnam policy, so the router’s worst case on any family is the worst cell in that family’s row, known before deployment. 2.2 One design is not enough, so we redesign A router still has to come from somewhere. It can be trained, like a neural gate, or written, like a page of rules. We asked an LLM to write it. Writing costs minutes where training costs days, and what is written can be read. The LLM received only what existed at the time, each policy’s scores on the in-pool train splits and the bandwidth statistics of those traces. From these it wrote eight IF–THEN rules over four signals, throughput mean, throughput variability, buffer level, and buffer drift. For comparison we trained a neural gate on the same traces, a small MLP that reads the same four signals, fits each policy’s observed rewards, and picks the highest prediction. The rules won the comparison. In-pool they routed almost perfectly, within 0.05 QoE of the best, and beat the gate on eight of nine families (Figure 3). Yet over all nine families they score 1.227, a full 0.43 below simply running RobustMPC everywhere. A carefully designed router lost to not routing at all. Who failed? Not the LLM, whose rules beat the trained gate. Not the rules, which were nearly perfect in the world they knew. Not the prompt, because no prompt can create a fact that does not yet exist. What failed was the timing. The router knew only the in-pool world, so it sent nearly everything to PA-MoE, the in-pool winner (Figure 3b). That pick was right the day it was made, and wrong the day the unseen families arrived, where PA-MoE is nearly the worst (Figure 3a). This pushed us from designing once to designing continually. The LLM can clearly write a good router. It just has to keep writing it. A design can be finished only after the world has fully revealed itself, and the world never does. 2.3 Weights are not safe, so we edit rules Rewriting a system that is serving users is an old problem, and software engineering settled it long ago. A change must say why it is needed, must pass the tests before it lands, and must be small enough to revert. Retraining the weights fails all three. It cannot say why, because a softmax reports the same confidence on families it has never seen. It cannot be tested in advance, because scoring a retrained network on every past network costs about as much as the training itself. It cannot be reverted, because every weight moves at once and there is no old version to put back. So its damage is discovered live, and can only be reduced, never eliminated [13, 21, 29]. A one-line rule edit passes all three. The page says why, by counting the decisions its rules no longer cover. The past is the test suite, because a small file can be re-scored on every family served so far before the edit lands. Reverting is deleting the line. None of this is special to our rules. Reviewability comes free with any rule representation, and that is exactly why we chose one. It also settles who may touch what. The policies stay frozen, beyond the reach of any edit, and the LLM only ever rewrites the page. 3 ReForge ReForge runs in two stages, as shown in Figure 1. The LLM writes the whole page once, then only revises it, one small edit at a time, as arriving families show what it missed. This section describes each stage in turn. 3.1 Stage 1: Writing the first page The first stage asks the LLM to write the page, the whole algorithm it will ever touch. The page must implement a router푔that turns a feature vectorℎ 푡 , computed from recent observations, into one pol- icy of the frozen poolΠ=휋 1 , . . .,휋 푁 , so that at every chunk the client executes휋 푔(ℎ 푡 ) (푠 푡 ). The prompt gives the LLM two things and no more. The first is measurements, each policy’s QoE, rebuffering, and smoothness on the in-pool train splits, the bandwidth statistics of those traces, and the observed range of every candidate feature. No routing hint appears anywhere, so what to look at and what to do must both come out of the numbers. The second is the form the answer must take, a JSON page in four parts. Features fix what the router sees, named views over the observa- tion stream assembled from a fixed operator table, so the LLM can never ask for a number the runtime cannot compute. Membership turns numbers into words, named trapezoidal bands such asLow, Mid, andHighin the style of classical fuzzy control [25]. A value near a band edge is not forced to one side but belongs to both neigh- bors at once, each to a degree between 0 and 1. Rules turn words into a choice. Each is a single IF–THEN clause, IF these features sit in these bands, THEN use this policy. A rule fires with the product of its degrees, and a policy’s weight is that of its strongest rule. Meta covers the cases the rules cannot. When a state is known to break a policy, the fence blocks that policy no matter what the rules say. When no rule fires, whether because the windows have not filled or because traffic falls outside every band, the default policy acts. When two policies score nearly the same, the stickiness margin stops the router from switching every chunk. This form has two benefits. The page is cheap to run, one pass of simple arithmetic per chunk, no sampling, no learning. And the page is easy to check, since a small program can verify every band and every rule before the page ever runs. We call the LLM once, before the first new family arrives, and its answer is the Stage-1 router, the one scored in Figure 3. The LLM picked four signals—windowed throughput mean, throughput variability, buffer occupancy, and per-chunk buffer drift—split each into bands, and wrote eight rules over them. It also wrote one fence, for MPC. In the measurements MPC was the riskiest policy, the best on the steadiest family and the worst on the choppy ones. The fence therefore bans MPC when the link shakes or the buffer runs low, and leaves the rest to the rules. Seven of the eight rules point at PA-MoE, which won four of the five families the LLM saw, and the single MPC rule covers the fifth, steady high-bandwidth traffic. The design was right for the families the LLM saw and wrong for the families it never saw. Everything after this point is revision. 3.2 Stage 2: The redesign round The second stage must fix what the first page got wrong without breaking what it got right. It works the way new traffic reaches a real service. Families arrive one after another as distributions D 1 ,D 2 , . . ., each a kind of network the system has not served before. Every family’s traces come split in two fixed parts, one for training and one for testing. WhenD 푘 arrives, its train part becomes a new Conference’26, December 2026, VietnamHe et al. 1.2 1.4 1.6 1.8 1.351.451.55 mean QoE — in-pool (5) 0.5 1.0 1.5 2.0 mean QoE — unseen (4) FDASH (-5.8) PaMoE Pensieve RobustMPC Merina LLM rules MLP gate oracle fixed RobustMPC +0.43 overall 0 100 routed (%) +0.00-0.05+0.00+0.00-0.00-0.92-3.14-1.01-0.52 (b)LLM rules FCC-16FCC-18 Oboe Puffer-21Puffer-22 Lumos4GLumos5G SolisWi-Fi Norway3G 0 100 routed (%) -0.09-0.09-0.13-0.28-0.21-1.70-3.20-0.84-0.58 (c)MLP gate in-pool (5)unseen (4) (a) Is routing worth it? test-trace QoE; dotted = equal overall QoE (b, c) Who each router picks ▼ best expert; numbers = regret; all on test traces FDASHPaMoEPensieveRobustMPCMerina Figure 3: Why the LLM’s first router fails. (a) Each point is one method;푥is mean QoE on the five in-pool families,푦on the four unseen families (both on test traces); dashed lines are equal nine-family means. The router the LLM wrote (1.23) sits below fixed RobustMPC (1.66). (b, c) The cause; policy rankings flip across the boundary, the in-pool winner is the wrong choice out-of-pool, and at design time only the in-pool axis is visible. probe, the only data the loop may work from, and probing is cheap, twenty simulated episodes score one candidate on one family. Its test part never enters the loop, and every number we report comes from test parts alone. Each arrival opens a phase of sixteen rounds. A round is one prompt, one edit, one verdict. The prompt holds the current page, its probe scores, and four kinds of evidence. The per-policy trial answers what every other policy would have done, by running each one alone on the probe traces. Ordinary logs record only the policy that was chosen and say nothing about the ones that were not, so without this table, sending a state to a different policy is a guess. The coverage report answers where the rules cannot reach. It counts the chunks that match no rule and fall through to the default. It also puts each feature’s observed range next to the bands meant to cover it. A neural gate offers nothing equivalent, because a softmax answers with the same confidence everywhere, so it cannot report that its own vocabulary has fallen behind. The worst-episode trace shows how a failure unfolds. The first two give averages, so the prompt also carries the worst episode on the worst probe family, logged chunk by chunk. This is where the LLM can see the state a bad decision was made in. The failure ledger records what has already been tried. The LLM starts each round from a fresh prompt with no memory of the last, so every rejected edit is listed with its reason, and the loop never walks the same dead branch twice. The LLM answers with one edit and nothing else. It never touches the rule file itself, it writes the edit in the closed language of Table 1, and a validator applies or refuses it. A refused edit wastes its round and is written into the ledger. An edit that lands changes a line or two of a one-page file, so a human can read exactly what each round did. Five of the six operators rearrange choices over words the page already has, andsplit_labelmakes a new word when a family carries states the old words cannot say. In our run, Lumos5G throughput (100–236 Mbps) landed in the sameHighband as Lu- mos4G throughput (5–27 Mbps), and no rule could part what the Table 1: The edit language. One edit per round; every edit is mechanically validated before any evaluation, and an invalid edit costs the round. OperatorMechanical checks (excerpt) add_rulefeatures, labels, and policy must exist remove_ruleindex must match the prompt’s numbering edit_rulesame checks as add, applied to an index retune_membershipnew breakpoints must satisfy 푎 ≤ 푏 ≤ 푐 ≤ 푑 split_labelsplit point must lie in the band’s plateau; rules referencing the old label are copied to the new one, so behavior is preserved set_metaleaf-path whitelist; the fence cannot be removed, only its thresholds tuned vocabulary could not tell apart.split_labelcuts the band in two and copies the affected rules, so the split alone changes nothing, and the redirect follows a round later. The verdict comes from the acceptance gate, a replay against the past. The loop keeps a scoreboard, the best score any accepted page has reached on each probe family. A candidate, the current page with the edit applied, is rerun on every probe family, the new one and every old one alike. If any family falls more than훿=0.05 below its best on the scoreboard, the edit is rejected. If none falls and the mean or the worst probe score rises by at least휖=10 −3 , the edit is accepted. Removals and splits are excused from showing a gain, since neither can, but they still must not drop any family below its best. And whenever the page has grown past its original size, an occasional round allows only two answers, remove a rule or do nothing, so the page cannot grow without bound. Two things follow. The loop stops, because scores are bounded and every accepted improvement clears a fixed margin. And no family the system has served can quietly get worse, because the edit that would hurt it dies in the replay. Forgetting is not reduced; it is rejected. ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model EditsConference’26, December 2026, Vietnam Table 2: Nine-family means, QoE and its three components. SystemQoE↑Bitrate↑Rebuf.↑Smooth↑ Classical controllers (outside the pool) Rate-based1.3742.203 −0.508 −0.321 BBA1.3791.977 −0.181 −0.417 BOLA0.5312.075 −0.681 −0.863 Frozen pool policies, each deployed alone FDASH−1.8522.302 −4.050 −0.103 Pensieve1.0081.412 −0.213 −0.191 Merina1.0391.318 −0.193 −0.087 PA-MoE1.2261.707 −0.229 −0.253 RobustMPC1.6612.143 −0.317 −0.165 Learned router over the frozen pool MLP gate1.0651.692 −0.293 −0.335 ReForge (ours), across the arrival phases Stage-1 router1.2271.741 −0.229 −0.285 Final page1.7382.111 −0.240 −0.133 Oracle (upper bound)1.8542.143 −0.171 −0.119 4 Evaluation 4.1 Setup Benchmark. Nine network families, each with disjoint train and test splits. The learned policies saw only the train splits of the five 3G-era families, FCC-16 and FCC-18 [3], Oboe [1], and Puffer-21 and Puffer-22 [27], so we call these five in-pool. The other four, Lumos4G and Lumos5G [18], SolisWi-Fi [4], and Norway3G [20], contributed nothing to any training, and we call them unseen. Their bandwidth reaches two orders of magnitude beyond the 3G traces. All reported numbers are mean QoE on test splits, 500 episodes×3 seeds per (family, phase). QoE is the standard linear form (bitrate reward minus rebuffering and smoothness penalties) [28]. Arrival sequence. Redesign proceeds in phases, each adding one probe family, always its train split. Phase 1 adds the 3G training pool, phase 2 Lumos4G, phase 3 Lumos5G. Each phase runs 16 rounds, one Claude Opus call per round at temperature 0, 48 calls in all. SolisWi-Fi and Norway3G never enter any probe set—they are the true zero-shot holdout. Baselines. Five rule-based and three learning-based methods, each running alone on every family. RobustMPC [28] optimizes QoE over a short horizon while hedging against prediction error; FDASH [25] maps buffer and throughput to bitrate with fuzzy rules; RateBased [14] picks the highest rate a throughput estimate sustains; BBA [8] reads bitrate off buffer occupancy; BOLA [24] turns the choice into Lyapunov optimization. Pensieve [16] learns a policy end to end; Merina [10] meta-learns for fast adaptation; PA-MoE [7] adapts through a plasticity-aware mixture of experts. The pool holds five of these eight, RobustMPC, FDASH, Pensieve, Merina, and PA-MoE. 4.2 Does redesign close the gap? A router earns its place only by beating the policies it routes over, and the Stage-1 router did not. It scores a nine-family mean QoE of 1.227, well short of the 1.661 of simply running RobustMPC everywhere. After the three families have arrived and been served, the page scores 1.738, ahead of every fixed policy. An oracle that always picks each family’s best policy scores 1.854, so the page recovers 94% of what perfect routing would give. Figure 5 shows how it got there, flat through the 3G phase, then rising as 4G and 5G arrive. Figure 5d breaks that mean down by family. The Stage-1 router gives up−0.92 QoE on Lumos4G,−3.14 on Lumos5G, and−1.01 on SolisWi-Fi against each family’s best fixed policy. These are the families where the policies differ most (Figure 2b), so a wrong pick costs the most there, and they are where redesign has the most to win back. After the three phases every family except Lumos5G and Norway3G sits within 0.05 of that best. Pooled over every playback (Figure 4), the final page has the fewest bad playbacks of any method and comes out ahead in all three trade-offs, and the decomposition says why, it keeps bitrate high without causing more stalls. None of this came from a bigger algorithm. Forty-eight proposals produced eighteen accepted edits, and the page ends with the eight rules it started with, over the same five policies. What changed is where those rules point, to four policies now instead of two, with the default moved from PA-MoE to MPC. 4.3 What did the past pay? Every edit is made for the family that just arrived, so the question is what it does to the families already served. Across all 48 rounds no served family ever lost more than훿on its probes, and five of the rejected rounds in Figure 5b fell precisely because they would have. Figure 5d shows the same on the test side, where the 3G rows barely move (1.523→1.518) while Lumos4G climbs+0.88 and Lumos5G +2.73. Adaptation happened, forgetting did not, and the whole cost to the past is−0.03 each on Puffer-21 and Puffer-22. Phase 1 shows the other side. On the 3G pool the five policies score almost the same, so routing has nothing to win, and sixteen rounds of trying gained a little on the probes while losing a little on the test traces. The loop overfits when there is nothing to learn, but the gate caps the bill, and a whole wasted phase costs 0.02 on the nine-family mean. Norway3G is the same case one family at a time, where no policy leads and no edit is ever accepted. 4.4 Where do the gains come from? The gains are few, fast, and each names its evidence, and what follows analyses one design trajectory rather than a general law. Three edits, each citing what it saw. Phase 2’s whole gain arrives in its first three rounds, the steps marked r17 to r19 in Figure 5a. Two of them sent theHighband to MPC, because the trial table showed MPC scoring 2.71 there where PA-MoE scored 1.79. The third moved the default to MPC, because the coverage report showed 6.4% of Lumos4G chunks firing no rule at all. Three edits were enough. The router now scores as well as the best policy on that family, and the next 13 rounds add nothing. The largest zero-shot transfer came from the default, not from a rule. Phase 2 never probed 5G, yet Lumos5G jumped from 1.02 to 3.71 and SolisWi-Fi’s regret went to zero, both from the r19 edit alone. On 5G, 52.5% of chunks fire no rule and take the default, so moving it from PA-MoE (0.97 there) to MPC (3.72) turned the Conference’26, December 2026, VietnamHe et al. −505 QoE 0.0 0.5 1.0 CDF Better 0.050.100.15 Time on Stall (s) 1.5 2.0 Bitrate (mbps) Better 0.250.500.75 Smooth (mbps) 1.5 2.0 Bitrate (mbps) Better 0.050.100.15 Time on Stall (s) 0.25 0.50 0.75 Smooth (mbps) Better QoE Bitrate Rebuf. Smooth −1 0 1 2 Score Rate-based BBA BOLA Pensieve Merina PaMoE MLP gate LLM rules (Stage 1) RobustMPC ReForge (Ours) Figure 4: Final performance pooled over the nine test families. Left to right: the per-episode QoE CDF, three pairwise trade-offs with penalty axes reversed so upper right is better, and the QoE decomposition, where ours is the last bar of each group. 2 3 4 probe QoE 4G / 5G P1 3GP2 +Lumos4GP3 +Lumos5G Lumos4G Lumos5G r17 edit→mpc +0.32 r18 edit→mpc +0.21 r19 meta→mpc +0.41 1.1 1.2 1.3 3G pool 3G pool edit 10203040 maintenance round (48 total, 16 per phase) 4 6 8 10 count rules bw_mean labels FDASH enters P0P1P2P3 FCC-16 FCC-18 Oboe Puffer-21 Puffer-22 Lumos4G Lumos5G SolisWi-Fi * Norway3G * 0.000.000.000.00 -0.05-0.050.000.00 0.00-0.00-0.00-0.00 0.00-0.03-0.04-0.03 -0.00-0.04-0.04-0.03 -0.92-0.91-0.03-0.04 -3.14-3.14-0.45-0.42 -1.01-1.010.000.00 -0.52-0.52-0.52-0.52 (a) (b) (c) (a-c) What each round changed (d) Outcome regret vs best fixed; * never probed edit ruleadd ruleretunesplit labelset metaremoverejected (hollow) Figure 5: The design trajectory. Top: probe QoE, which moves only on accepted rounds and never descends. Bottom: the edit ledger, color by operator, filled when accepted. Right: per-family regret after each phase. largest blind spot into near-best behavior on families never seen. A local observation on 4G became a policy for everything out of vocabulary, and the replay confirmed it hurt nothing. One missing channel stops the loop entirely. An earlier version of the loop had no coverage report. On the 5G arrival it tried eight rule edits in eight rounds, and not one was accepted. The model was not at fault. The real problem was that no rule applied to those chunks at all. Nothing in its evidence could have told it that, so it kept editing rules that were never going to fire. We added the report, and the next run opened by widening a band instead, and kept seven of its eight edits. New words are cheap, in both senses. The loop proposed six splits and all were accepted. Phase 3 cut the bandFullin two and sent the new half to FDASH the round after, worth+0.043 on the 5G probe. Not all six earned their round. A split changes nothing by itself, so it can never show a gain, and we exempt it from having to. Without that exemption the vo- cabulary could never grow, because the first step would be rejected before the second could pay for it. With it, a split is the only edit certain to be accepted, reason enough to propose one when nothing better comes to mind. 5 Conclusion and Discussion An algorithm is written once, on the day its designer knows the least, and the world it serves keeps moving after that. The field has answered this by asking one algorithm to be right about a future it cannot see, or by retraining it blindly once the future arrives. We answered it by making the design itself continue. The routing layer of an ABR system became a page of rules that an LLM rewrites as network families arrive, one small edit per round, each edit replayed against every family already served and kept only if it harms none. The page reports when it no longer covers the world, the replay reports what a change would cost, and between the two, forgetting stops being a risk to be reduced and becomes an event to be refused. A few edits per arrival carried the router past the best fixed policy and to 94% of an oracle. A finite algorithm will always be overtaken by endless variation. An algorithm that is never finished only has to keep up with it. ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model EditsConference’26, December 2026, Vietnam Two limits mark where this stops. The first is competence, be- cause editing re-dispatches it and cannot create it. On Norway3G no policy in the pool can serve the family, so the loop finds no edit worth accepting and the score never moves. That is the signal to train a new policy, not to write another rule. The second is cost. The guarantee is bought by rerunning every past family on every candidate, which stays affordable only while the artifact is a page and the episodes are cheap. Scaling to larger rule bases and slower simulators is open. References [1] Zahaib Akhtar, Yun Seong Nam, Ramesh Govindan, Sanjay Rao, Jessica Chen, Ethan Katz-Bassett, Bruno Ribeiro, Jibin Zhan, and Hui Zhang. 2018. Oboe: Auto- tuning video ABR algorithms to network conditions. In Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Communication. 44–58. [2]Pietro Buzzega, Matteo Boschini, Angelo Porrello, Davide Abati, and Simone Calderara. 2020. Dark experience for general continual learning: a strong, simple baseline. Advances in neural information processing systems 33 (2020), 15920– 15930. [3]Federal Communications Commission. 2016. Measuring Broadband America: Raw Data Releases (2016). https://w.fcc.gov/general/measuring-broadband- america. [4]GreenLv. 2023. Solis-WiFi-Trace. https://github.com/GreenLv/Solis-WiFi-Trace [5]Pouya Hamadanian, Pantea Karimi, Arash Nasr-Esfahany, Kimia Noorbakhsh, Joseph Chandler, Ali ParandehGheibi, Mohammad Alizadeh, and Hari Balakr- ishnan. 2026. Glia: A human-inspired ai for automated systems design and optimization. In Proceedings of the ACM Conference on AI and Agentic Systems. 61–84. [6]Zhiyuan He, Aashish Gottipati, Lili Qiu, Xufang Luo, Kenuo Xu, Yuqing Yang, and Francis Y Yan. 2024. Designing network algorithms via large language models. In Proceedings of the 23rd ACM Workshop on Hot Topics in Networks. 205–212. [7]Zhiqiang He and Zhi Liu. 2026. Plasticity-Aware Mixture of Experts for Learning Under QoE Shifts in Adaptive Video Streaming. IEEE Transactions on Multimedia (2026), 1–13. doi:10.1109/TMM.2026.3688418 [8] Te-Yuan Huang, Ramesh Johari, Nick McKeown, Matthew Trunnell, and Mark Watson. 2014. A buffer-based approach to rate adaptation: Evidence from a large video streaming service. In Proceedings of the 2014 ACM conference on SIGCOMM. 187–198. [9]Lianchen Jia, Chaoyang Li, Qian Houde, Tianchi Huang, Jiangchuan Liu, and Lifeng Sun. 2026. Crucible: Quantifying the Potential of Control Algorithms through LLM Agents. Advances in Neural Information Processing Systems 38 (2026), 123043–123067. [10]Nuowen Kan, Chenglin Li, Yuankun Jiang, Wenrui Dai, Junni Zou, Hongkai Xiong, and Laura Toni. 2025. MERINA+: Improving Generalization for Neural Video Adaptation via Information-Theoretic Meta-Reinforcement Learning. IEEE Transactions on Circuits and Systems for Video Technology (2025). [11] Pantea Karimi, Kimia Noorbakhsh, Mohammad Alizadeh, and Hari Balakrishnan. 2026. Improving coherence and persistence in agentic ai for system optimization. In Proceedings of the ACM Conference on AI and Agentic Systems. 124–160. [12] Pantea Karimi, Dany Rouhana, Pooria Namyar, Siva Kesava Reddy Kakarla, Venkat Arun, and Behnaz Arzani. 2025. Robust Heuristic Algorithm Design with LLMs. arXiv:2510.08755 [cs.AI] https://arxiv.org/abs/2510.08755 [13]James Kirkpatrick, Razvan Pascanu, Neil Rabinowitz, Joel Veness, Guillaume Desjardins, Andrei A Rusu, Kieran Milan, John Quan, Tiago Ramalho, Agnieszka Grabska-Barwinska, et al.2017. Overcoming catastrophic forgetting in neural networks. Proceedings of the national academy of sciences 114, 13 (2017), 3521– 3526. [14]Zhi Li, Xiaoqing Zhu, Joshua Gahm, Rong Pan, Hao Hu, Ali C Begen, and David Oran. 2014. Probe and adapt: Rate adaptation for HTTP video streaming at scale. IEEE journal on selected areas in communications 32, 4 (2014), 719–733. [15]Fei Liu, Yiming Yao, Ping Guo, Zhiyuan Yang, Xi Lin, Zhe Zhao, Xialiang Tong, Kun Mao, Zhichao Lu, Zhenkun Wang, et al.2024. A systematic survey on large language models for algorithm design. Comput. Surveys (2024). [16]Hongzi Mao, Ravi Netravali, and Mohammad Alizadeh. 2017. Neural adaptive video streaming with pensieve. In Proceedings of the conference of the ACM special interest group on data communication. 197–210. [17]Michael McCloskey and Neal J Cohen. 1989. Catastrophic interference in con- nectionist networks: The sequential learning problem. In Psychology of learning and motivation. Vol. 24. Elsevier, 109–165. [18]Arvind Narayanan, Xumiao Zhang, Ruiyang Zhu, Ahmad Hassan, Shuowei Jin, Xiao Zhu, Xiaoxuan Zhang, Denis Rybkin, Zhengxuan Yang, Zhuoqing Morley Mao, et al.2021. A variegated look at 5G in the wild: performance, power, and QoE implications. In Proceedings of the 2021 ACM SIGCOMM 2021 Conference. 610–625. [19]Alexander Novikov, Ngân V ̃ u, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov, Borislav Kozlovskii, Francisco JR Ruiz, Abbas Mehrabian, et al.2025. Alphaevolve: A coding agent for scientific and algorithmic discovery. arXiv preprint arXiv:2506.13131 (2025). [20]Haakon Riiser, Paul Vigmostad, Carsten Griwodz, and Pål Halvorsen. 2013. Com- mute path bandwidth traces from 3G networks: Analysis and applications. In Proceedings of the 4th ACM Multimedia Systems Conference. 114–118. [21]David Rolnick, Arun Ahuja, Jonathan Schwarz, Timothy Lillicrap, and Gregory Wayne. 2019. Experience replay for continual learning. Advances in neural information processing systems 32 (2019). [22]Bernardino Romera-Paredes, Mohammadamin Barekatain, Alexander Novikov, Matej Balog, M Pawan Kumar, Emilien Dupont, Francisco JR Ruiz, Jordan S Ellenberg, Pengming Wang, Omar Fawzi, et al.2024. Mathematical discoveries from program search with large language models. Nature 625, 7995 (2024), 468–475. [23]Andrei A Rusu, Neil C Rabinowitz, Guillaume Desjardins, Hubert Soyer, James Kirkpatrick, Koray Kavukcuoglu, Razvan Pascanu, and Raia Hadsell. 2016. Pro- gressive neural networks. arXiv preprint arXiv:1606.04671 (2016). [24]Kevin Spiteri, Rahul Urgaonkar, and Ramesh K Sitaraman. 2020. BOLA: Near- optimal bitrate adaptation for online videos. IEEE/ACM transactions on networking 28, 4 (2020), 1698–1711. [25] Dimitrios J Vergados, Angelos Michalas, Aggeliki Sgora, Dimitrios D Vergados, and Periklis Chatzimisios. 2015. FDASH: A fuzzy-based MPEG/DASH adaptation algorithm. IEEE Systems Journal 10, 2 (2015), 859–868. [26]Wenli Xiao, Jia Xie, Tonghe Zhang, Haotian Lin, Letian Fu, Haoru Xue, Jalen Lu, Yi Yang, Cunxi Dai, Zi Wang, et al.2026. ENPIRE: Agentic Robot Policy Self-Improvement in the Real World. arXiv preprint arXiv:2606.19980 (2026). [27] Francis Y Yan, Hudson Ayers, Chenzhi Zhu, Sadjad Fouladi, James Hong, Keyi Zhang, Philip Levis, and Keith Winstein. 2020. Learning in situ: a randomized experiment in video streaming. In 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20). 495–511. [28] Xiaoqi Yin, Abhishek Jindal, Vyas Sekar, and Bruno Sinopoli. 2015. A control- theoretic approach for dynamic adaptive video streaming over HTTP. In Proceed- ings of the 2015 ACM conference on special interest group on data communication. 325–338. [29]Friedemann Zenke, Ben Poole, and Surya Ganguli. 2017. Continual learning through synaptic intelligence. In International conference on machine learning. Pmlr, 3987–3995. [30] Hangfan Zhang, Shao Zhang, Kangcong Li, Chen Zhang, Yang Chen, Yiqun Zhang, Lei Bai, and Shuyue Hu. 2026. Self-harness: Harnesses that improve themselves. arXiv preprint arXiv:2606.09498 (2026). [31]Andrew Zhao, Yiran Wu, Tong Wu, Quentin Xu, Yang Yue, Matthieu Lin, Shen- zhi Wang, Qingyun Wu, Zilong Zheng, and Gao Huang. 2026. Absolute zero: Reinforced self-play reasoning with zero data. Advances in Neural Information Processing Systems 38 (2026), 105816–105879. Conference’26, December 2026, VietnamHe et al. A The Stage-1 Router The complete page produced by Stage 1, reformatted from JSON. Signals use a five-chunk window. A trapezoid[푎,푏,푐,푑]rises from 푎to푏, holds to푐, and falls to푑. Seven of the eight rules end in PA-MoE, the in-pool winner. Table 3: Membership bands of the Stage-1 router. SignalLabel [푎,푏,푐,푑] throughput mean (kbps) Low [0, 0, 900, 1500] Mid [900, 1500, 4800, 6400] High [4800, 6400, 10 5 , 10 5 ] throughput variability Steady [0, 0, 0.10, 0.20] Choppy [0.10, 0.20, 0.35, 0.55] Volatile [0.35, 0.55, 5, 5] buffer level (s) Critical [0, 0, 4, 8] Healthy [4, 8, 30, 42] Full [30, 42, 10 3 , 10 3 ] buffer drift (s/chunk) Draining [−10 3 ,−10 3 ,−2.0,−0.5] Holding [−2.0,−0.5, 10 3 , 10 3 ] Table 4: The eight rules; a blank cell means the rule ignores that signal. Metadata: the fence allows MPC only when vari- ability is at most 0.35, the buffer holds at least 10 s, and the drift is no worse than−3 s per chunk; stickiness keeps the incumbent unless a challenger leads by 0.15 for 4 chunks; the warm-up and no-rule default is PA-MoE. #meanvariabilitybufferdrift → policy 0 High Steady Full HoldingMPC 1 High Steady Full DrainingPA-MoE 2 High Steady HealthyPA-MoE 3 High Steady CriticalPA-MoE 4 High ChoppyPA-MoE 5 High VolatilePA-MoE 6 MidPA-MoE 7 LowPA-MoE ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model EditsConference’26, December 2026, Vietnam B The Stage-1 Prompt The prompt that produced the Stage-1 router, verbatim. The system half fixes the interface, the feature vocabulary, the safety fence, and the output format. The user half carries only measurements, the per-policy profiles, the trace statistics, and the observed feature ranges. The model’s answer, one JSON controller, follows last, and Appendix A shows the same rule base reformatted for reading. B.1 System prompt You are designing, from scratch, the complete controller for a router that picks – once per video chunk – which of several frozen pre-trained adaptive-bitrate (ABR) experts gets to act. You design three things: WHAT THE ROUTER OBSERVES, how those observations are carved into fuzzy labels, and the rules mapping labels to experts. You are given ONLY measurements: how each expert scored on each training trace family, the bandwidth statistics of those families, and the observed ranges of candidate quantities. You are NOT given any routing heuristic, and no feature view is imposed on you. Infer both the feature view and the routing policy from the measurements. The router only ever delegates. Whatever it picks, the executed action is that expert's own decision for this chunk – the router never chooses a bitrate itself. == How the deployed router runs your controller, once per chunk == 1. Evaluate the`features` section in declaration order to get one number per feature. 2. For every feature that appears in`membership`, each label's trapezoidal function gives a degree in [0,1]: trapezoid(x; a,b,c,d) = 0 for x<=a or x>=d; 1 for b<=x<=c; linear on (a,b) and (c,d). 3. Rule firing strength = PRODUCT of its antecedent degrees (product T-norm). 4. Per expert, aggregate across rules by MAX (max S-norm). 5. Experts blocked by the safety fence this chunk are dropped. 6. Highest remaining weight wins, subject to stickiness. If nothing fires at all, the router falls back blindly to meta.warmup.default – avoid leaving holes. == The feature vocabulary == A feature is one node.`of` /`num` /`den` may only reference a feature declared EARLIER in the object (no forward references, no cycles). Operators: "op":"obs", "field":<name>, "scale":<float>, "index":<int> read a raw observation field, multiplied by`scale` (default 1.0). `index` is required only for next_video_chunk_sizes (a 6-vector). "op":"throughput" observed goodput of the chunk just downloaded, kbps (= chunk_bytes*8/delay_ms). Carries the previous value on idle chunks. "op":"last_bitrate_kbps" the bitrate actually executed on the previous chunk, kbps. "op":"diff", "of":<feature> value now minus value last chunk "op":"window_mean", "of":<feature>, "window":<int> "op":"window_std", "of":<feature>, "window":<int> "op":"window_cv", "of":<feature>, "window":<int> std/mean, dimensionless "op":"window_slope", "of":<feature>, "window":<int> least-squares slope per chunk "op":"ema", "of":<feature>, "alpha":<0..1]> alpha on the new sample "op":"ratio", "num":<feature>, "den":<feature> Observation fields available to`obs`: delay_ms download time of the chunk just fetched, milliseconds sleep_time_ms time the player slept because the buffer was full, milliseconds buffer_size_ms current playout buffer occupancy, milliseconds rebuffer_ms stall time caused by the chunk just fetched, milliseconds selected_video_chunk_size_bytes bytes actually downloaded for that chunk remain_chunk chunks left in the video next_video_chunk_sizes bytes of the NEXT chunk at each of the 6 bitrate rungs (6-vector, needs index) is_done_bool 1 when the episode has ended You may declare intermediate features that carry no membership functions – e.g. a raw throughput series feeding a windowed statistic. Only features that appear in `membership` can be used in rule antecedents. == The safety fence == A hard, non-negotiable filter, evaluated before aggregation. It exists so that a high-variance expert cannot be selected in states where it is known to be catastrophic; you decide which experts it guards and at what thresholds, over your own declared features: "fence": ["expert": "<name>", "require": ["feature": "<declared feature>", "min": <float>, "feature": "<declared feature>", "max": <float>]] An expert is blocked on any chunk where any of its`require` conditions fails. Conference’26, December 2026, VietnamHe et al. Use [] if you judge no expert needs guarding. == Output == A SINGLE JSON object, nothing else – no prose, no markdown fence: "features": "<name>": "op": ..., ..., ..., "membership": "<feature>": "<Label>": [a,b,c,d], ..., ..., "rules": ["antecedents": "<feature>": "<Label>", ..., "consequent": "<expert>", ...], "meta": "fence": [...], "stickiness": "margin": <float>, "min_dwell": <int>, "warmup": "steps": <int>, "default": "<expert>" , "notes": ["<why you chose these features>", "<what regime each rule group targets>", ...] Hard constraints: - Breakpoints must satisfy a <= b <= c <= d, in that feature's own units. - Every label used in a rule must be declared in`membership` for that feature. - Every consequent must be one of the expert names given to you. - A rule may omit features from its antecedents; it then ignores them. - Label sets must cover each membership feature's full observed range with no gaps – a value outside every label makes the rule silently unable to fire. - At most 24 rules. Prefer the smallest controller that covers the measured regimes; every rule you add is one a human has to audit. - meta.warmup.default is used for the first chunks, before any window has filled. In`notes`, say explicitly why each feature earns its place. A feature that no measurement justifies is worse than no feature: it enlarges the rule space a human must read without buying discrimination. B.2 User prompt ## Expert pool - fdash (fuzzy-logic controller (no learned parameters)) - pamoe (sparse mixture-of-experts policy – noisy top-k router over several expert heads, trained with PPO) - pensieve (deep RL policy trained with PPO, using Pensieve's 6x8 history-matrix feature extractor) - mpc (model-predictive control – harmonic-mean throughput prediction discounted by the worst recent prediction error, then a lookahead search over bitrate sequences ( no learned parameters)) - merina (meta-RL policy – a VAE encodes the recent bandwidth trace into a latent, which conditions a PPO policy) ## A. Expert profiles – mean QoE per training trace family Higher QoE is better. QoE = bitrate reward - rebuffer penalty - smoothness penalty. Also shown: mean stall time per episode (s) and mean |delta bitrate| (Mbps). scenario fdash pamoe pensieve mpc merina QoE / stall_s / smooth QoE / stall_s / smooth QoE / stall_s / smooth QoE / stall_s / smooth QoE / stall_s / smooth FCC-16-Train +0.839 / 0.02 / 0.067 +0.909 / 0.03 / 0.091 +0.849 / 0.05 / 0.101 +0.838 / 0.05 / 0.157 +0.880 / 0.04 / 0.101 FCC-18-Train +2.665 / 0.03 / 0.083 +2.901 / 0.04 / 0.110 +2.887 / 0.05 / 0.121 +2.949 / 0.03 / 0.142 +2.881 / 0.05 / 0.121 Oboe-Train +1.869 / 0.00 / 0.099 +2.164 / 0.01 / 0.121 +2.042 / 0.04 / 0.140 +2.153 / 0.01 / 0.200 +2.089 / 0.03 / 0.138 Puffer-21-Train +0.936 / 0.07 / 0.266 +1.100 / 0.07 / 0.177 +0.996 / 0.09 / 0.199 +0.863 / 0.11 / 0.306 +1.032 / 0.09 / 0.191 Puffer-22-Train +0.511 / 0.13 / 0.105 +0.658 / 0.14 / 0.107 +0.539 / 0.17 / 0.119 +0.507 / 0.17 / 0.186 +0.609 / 0.15 / 0.112 Per-scenario best expert: FCC-16-Train best=pamoe QoE=+0.909 (spread across pool = 0.071) FCC-18-Train best=mpc QoE=+2.949 (spread across pool = 0.284) Oboe-Train best=pamoe QoE=+2.164 (spread across pool = 0.296) Puffer-21-Train best=pamoe QoE=+1.100 (spread across pool = 0.237) Puffer-22-Train best=pamoe QoE=+0.658 (spread across pool = 0.151) ## B. Trace statistics – the feature distributions your rules must partition Throughput in kbps. cv = std/mean over a sliding window of 5 samples, computed exactly the way the deployed router computes bw_cv. scenario n mean p10 p25 median p75 p90 cv_med cv_p90 %cv>.15 FCC-16-Train 151 1553 525 822 1267 2056 2871 0.110 0.324 36.5% FCC-18-Train 300 6400 1529 2163 4272 8355 13361 0.046 0.257 19.6% Oboe-Train 328 2806 850 1492 2758 3885 4701 0.042 0.214 17.9% Puffer-21-Train 500 2022 42 293 1188 3213 5211 0.643 1.230 90.8% Puffer-22-Train 500 1713 161 536 1222 2491 3938 0.369 0.917 70.4% IMPORTANT: the numbers above are the *link capacity* recorded in the trace files. They are NOT what your rules see. The router's bw_mean_kbps is a ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model EditsConference’26, December 2026, Vietnam derived quantity, chunk_bytes*8/delay_ms averaged over the last 5 downloads, and it can differ from link capacity by a large factor in either direction depending on chunk sizes and download timing. Set your breakpoints in the OBSERVED feature space below, not in the capacity space above. ## B2. OBSERVED RANGES of candidate quantities Measured by running every expert in the pool on each training family and logging, per chunk, the quantities you are most likely to build features from. These are ranges, not a prescribed feature view – you choose the view. Columns: observed goodput (kbps, 5-chunk window mean), its CV over the same window, buffer occupancy (s), and per-chunk buffer change (s). scenario n tp_p05 tp_p25 tp_med tp_p75 tp_p95 tp_max cv_med cv_p90 buf_p05 buf_med buf_p95 dbuf_p05 dbuf_med dbuf_p95 FCC-16-Train 470 755 915 1048 1116 1168 1211 0.103 0.258 5.8 17.3 35.7 -2.62 0.11 2.79 FCC-18-Train 470 6437 7703 8479 9200 10036 10418 0.080 0.166 8.3 52.2 59.9 -0.24 1.62 2.44 Oboe-Train 470 425 610 1236 4324 5775 6361 0.153 0.292 5.5 19.4 39.9 -2.69 0.76 2.60 Puffer-21-Train 470 760 1168 1523 5156 6846 8710 0.351 0.735 4.4 24.1 40.4 -9.15 1.74 3.63 Puffer-22-Train 470 272 294 1045 1927 2031 2133 0.060 0.101 4.0 5.3 38.4 -1.76 0.00 3.26 Across all visible training families the observed ranges are roughly: goodput 0 .. 10418 kbps buffer 0 .. 60.0 s CV 0 .. ~2 Whatever features you declare, their label sets must cover the range those features actually take on, with no gaps. ## Task Emit the JSON controller: features, membership, rules, meta. Route each measured regime to the expert the measurements say is strongest there. The binding constraint is that at runtime the router does NOT know which trace family it is on – it only sees the features you declared. So a regime is only actionable if your features can tell it apart from the others. B.3 Model output "features": "tp_kbps": "op": "throughput", "bw_mean_kbps": "op": "window_mean", "of": "tp_kbps", "window": 5, "bw_cv": "op": "window_cv", "of": "tp_kbps", "window": 5, "buf_s": "op": "obs", "field": "buffer_size_ms", "scale": 0.001, "dbuf_s": "op": "diff", "of": "buf_s" , "membership": "bw_mean_kbps": "Low": [0, 0, 900, 1500], "Mid": [900, 1500, 4800, 6400], "High": [4800, 6400, 100000, 100000], "bw_cv": "Steady": [0, 0, 0.1, 0.2], "Choppy": [0.1, 0.2, 0.35, 0.55], "Volatile": [0.35, 0.55, 5.0, 5.0] , "buf_s": "Critical": [0, 0, 4, 8], "Healthy": [4, 8, 30, 42], "Full": [30, 42, 1000, 1000], "dbuf_s": "Draining": [-1000, -1000, -2.0, -0.5], "Holding": [-2.0, -0.5, 1000, 1000] , "rules": [ "antecedents": "bw_mean_kbps": "High", "bw_cv": "Steady", "buf_s": "Full", "dbuf_s": "Holding", "consequent": "mpc" , "antecedents": "bw_mean_kbps": "High", "bw_cv": "Steady", "buf_s": "Full", "dbuf_s": "Draining", "consequent": "pamoe" , "antecedents": "bw_mean_kbps": "High", "bw_cv": "Steady", "buf_s": "Healthy", "consequent": "pamoe" , "antecedents": "bw_mean_kbps": "High", "bw_cv": "Steady", "buf_s": "Critical", "consequent": "pamoe" , "antecedents": "bw_mean_kbps": "High", "bw_cv": "Choppy", "consequent": "pamoe", "antecedents": "bw_mean_kbps": "High", "bw_cv": "Volatile", "consequent": "pamoe", "antecedents": "bw_mean_kbps": "Mid", "consequent": "pamoe", "antecedents": "bw_mean_kbps": "Low", "consequent": "pamoe" ], "meta": Conference’26, December 2026, VietnamHe et al. "fence": [ "expert": "mpc", "require": [ "feature": "bw_cv", "max": 0.35, "feature": "buf_s", "min": 10.0, "feature": "dbuf_s", "min": -3.0 ] ], "stickiness": "margin": 0.15, "min_dwell": 4, "warmup": "steps": 5, "default": "pamoe" , "notes": [ "POLICY SHAPE FROM THE MEASUREMENTS: pamoe is the per-scenario best expert in 4 of 5 families (FCC-16 +0.909, Oboe +2.164, Puffer-21 +1.100, Puffer-22 +0.658) and has the best pool-wide mean QoE (1.546 vs mpc 1.462, merina 1.498, pensieve 1.463, fdash 1.364). mpc is the only expert that beats it anywhere: FCC-18-Train, +2.949 vs +2.901. So the entire routing problem reduces to: recognise the FCC-18-like regime and hand it to mpc; everywhere else delegate to pamoe. Every rule below exists to draw exactly that one boundary, plus its safety complement.", "WHY bw_mean_kbps (5-chunk window mean of observed goodput): this is the single strongest separator in the OBSERVED space. FCC-18 sits at tp_p05=6437 / tp_med=8479, while every other family's tp_p95 is at most 6846 (Puffer-21) and typically <=5775 (Oboe). The 4800->6400 ramp puts essentially all of FCC-18 at High=1.0 while Oboe (p95 5775) only reaches partial High and FCC-16 (max 1211) and Puffer-22 (max 2133) never leave Low/Mid. Without this feature mpc's home regime is invisible .", "WHY bw_cv (same 5-chunk window): goodput alone is NOT sufficient, because Puffer-21 reaches tp_p95=6846 / tp_max=8710 and would otherwise masquerade as FCC-18 \ u2014 and Puffer-21 is precisely where mpc is the WORST expert in the pool (+0.863 vs pamoe +1.100, with the highest stall 0.11s and the worst smoothness 0.306). The observed CV cleanly splits them: FCC-18 cv_med 0.080 / cv_p90 0.166 versus Puffer-21 cv_med 0.351 / cv_p90 0.735. This is the measurement that says mpc's harmonic-mean-plus-error-discount predictor is only trustworthy on a stationary link, so cv carries a rule antecedent AND a fence bound.", "WHY buf_s: FCC-18 runs with buf_med 52.2s and buf_p95 59.9s 2014 deeper than every other family (next highest median is Puffer-21 at 24.1s, Puffer-22 sits at 5.3 s). Deep buffer is both a co-signature of the mpc-favouring regime and the state in which an mpc lookahead mistake cannot turn into a stall. Restricting mpc to buf Full keeps the shallow-buffer tail of FCC-18 (buf_p05 8.3s) on pamoe, which costs nothing there (2.901 vs 2.949 is inside the noise) and removes the only way mpc could stall on its own home family.", "WHY dbuf_s: per-chunk buffer change is the earliest collapse signal, and it is family-discriminative in exactly the direction that matters 2014 FCC-18 dbuf_p05 is only -0.24s while Puffer-21 dbuf_p05 is -9.15s and FCC-16/Oboe reach about -2.6s. It carries no rule of its own beyond one handoff term: it hands the deep- buffer/high-goodput cell back to pamoe when the buffer is actually collapsing, and it backstops the fence at -3.0s/chunk. Cheap (one extra label pair), and it is the feature that prevents the fence from ever opening a hole.", "FEATURES DELIBERATELY NOT DECLARED: no bitrate/last-action feature, no remain_chunk, no chunk-size features. No measurement in A or B2 stratifies expert quality along those axes, and each would multiply the rule space a reviewer must read without buying discrimination.", "RULE GROUP 1 (rule 1) 2014 mpc's only home: High goodput AND Steady cv AND Full buffer AND not draining. This is the FCC-18 signature and nothing else in the training set lands there at full degree.", "RULE GROUP 2 (rules 2-6) 2014 the complement inside High goodput, all to pamoe: choppy or volatile link (Puffer-21's high-goodput bursts), shallow or critical buffer, or a deep buffer that is draining. This guarantees the High region is fully tiled, so when the fence drops mpc there is still a live rule and the router never falls through to the blind warmup path.", "RULE GROUP 3 (rules 7-8) 2014 Mid and Low goodput to pamoe unconditionally. This covers FCC-16 (tp 755-1211), Puffer-22 (tp_p05 272, tp_med 1045), Oboe's lower half (tp_p25 610) and Puffer-21's lower half (tp_med 1523) 2014 every family where pamoe is measured best, and where mpc is measured worst-or-near-worst (FCC-16 +0.838, Puffer-22 +0.507, both last in the pool).", "FENCE: mpc is the only guarded expert because it is the only high-variance expert the rules can select, and its variance is measured, not assumed 2014 it is best on FCC-18 (+2.949) and simultaneously last on FCC-16 (+0.838), Puffer-21 (+0.863) and Puffer-22 (+0.507), with the largest |delta bitrate| in 4 of 5 families (up to 0.306). The bounds cv<=0.35 (above Puffer-21's cv_med 0.351 boundary, far above FCC-18's cv_p90 0.166), buf>=10s and dbuf>=-3.0s/chunk block it in exactly the states where its lookahead has been observed to stall and thrash, and never bind on its home family. fdash/pensieve/merina need no fence: they are never selected .", "EXPERTS LEFT UNROUTED (fdash, pensieve, merina) 2014 a deliberate, measurement-driven omission: none is the best expert in any measured family, and none is best in any sub-regime my features can actually separate. merina is a consistent runner-up (FCC-16 +0.880, Puffer-21 +1.032, Puffer-22 +0.609) but is dominated by pamoe in every one of them; pensieve is dominated everywhere; fdash owns the lowest stall time in 4 of 5 families (0.00s on Oboe, 0.02s on FCC-16) but pays for it with the lowest QoE in the pool everywhere, including the low-buffer regime where one might reach for it 2014 Puffer-22 runs at buf_med 5.3s and there pamoe still wins +0.658 vs fdash +0.511. Routing to an expert that no measurement crowns would trade real QoE for rules a human has to audit.", "STICKINESS margin 0.15 / min_dwell 4: expert alternation shows up directly in the smoothness penalty, and the pamoe-vs-mpc gap on FCC-18 is only 0.048 QoE 2014 far smaller than the cost of oscillating between two different policies near the boundary. A 4-chunk dwell (~16s of video) and a 15% weight margin mean mpc is only entered on a decisive, sustained High/Steady/Full reading.", "WARMUP: 5 steps (the window length of bw_mean_kbps and bw_cv) defaulting to pamoe 2014 the highest-mean expert overall and the correct blind fallback, so even the never-fires path degrades to the measured global best." ] C The Stage-2 Continual Round Prompt One full round of the second stage. The system half is fixed across all 48 rounds. The user half is rebuilt every round from the current page, the probe scores, and the evidence channels, and the one shown here is phase 2, round 3 (one validator message, logged in Chinese, is shown in English). The model’s answer to it is the single edit that moved the no-rule default from PA-MoE to MPC. The final rule base, as it stands after phase 3, closes the appendix. C.1 System prompt You are the maintainer of a fuzzy rule base that routes per-chunk decisions to one of several pre-trained adaptive bitrate (ABR) experts. Your job: propose a single small edit that improves the worst-case trace performance without breaking previously-passing traces. You will receive: ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model EditsConference’26, December 2026, Vietnam - The current rule base (membership functions + IF-THEN rules + meta). - A per-trace QoE summary (mean QoE per probe trace). - Where available, a fixed-expert trial table: what each expert scores on its own on the probe traces. - A worst-trace replay snippet (per-chunk: state features, chosen expert, per-step QoE). - The regression bank: traces with their historical-best QoE we must not regress on by more than tolerance. - The failed-direction ledger: brief one-liners about edits we already tried that broke regressions. The expert pool (all frozen; you only choose between them, you never modify them): - fdash: fuzzy-logic controller (no learned parameters) - pamoe: sparse mixture-of-experts policy – noisy top-k router over several expert heads, trained with PPO - pensieve: deep RL policy trained with PPO, using Pensieve's 6x8 history-matrix feature extractor - mpc: model-predictive control – harmonic-mean throughput prediction discounted by the worst recent prediction error, then a lookahead search over bitrate sequences (no learned parameters) - merina: meta-RL policy – a VAE encodes the recent bandwidth trace into a latent, which conditions a PPO policy Output: a single JSON object with one of these schemas, and nothing else (no prose, no code fences). "op": "add_rule", "antecedents": "bw_mean_kbps": "Low|Mid|High|VeryLow|MidHigh", "bw_cv": "Steady|Choppy|Volatile", "buf_s": "Critical|Healthy|Full", "dbuf_s": " Draining|Holding", "consequent": "fdash|pamoe|pensieve|mpc|merina", "rationale": "<<= 50 chars why" "op": "edit_rule", "index": <int>, "antecedents": ..., "consequent": "...", "rationale": "..." "op": "remove_rule", "index": <int>, "rationale": "..." "op": "retune_membership", "feature": "bw_mean_kbps|bw_cv|buf_s|dbuf_s", "label": "<existing label>", "breakpoints": [a, b, c, d], "rationale": "..." "op": "split_label", "feature": "bw_mean_kbps|bw_cv|buf_s|dbuf_s", "label": "<existing label>", "at": <number>, "new_label": "<new name>", "rationale": "..." "op": "set_meta", "path": ["stickiness", "margin"], "value": <number|string>, "rationale": "..." valid paths: ["stickiness", "margin"], ["stickiness", "min_dwell"], ["warmup", "steps"], ["warmup", "default"] "op": "noop", "rationale": "..." Rules of thumb you should follow: - Make ONE small edit per round. No giant rewrites. - Only consequent values from fdash, pamoe, pensieve, mpc, merina. Any of them is available – including experts that do not yet appear as a consequent anywhere in the current rule base. - Antecedents may use any subset of the features above; every label must already exist in the membership table shown to you. - Trapezoidal breakpoints must satisfy a <= b <= c <= d. - Avoid edits already on the failed-direction ledger. - Match the expert to the evidence, not to a fixed preference order. If a fixed-expert trial table is present, an expert that scores far above the current router on a probe trace is the strongest available signal about which consequent that trace's states need. - READ THE COVERAGE SECTION FIRST. If a probe reports a high "fire NO rule" fraction, or a feature whose observed values fall outside what the table covers, then no rule edit can change anything on that probe – the router is running the warmup default there. Fix the coverage first with retune_membership (widen the outermost label to reach the observed range), before proposing any rule. - When two probe traces need DIFFERENT experts but their states share the same label on every feature, no rule can separate them – narrowing the antecedent only lowers the firing strength. Use split_label to cut the shared label in two, then edit_rule the copy that landed on the new label. split_label with a single "at" value preserves the current behaviour exactly (it clones every rule that used the old label), so it is safe to spend one round on; the round after it is where you change the consequent. - Only split a label that the coverage section shows is actually OCCUPIED, and only at a cut point that leaves BOTH halves occupied. Splitting a label with ~0% occupancy, or cutting outside the observed range, costs a round and buys nothing: the split passes the accept test for free (it changes no score by construction) but no later rule edit on the new label can ever matter, because no state lands there. - Rule strength is the PRODUCT of the antecedent memberships, and each expert takes the MAX over its rules. A narrower antecedent is therefore always WEAKER. add_rule cannot outrank an existing broader rule with a different consequent – in a region already covered by a catch-all, use edit_rule or remove_rule instead. Respond with ONLY the JSON object. No prose. C.2 User prompt (phase 2, round 3) ## current rule base membership: bw_mean_kbps.Low = [0.0, 0.0, 889.99999911, 890.0] bw_mean_kbps.Mid = [900.0, 1500.0, 1999.999998, 2000.0] bw_mean_kbps.High = [4800, 6400, 100000, 100000] bw_mean_kbps.VeryLow = [889.99999911, 890.0, 900.0, 1500.0] bw_mean_kbps.MidHigh = [1999.999998, 2000.0, 4800.0, 6400.0] bw_cv.Steady = [0, 0, 0.1, 0.2] bw_cv.Choppy = [0.1, 0.2, 0.35, 0.55] bw_cv.Volatile = [0.35, 0.55, 5.0, 5.0] buf_s.Critical = [0, 0, 4, 8] buf_s.Healthy = [4, 8, 30, 42] buf_s.Full = [30, 42, 1000, 1000] dbuf_s.Draining = [-1000, -1000, -2.0, -0.5] dbuf_s.Holding = [-2.0, -0.5, 1000, 1000] Conference’26, December 2026, VietnamHe et al. rules: [0] IF bw_mean_kbps=High,bw_cv=Steady,buf_s=Full,dbuf_s=Holding THEN mpc [1] IF bw_mean_kbps=High,bw_cv=Steady,buf_s=Healthy THEN mpc [2] IF bw_mean_kbps=High,bw_cv=Steady,buf_s=Critical THEN pamoe [3] IF bw_mean_kbps=High,bw_cv=Choppy THEN mpc [4] IF bw_mean_kbps=Mid THEN pamoe [5] IF bw_mean_kbps=Low THEN pensieve [6] IF bw_mean_kbps=VeryLow THEN merina [7] IF bw_mean_kbps=MidHigh THEN pamoe meta: fence = ['expert':'mpc','require': ['feature':'bw_cv','max': 0.35, 'feature':'buf_s','min': 10.0, 'feature':'dbuf_s','min': -3.0]] stickiness = 'margin': 0.15,'min_dwell': 4 warmup = 'steps': 5,'default':'pamoe' ## probe & regression results per-trace mean QoE on probe set: ABRBench-3G-Train-Pool: 1.1556 Lumos4G-Train: 2.3070 regression bank (must keep QoE >= best - 0.050): ABRBench-3G-Train-Pool: best=1.1556 Lumos4G-Train: best=2.3070 ## fixed-expert trial fixed-expert trial – mean QoE if that expert ran alone on the whole trace: trace fdash pamoe pensieve mpc merina ABRBench-3G-Train-Pool 0.983 1.100 1.138 1.073 1.133 best=pensieve Lumos4G-Train -4.998 1.791 0.303 2.714 0.697 best=mpc ## rule coverage rule coverage – whether the feature values fall inside the membership table at all: ABRBench-3G-Train-Pool: 0.0% of chunks fire NO rule at all (the router then falls back to meta.warmup.default) bw_mean_kbps: observed min=883.4 p50=1432.6 max=4791.3 | table covers [0, 100000] label occupancy: Low=1%, Mid=2%, High=0%, VeryLow=49%, MidHigh=48% bw_cv: observed min=0.0 p50=0.1 max=0.6 | table covers [0, 5] <-- 2% of values have ZERO membership in every label of bw_cv; no rule using bw_cv can fire there label occupancy: Steady=52%, Choppy=38%, Volatile=7% buf_s: observed min=4.0 p50=15.5 max=33.7 | table covers [0, 1000] label occupancy: Critical=3%, Healthy=97%, Full=0% dbuf_s: observed min=-7.0 p50=0.5 max=3.7 | table covers [-1000, 1000] label occupancy: Draining=21%, Holding=79% Lumos4G-Train: 6.4% of chunks fire NO rule at all (the router then falls back to meta.warmup.default) bw_mean_kbps: observed min=5370.7 p50=18145.1 max=95545.3 | table covers [0, 100000] label occupancy: Low=0%, Mid=0%, High=99%, VeryLow=0%, MidHigh=1% bw_cv: observed min=0.0 p50=0.2 max=0.7 | table covers [0, 5] <-- 2% of values have ZERO membership in every label of bw_cv; no rule using bw_cv can fire there label occupancy: Steady=30%, Choppy=60%, Volatile=9% buf_s: observed min=4.0 p50=22.0 max=56.2 | table covers [0, 1000] label occupancy: Critical=2%, Healthy=69%, Full=29% dbuf_s: observed min=-10.9 p50=1.0 max=3.9 | table covers [-1000, 1000] label occupancy: Draining=21%, Holding=79% ## worst trace replay worst-trace per-chunk (first 20 chunks): chunk bw_mean bw_cv buf_s expert qoe 0 744 0.00 0.0 pamoe +0.300 1 703 0.06 0.0 pamoe +0.300 2 697 0.05 0.0 pamoe +0.300 3 713 0.06 0.0 pamoe +0.300 4 713 0.05 0.0 pamoe +0.300 5 703 0.05 0.0 pensieve +0.300 6 722 0.04 0.0 pensieve +0.300 7 719 0.05 0.0 pensieve +0.300 8 718 0.05 0.0 pensieve +0.300 9 718 0.05 0.0 pensieve +0.300 10 722 0.04 0.0 pensieve +0.750 11 718 0.04 0.0 pensieve +0.750 12 725 0.03 0.0 pensieve +0.750 13 632 0.27 0.0 pensieve -0.150 14 513 0.50 0.0 pensieve +0.300 15 407 0.64 0.0 pensieve +0.300 16 297 0.72 0.0 pensieve +0.300 17 196 0.29 0.0 pensieve -3.931 18 188 0.23 0.0 pensieve -4.313 19 209 0.12 0.0 pensieve -9.489 ## failed-direction memory ReForge: Keeping ABR Algorithms Never Finished with Verified Large Language Model EditsConference’26, December 2026, Vietnam - [phase1_3g_r2] parse/bad-edit: split_label: the split point must lie inside Low's plateau, i.e. 0.0 <= at0 <= at1 <= 900.0, got at=[1149.99999885, 1150.0] (Low = [0.0, 0.0, 900.0, 1500.0] - [phase1_3g_r3] ~ rule[7] -> 'bw_mean_kbps':'Low' -> merina: no improvement - [phase1_3g_r4] ~ rule[7] -> 'bw_mean_kbps':'Low' -> fdash: no improvement - [phase1_3g_r7] ~ rule[6] -> 'bw_mean_kbps':'Low' -> pamoe: no improvement - [phase1_3g_r9] ~ rule[6] -> 'bw_mean_kbps':'Low' -> fdash: no improvement - [phase1_3g_r10] ~ rule[6] -> 'bw_mean_kbps':'Low' -> merina: no improvement - [phase1_3g_r13] ~ rule[5] -> 'bw_mean_kbps':'Low' -> merina: no improvement - [phase1_3g_r14] ~ rule[5] -> 'bw_mean_kbps':'Low' -> fdash: no improvement - [phase1_3g_r15] ~ rule[5] -> 'bw_mean_kbps':'Low' -> mpc: no improvement - [phase1_3g_r16] ~ rule[5] -> 'bw_mean_kbps':'Low' -> pamoe: no improvement Output JSON edit (and only the JSON): C.3 Model output "op": "set_meta", "path": ["warmup", "default"], "value": "mpc", "rationale": "Lumos 6.4% no-rule chunks: mpc best there" C.4 The final rule base "features": "tp_kbps": "op": "throughput", "bw_mean_kbps": "op": "window_mean", "of": "tp_kbps", "window": 5, "bw_cv": "op": "window_cv", "of": "tp_kbps", "window": 5, "buf_s": "op": "obs", "field": "buffer_size_ms", "scale": 0.001, "dbuf_s": "op": "diff", "of": "buf_s" , "membership": "bw_mean_kbps": "Low": [0.0, 0.0, 399.9999996, 400.0], "Mid": [900.0, 1500.0, 1999.999998, 2000.0], "High": [4800, 6400, 100000, 100000], "VeryLow": [889.99999911, 890.0, 900.0, 1500.0], "MidHigh": [1999.999998, 2000.0, 2999.999997, 3000.0], "MidHighHi": [4599.9999954, 4600.0, 4800.0, 6400.0], "MidHighUp": [2999.999997, 3000.0, 4599.9999954, 4600.0], "DeepLow": [399.9999996, 400.0, 889.99999911, 890.0] , "bw_cv": "Steady": [0, 0, 0.1, 0.2], "Choppy": [0.1, 0.2, 0.35, 0.55], "Volatile": [0.35, 0.55, 5.0, 5.0] , "buf_s": "Critical": [0, 0, 4, 8], "Healthy": [4, 8, 30, 42], "Full": [30.0, 42.0, 49.99999995, 50.0], "Brimming": [49.99999995, 50.0, 1000.0, 1000.0] , "dbuf_s": "Draining": [-1000, -1000, -2.0, -0.5], "Holding": [-2.0, -0.5, 1000, 1000] , "rules": [ "antecedents": "bw_mean_kbps": "Mid", "consequent": "pamoe", "antecedents": "bw_mean_kbps": "Low", "consequent": "pensieve", "antecedents": "bw_mean_kbps": "VeryLow", "consequent": "merina", "antecedents": "bw_mean_kbps": "MidHigh", "consequent": "pamoe", "antecedents": "bw_mean_kbps": "MidHighHi", "consequent": "pamoe", "antecedents": "bw_mean_kbps": "MidHighUp", "consequent": "pamoe", "antecedents": "bw_mean_kbps": "DeepLow", "consequent": "pensieve", "antecedents": "buf_s": "Brimming", "consequent": "fdash" ], "meta": "fence": [ "expert": "mpc", "require": [ "feature": "bw_cv", "max": 0.35, "feature": "buf_s", "min": 10.0, "feature": "dbuf_s", "min": -3.0 ] ], "stickiness": "margin": 0.15, "min_dwell": 4, "warmup": "steps": 5, "default": "mpc" , "notes": [ Conference’26, December 2026, VietnamHe et al. "POLICY SHAPE FROM THE MEASUREMENTS: pamoe is the per-scenario best expert in 4 of 5 families (FCC-16 +0.909, Oboe +2.164, Puffer-21 +1.100, Puffer-22 +0.658) and has the best pool-wide mean QoE (1.546 vs mpc 1.462, merina 1.498, pensieve 1.463, fdash 1.364). mpc is the only expert that beats it anywhere: FCC-18-Train, +2.949 vs +2.901. So the entire routing problem reduces to: recognise the FCC-18-like regime and hand it to mpc; everywhere else delegate to pamoe. Every rule below exists to draw exactly that one boundary, plus its safety complement.", "WHY bw_mean_kbps (5-chunk window mean of observed goodput): this is the single strongest separator in the OBSERVED space. FCC-18 sits at tp_p05=6437 / tp_med=8479, while every other family's tp_p95 is at most 6846 (Puffer-21) and typically <=5775 (Oboe). The 4800->6400 ramp puts essentially all of FCC-18 at High=1.0 while Oboe (p95 5775) only reaches partial High and FCC-16 (max 1211) and Puffer-22 (max 2133) never leave Low/Mid. Without this feature mpc's home regime is invisible .", "WHY bw_cv (same 5-chunk window): goodput alone is NOT sufficient, because Puffer-21 reaches tp_p95=6846 / tp_max=8710 and would otherwise masquerade as FCC-18 \ u2014 and Puffer-21 is precisely where mpc is the WORST expert in the pool (+0.863 vs pamoe +1.100, with the highest stall 0.11s and the worst smoothness 0.306). The observed CV cleanly splits them: FCC-18 cv_med 0.080 / cv_p90 0.166 versus Puffer-21 cv_med 0.351 / cv_p90 0.735. This is the measurement that says mpc's harmonic-mean-plus-error-discount predictor is only trustworthy on a stationary link, so cv carries a rule antecedent AND a fence bound.", "WHY buf_s: FCC-18 runs with buf_med 52.2s and buf_p95 59.9s 2014 deeper than every other family (next highest median is Puffer-21 at 24.1s, Puffer-22 sits at 5.3 s). Deep buffer is both a co-signature of the mpc-favouring regime and the state in which an mpc lookahead mistake cannot turn into a stall. Restricting mpc to buf Full keeps the shallow-buffer tail of FCC-18 (buf_p05 8.3s) on pamoe, which costs nothing there (2.901 vs 2.949 is inside the noise) and removes the only way mpc could stall on its own home family.", "WHY dbuf_s: per-chunk buffer change is the earliest collapse signal, and it is family-discriminative in exactly the direction that matters 2014 FCC-18 dbuf_p05 is only -0.24s while Puffer-21 dbuf_p05 is -9.15s and FCC-16/Oboe reach about -2.6s. It carries no rule of its own beyond one handoff term: it hands the deep- buffer/high-goodput cell back to pamoe when the buffer is actually collapsing, and it backstops the fence at -3.0s/chunk. Cheap (one extra label pair), and it is the feature that prevents the fence from ever opening a hole.", "FEATURES DELIBERATELY NOT DECLARED: no bitrate/last-action feature, no remain_chunk, no chunk-size features. No measurement in A or B2 stratifies expert quality along those axes, and each would multiply the rule space a reviewer must read without buying discrimination.", "RULE GROUP 1 (rule 1) 2014 mpc's only home: High goodput AND Steady cv AND Full buffer AND not draining. This is the FCC-18 signature and nothing else in the training set lands there at full degree.", "RULE GROUP 2 (rules 2-6) 2014 the complement inside High goodput, all to pamoe: choppy or volatile link (Puffer-21's high-goodput bursts), shallow or critical buffer, or a deep buffer that is draining. This guarantees the High region is fully tiled, so when the fence drops mpc there is still a live rule and the router never falls through to the blind warmup path.", "RULE GROUP 3 (rules 7-8) 2014 Mid and Low goodput to pamoe unconditionally. This covers FCC-16 (tp 755-1211), Puffer-22 (tp_p05 272, tp_med 1045), Oboe's lower half (tp_p25 610) and Puffer-21's lower half (tp_med 1523) 2014 every family where pamoe is measured best, and where mpc is measured worst-or-near-worst (FCC-16 +0.838, Puffer-22 +0.507, both last in the pool).", "FENCE: mpc is the only guarded expert because it is the only high-variance expert the rules can select, and its variance is measured, not assumed 2014 it is best on FCC-18 (+2.949) and simultaneously last on FCC-16 (+0.838), Puffer-21 (+0.863) and Puffer-22 (+0.507), with the largest |delta bitrate| in 4 of 5 families (up to 0.306). The bounds cv<=0.35 (above Puffer-21's cv_med 0.351 boundary, far above FCC-18's cv_p90 0.166), buf>=10s and dbuf>=-3.0s/chunk block it in exactly the states where its lookahead has been observed to stall and thrash, and never bind on its home family. fdash/pensieve/merina need no fence: they are never selected .", "EXPERTS LEFT UNROUTED (fdash, pensieve, merina) 2014 a deliberate, measurement-driven omission: none is the best expert in any measured family, and none is best in any sub-regime my features can actually separate. merina is a consistent runner-up (FCC-16 +0.880, Puffer-21 +1.032, Puffer-22 +0.609) but is dominated by pamoe in every one of them; pensieve is dominated everywhere; fdash owns the lowest stall time in 4 of 5 families (0.00s on Oboe, 0.02s on FCC-16) but pays for it with the lowest QoE in the pool everywhere, including the low-buffer regime where one might reach for it 2014 Puffer-22 runs at buf_med 5.3s and there pamoe still wins +0.658 vs fdash +0.511. Routing to an expert that no measurement crowns would trade real QoE for rules a human has to audit.", "STICKINESS margin 0.15 / min_dwell 4: expert alternation shows up directly in the smoothness penalty, and the pamoe-vs-mpc gap on FCC-18 is only 0.048 QoE 2014 far smaller than the cost of oscillating between two different policies near the boundary. A 4-chunk dwell (~16s of video) and a 15% weight margin mean mpc is only entered on a decisive, sustained High/Steady/Full reading.", "WARMUP: 5 steps (the window length of bw_mean_kbps and bw_cv) defaulting to pamoe 2014 the highest-mean expert overall and the correct blind fallback, so even the never-fires path degrades to the measured global best." ]