{"id":"055926c0-12fa-4bee-8bdb-134caebc4d2d","arxiv_id":"2607.05476","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A parameter-free relational encoder combined with a single-table foundation model matches or beats parameterized, pre-trained RDB encoders on six benchmarks.","lead":"Relational-database foundation models typically rely on trained encoders to embed tables, but this paper shows that a simple rule-based encoder paired with a pretrained single-table model remains competitive. Across six benchmark suites, their pipeline (RDBLearn v1.1) beat all open-source rivals and closed-source systems on four of the six.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Validation-based aggregation selection contradicts the 'no task-specific adjustments' claim; reported RDBLearn superiority may depend on this selection, not the parameter-free encoder alone.","rationale":"The reader's formal weakest_assumption targets the expressiveness of fixed vertical SQL aggregations, which is a valid concern about generality. However, the reader's rationale also flags the gap between 'no task-specific adjustments' and validation-based selection of aggregations as 'the biggest concern.' I consider this validation-selection inconsistency more load-bearing because it directly affects the interpretation of the reported benchmark superiority: the main evidence for the paper's viability claim is empirical, and a core encoder component is selected using validation labels, contradicting the paper's own no-adjustment rhetorical framing. It also creates an asymmetry with baselines that may not have received equivalent per-task validation tuning. The proposed ablation is a single, decisive check: if the minimal no-validation RDBLearn matches the v1.1 results, the concern is resolved and the central claim stands with the current conditional acceptance; if not, the claim should be downgraded to 'viable only with task-specific aggregation selection,' which is a materially weaker statement. I am not alleging any misconduct; the issue is purely that an unquantified model-selection step prevents attribution of the empirical outcome to the parameter-free design. The paper's theoretical results remain as stated, but they do not by themselves establish the empirical superiority, so the empirical demonstration must be cleanly attributable. For these reasons, I keep the reader's conditional verdict but would require the ablation as a condition for the stronger 'no task-specific adjustments' claim.","tokens_in":18289,"tokens_out":8546,"duration_ms":96270,"concrete_test":"Re-run all six benchmark suites with the base RDBLearn v1.1 pipeline using only the original minimal aggregation set (mean, min, max, std, count, median) and no validation-based selection, while keeping the same downstream single-table FM. Compare average ranks and per-benchmark metrics to the reported v1.1 results and to the open/closed-source baselines. If performance degrades substantially (e.g., average rank worsens by more than 1 position or falls below KumoRFM-2/TabPFN-REL), the reported advantage is attributable to validation-based aggregation selection rather than to the parameter-free design; if performance holds, the 'no task-specific adjustments' claim is restored.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central empirical claim is that RDBLearn v1.1, with a parameter-free encoder, outperforms other FMs while being run 'with no task-specific adjustments' (Section 5). However, Appendix A states: 'When available, the validation set performance is used to select between the original aggregations and the expanded group listed here.' This is a task-specific, validation-driven choice of the encoder's aggregation set — a core component of the parameter-free representation. It means the pipeline is not fully task-agnostic, and the strong 'no adjustments' statement is inaccurate. Since the paper provides no ablation of this selection, the reported advantage could stem from per-benchmark validation tuning rather than from the parameter-free encoding principle. This is especially consequential because the same Section 5 uses 'zero exposure to RDB data' as a rhetorical guarantee, yet validation labels are task-specific RDB signal used to pick the aggregation family. The theory (Propositions 3.1/4.1) argues labels do not help fix encoder column-screening, but the empirical protocol in effect uses labels to choose between aggregation families, creating an unexamined tension. Unless this selection is shown to be unnecessary, the viability claim is conditional on a validation-based adjustment that has not been isolated.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper argues that parameter-free RDB encoders, when paired with single-table in-context-learning foundation models, remain competitive with parameterized, RDB-pretrained encoders. It contributes two propositions in the style of impossibility/existence results concerning the use of neighborhood labels as encoder inputs, and supports the thesis empirically with an updated RDBLearn v1.1 evaluated on six benchmark suites (SALT, RelBench-v1, RelBench-v2, 4DBInfer) against open-source and closed-source baselines. The central empirical claim is that RDBLearn outperforms all open-source foundation models on the considered benchmarks and exceeds closed-source models on four of six.","tokens_in":18566,"tokens_out":6923,"duration_ms":76914,"significance":"If the claim holds, the paper meaningfully simplifies RDB foundation-model design by showing that RDB-specific pretraining of encoder parameters is not necessary for strong performance. Strengths include explicit proof constructions in Appendix D, a publicly released implementation (RDBLearn v1.1), and evaluation over six diverse benchmark suites with many baselines. The paper also acknowledges the two RelBench-v1 benchmarks where closed-source models do better. The main weakness is that the empirical protocol is less clean than the headline 'no task-specific adjustments' claim suggests, because Appendix A discloses validation-based selection of the aggregation set. The theoretical propositions are correctly framed as existence results and are self-contained, though they are not strong enough to explain the empirical success by themselves.","major_comments":[{"comment":"The claim that RDBLearn was run 'with no task-specific adjustments and zero exposure to RDB data of any kind at any stage' is contradicted by Appendix A: 'When available, the validation set performance is used to select between the original aggregations and the expanded group listed here.' Choosing between aggregation sets using a per-benchmark validation split is a task-specific adjustment to the core encoder, and validation labels are task-specific RDB signal. No ablation is provided to show that the rankings in Figure 1 and Tables 1-6 are invariant to this choice. Please add a fixed-aggregation comparison (e.g., always use the expanded set) and/or revise the claim; otherwise it is unclear whether the reported advantage reflects the parameter-free encoding principle or a validation-driven model selection.","section":"Section 5 / Appendix A"},{"comment":"The paper does not specify which base single-table FM produced the results in Tables 1-6. Appendix A adds TabICL-v2 and TabPFN-v3, while the stated default for benchmarks without validation splits is TabPFNv2.5. Since the parameter-free encoder's output is consumed entirely by the base FM, the choice of base model is a substantial confound. A per-benchmark configuration table is needed, including how the two added base models were combined (if at all). Without this, the comparison to published KumoRFM-2 and TabPFN-REL results is under-specified.","section":"Appendix A, 'Base Model Predictors' / 'Default Setting'"}],"minor_comments":[{"comment":"The sentence 'where relevance is largely indeterminate adequate label information' appears to be missing a word; it should probably read 'indeterminate without adequate label information.'","section":"Section 2.4"},{"comment":"Typo: 'validaion-set' should be 'validation-set'.","section":"Appendix B.3"},{"comment":"The caption contains a stray '#' in 'lower is better #'.","section":"Figure 1"},{"comment":"Formatting issue: '0.6210.16' should be separated into two numbers, and several entries appear as '1' instead of '1.00'.","section":"Table 2"},{"comment":"No confidence intervals or repeated-seed results are reported. Many comparisons differ by less than one point in AUROC or MAE (e.g., Table 3, mimic-stay: 55.40 vs 56.33), so the rank-based conclusions should be interpreted as point estimates.","section":"Tables 1-6"}],"recommendation":"major_revision","confidential_remarks":"The paper is a reasonable workshop-length contribution and the central viability claim is likely defensible. The main blockage is the inconsistency between the 'no task-specific adjustments' guarantee and the validation-based aggregation selection in Appendix A. If the authors add a fixed-aggregation ablation and clarify the per-benchmark base-FM configuration, the paper could be acceptable; without these, the empirical headline is overstated."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things about this paper. First, it is a genuinely useful update to the RDBLearn program: two new existence propositions about labels-as-input, a wider empirical comparison with newer single-table FMs, and a straightforward writing style that flags its own limitations. Second, the stress-test about validation-based aggregation selection lands. Appendix A says, \"When available, the validation set performance is used to select between the original aggregations and the expanded group.\" That is a task-specific choice about a core part of the encoder's representation, so Section 5's \"no task-specific adjustments\" claim is inaccurate as written. It is not a fatal flaw—the encoder is still parameter-free, and the choice is only between two fixed aggregation sets—but there is no ablation showing the choice is immaterial, and the reported rankings could depend on it.\n\nWhat is actually new: Proposition 3.1 shows a fixed encoder cannot generally exploit neighborhood labels as discriminative features; Proposition 4.1 shows such labels do not help a fixed encoder adjudicate which columns matter. The proofs are adversarial parity constructions, so they are existence results rather than deep theory, but they are correct, self-contained, and well explained—the appendix gives real constructions, not hand-waving. The empirical comparison is broader than the prior paper: updated aggregations, TabICL-v2 and TabPFN-v3 as base models, and six benchmark suites. The paper also does something rare: it openly discusses the leakage risk in LLM-agent baselines and the uncertainty around KumoRFM-2's per-task hyperparameters.\n\nSoft spots, in proportion. The validation-selection issue is the main one; a quick experiment with a fixed aggregation set, or a table showing both choices give similar rankings, would fix it. There are also no error bars or significance tests, and most baseline numbers are taken from other papers, so the comparisons are only as reliable as those sources. The theory is worst-case, which makes it a useful caution against parameterized-encoder hype but not a guide to average-case performance. Finally, six benchmarks is a small sample; the authors implicitly acknowledge this when cautioning about extrapolation.\n\nWho is this for? Anyone working on relational database foundation models, especially those deciding whether RDB-specific pre-training is necessary. It deserves a serious referee: the question is relevant, the methodology is mostly sound, and the central claim—that a parameter-free vertical-aggregation encoder paired with a strong single-table FM remains competitive—is supported conditional on the aggregation-selection caveat. I would send it to review rather than desk-reject, and I would ask the authors to address the ablation in the revision.","headline":"Solid, honest follow-up on parameter-free RDB encoders; the core empirical claim holds with caveats, but the 'no task-specific adjustments' line is overstrong because validation performance is used to pick the aggregation family.","tokens_in":19028,"tokens_out":2770,"would_cite":true,"duration_ms":31640,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper argues that simple, parameter-free encoders—fixed column-wise SQL aggregations paired with single-table foundation models—remain at least as good as pre-trained, parameterized relational encoders, and proves theoretical limits on","keywords":["relational database foundation models","parameter-free encoders","in-context learning","RDBLearn","tabular foundation models","label propagation","SQL aggregation","pre-training-free"],"falsifier":"Find or construct an RDB benchmark where the target is an XOR or cross-column interaction of two or more feature columns (so that any per-column aggregation loses the signal), and show that a pre-trained parameterized encoder such as KumoRFM-2 solves it while RDBLearn v1.1 clearly fails, despite a supervised model on the raw rows succeeding.","tokens_in":18181,"feed_emoji":"🗄️","tokens_out":5249,"duration_ms":53382,"temperature":0.7,"pith_summary":"The paper is trying to establish that the added complexity of pre-trained, parameterized encoders for relational databases (RDBs) does not deliver a principled advantage over a much simpler, parameter-free design. It proves two information-theoretic limitations: a frozen encoder cannot reliably exploit label information in neighborhood subgraphs (Proposition 3.1), and labels cannot help an encoder figure out which feature columns matter (Proposition 4.1). Empirically, RDBLearn v1.1, using only fixed SQL aggregations plus a strong single-table foundation model, beats all open-source foundation models on all six benchmarks and beats closed-source ones on four of six. A sympathetic reader would care because it suggests RDB-specific pre-training may be unnecessary for many tasks, and that the frontier is in the single-table FM and aggregation design rather than the RDB encoder.","feed_headline":"RDBLearn beats all open-source rivals with no RDB pre-training","feed_subtitle":"Parameter-free SQL aggregations beat every open-source rival and most closed-source relational models.","key_machinery":"The central object is the parameter-free encoder of RDBLearn: it compresses relational context vertically within each column using a fixed set of SQL aggregations (mean, min/max, count, quantiles, etc.), avoiding any cross-column mixing. This 'vertical compression' design is paired with in-context learning via single-table foundation models (TabPFN-v3, TabICL-v2). The theoretical results hinge on adversarial constructions using parity (XOR) functions over labels or feature supports to show indistinguishability: no fixed encoder can extract the required signal from the given subgraph, and labels add no information about the support set.","core_discovery":"The paper demonstrates through constructed distributions that any fixed encoder/prediction-head combination is limited when neighborhood labels are used as features: for certain deterministic labeling rules (e.g., parity checks), the encoder cannot do better than chance at test time, while task-specific supervised learning can fit the training labels perfectly (Proposition 3.1). Similarly, even when labels are provided as inputs, they carry no information about which feature columns constitute the true generative support, so labels cannot enable a trainable encoder to do feature screening (Proposition 4.1). Empirically, the authors show that RDBLearn v1.1, a parameter-free encoder with expan","pith_inferences":["The theoretical results suggest that adding label-derived aggregate features (e.g., label proportions in the neighborhood) to parameter-free encoders like RDBLearn could yield further gains without undermining their design — a direction the paper leaves open.","The empirical viability claim is limited to the benchmarks tested; on tasks requiring non-additive cross-column interactions (e.g., XOR of two columns), the parameter-free vertical aggregation approach may be insufficient, potentially leaving room for parameterized encoders.","The parity-based impossibility results may generalize: any frozen representation that is fixed across tasks cannot robustly exploit task-specific label relationships, a principle that extends beyond RDBs to other foundation-model settings."],"forward_implications":["RDB-specific pre-training is not a prerequisite for strong performance; training-free pipelines remain competitive.","Adding neighbor labels to encoders does not, by itself, justify parameterized encoders; a fixed aggregation of labels may be just as useful.","Performance gains may come from improving single-table foundation models and aggregation sets rather than RDB encoder complexity.","Existing closed-source pre-trained RDB FMs may not offer a fundamental advantage on standard benchmarks, suggesting effort can be redirected to open approaches.","The theoretical results constrain the design space: any future encoder that uses labels must do so in a way that is task-adaptive (e.g., through ICL) rather than static."],"fun_headline_variants":["Parameter-free SQL encoders beat pre-trained rivals","No pre-training? No problem: RDB encoders still win","RDBLearn: no pre-training, still beats all rivals","Why train RDB encoders when simple, parameter-free works?","Simple RDB encoders outperform without pre-training"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The parameter-free encoder relies on fixed aggregations computed within individual columns; if a prediction task requires combining information across columns or across tables in a way these aggregates cannot express, the parameter-free design will fail regardless of the downstream single-table model.","fun_headline_variants_meta":{"raw":{"variants":["Parameter-free SQL encoders beat pre-trained rivals","No pre-training? No problem: RDB encoders still win","RDBLearn: no pre-training, still beats all rivals","Why train RDB encoders when simple, parameter-free works?","Simple RDB encoders outperform without pre-training"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001037,"raw_usage":{"total_tokens":4174,"prompt_tokens":691,"completion_tokens":3483,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":435,"completion_tokens_details":{"reasoning_tokens":3415}},"tokens_in":435,"tokens_out":3483,"duration_ms":33174,"temperature":1.0,"reasoning_tokens":3415,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-02T08:30:03.557355+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Find or construct an RDB benchmark where the target is an XOR or cross-column interaction of two or more feature columns (so that any per-column aggregation loses the signal), and show that a pre-trained parameterized encoder such as KumoRFM-2 solves it while RDBLearn v1.1 clearly fails, despite a supervised model on the raw rows succeeding.","supporting_citations":[],"review_version":2}