{"id":"1cc17764-4532-49ff-8106-4562c951898c","arxiv_id":"2501.00446","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"DEHYDRATOR reduces provenance graph edge storage by 84.55% across seven datasets using field mapping, hierarchical encoding, and a transformer with an error-correction table.","lead":"This paper describes DEHYDRATOR, a system that shrinks audit-log provenance graphs by about 85% using field-level and hierarchical encoding plus a small transformer model. The significance is that security analysts could keep much longer system-activity histories for attack investigation on the same storage budget.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 16.17x advantage over Leonard is computed against Leonard's uncompressed ECT, while Leonard's actual on-disk artifact is gzip-compressed; applying the paper's own disk-usage metric to both systems changes the headline comparison.","rationale":"The reader's weakest assumption correctly identifies the ECT compression asymmetry as load-bearing. I agree with that assessment: the paper explicitly defines BPpost as disk usage, then measures Leonard using an uncompressed JSON file whose gzip-compressed version is reported in the same paragraph. This is not a minor footnote; it drives the 16.17x claim, because Leonard's ECT is the dominant component of its reported footprint and the specific number quoted is 53x larger than its actual compressed artifact. I also considered the omission of the node table and mapping table MT from both BPpre and BPpost. That is a real metric-completeness concern: queries need NTen and MT to return node information, and both are excluded from the stated BPpost. However, the paper explicitly scopes BPpre to the edge table (stating ET is >95% of graph size), and the absolute reduction figure is conservative in the sense that compressing Dehydrator's ECT would only make its own footprint smaller. The Leonard comparison is therefore the more decisive issue for the paper's headline. I did not find evidence of circular reasoning: the reduction is measured from stored artifacts, not derived from a fitted constant. There is also a secondary algebra slip in the Section IV-E derivation: with the stated bounds, the inequality BSETen >= BSEThi requires average degree at least 6, not 3, though the synthetic P1-P5 experiments empirically support the threshold near 3, and real datasets have average degree ~22. That error does not threaten the measured storage claim, so it is not the primary concern. The conditional verdict stands: the core system is plausible and the 84.55% edge-table reduction appears internally consistent, but the comparative evaluation needs to be redone on a common metric before the headline claims can be fully accepted.","tokens_in":23950,"tokens_out":10673,"duration_ms":108647,"concrete_test":"Reproduce the storage comparison on G1 (or all G1-G7): compute Dehydrator total bytes as MMT + DNN + gzip -9(ECT) and Leonard total bytes as model + gzip -9(ECT), matching the paper's own BPpost disk-usage definition. If the Dehydrator/Leonard ratio falls well below 16.17x, the abstract's comparative claim must be revised; report the ratio and also the resulting 84.55% figure with and without including NTen and MT in both numerator and denominator.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central comparison with Leonard in Section IV-B and Table IV is not apples-to-apples. The authors report Leonard at an average BPpost of 3,991 MB by counting the raw ECT JSON file (e.g., 3,592 MB for G1), yet in the same section they state that this ECT compresses to a 68 MB gzip file. Leonard's stored, queryable artifact is therefore the gzip-compressed ECT plus the model, roughly 69 MB for G1, not 3,592 MB. Dehydrator's BPpost, by contrast, counts its own ECT uncompressed, and the paper's stated metric for BPpost is disk usage. If both systems are measured by their actual on-disk artifacts, Leonard's footprint is about 69 MB for G1, while Dehydrator's is 247 MB on average, so the 16.17x ratio is an artifact of comparing Dehydrator's stored files against Leonard's decompressed intermediate file. This does not by itself refute the 84.55% absolute reduction of the edge table, but it invalidates the third headline comparative claim and materially overstates the advantage over the closest prior work, especially since ECT dominates Dehydrator's BPpost (over 90%) and would itself compress substantially under gzip.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Dehydrator, a provenance-graph storage system that combines three stages: field mapping encoding to remove field-level redundancy, hierarchical encoding to compress incoming-edge structure, and a single-layer decoder-only transformer with an error-correction table (ECT) to support batch queries. The evaluation on seven DARPA TC/DEPIMPACT provenance graphs reports a post-storage average of 247 MB against a pre-storage edge-table average of about 1,599 MB, i.e., an 84.55% reduction, and claims 7.36x, 7.16x, and 16.17x storage-efficiency improvements over PostgreSQL, Neo4j, and Leonard, respectively. The paper also studies the contribution of each component, the impact of model capacity through a Latency-to-Storage Ratio (LSR) metric, and the applicability of hierarchical encoding as a function of average degree.","tokens_in":24224,"tokens_out":15934,"duration_ms":135474,"significance":"If the reported reductions are reproducible, this is a useful contribution to cold storage of provenance graphs: it targets structure-level redundancy, which prior encoding-based systems address only partially, and it evaluates on substantially larger graphs than the closest learned-storage baseline. Strengths include the use of seven public datasets, an ablation of the encoding components, the explicit ECT mechanism for losslessness, and the introduction of LSR as a way to reason about the storage-latency tradeoff. The central edge-table reduction is an empirical result and does not appear to be forced by a fitted constant. However, the headline comparison with Leonard is not a normalized disk-usage comparison, and two technical points in the algorithm and the applicability derivation need correction before the central claims can be accepted as stated.","major_comments":[{"comment":"The 16.17x claim against Leonard is not an apples-to-apples disk-usage comparison. The paper itself states that Leonard's 3,592 MB ECT for G1 compresses to a 68 MB gzip file, so Leonard's actual stored and queryable artifact is the gzip ECT plus the 0.9 MB model, about 69 MB for G1. Dehydrator's BPpost, by contrast, counts its own ECT, MMT, and DNN uncompressed (60.9 MB for G1, 247 MB on average). Measured by the paper's own BPpost definition, i.e., bytes on disk, the G1 ratio is roughly 69/60.9, not 3,592/60.9, and the average 16.17x ratio is an artifact of comparing Dehydrator's stored files against Leonard's decompressed intermediate JSON. The defense in §IV-B that raw ECT must be counted because decompression and loading take 138 s is a query-latency argument, not a storage-metric argument, and it is applied asymmetrically. This invalidates the third headline comparative claim, although it does not by itself refute the absolute edge-table reduction.","section":"§IV-B, Table IV"},{"comment":"In Algorithm 1, startTime and endTime are computed inside the loop over v but after the inner loop over u, using Dict[(u, v)] where u is the last parent processed. This means the min/max timestamps are taken over edges of only the last parent, not over all incoming edges of v. The correct source for these extremes is the accumulated Ev list (or all pairs in Dict[v]). As printed, the pseudocode corrupts the temporal interval for every multi-parent node, and since timeOffset is defined as e.timestamp - startTime, the reconstructed edge timestamps would be wrong; this undermines the content-lossless claim. Please fix the pseudocode, and verify that the implementation computes startTime and endTime over all incoming edges.","section":"Algorithm 1, lines 16-17"},{"comment":"The derivation of the d_avg >= 3 applicability threshold rests on the assertion sum_v m_v^o <= 3n, justified by 'a node can have at most 3 operations of incoming edges.' The paper's own Table I lists at least five operation types (Read, Write, Execute, Sendto, Recvfrom, Fork), and different node types can receive different subsets, so a universal bound of 3 is not supported. Replacing the constant 3 by the actual vocabulary size O gives, under the paper's other bounds, a threshold of roughly (O+3)/2 for m/n, not a fixed threshold of 3. The synthetic P1-P5 experiments may still show threshold 3 for their generated data, but the analytical claim in Eq. (5) is incorrect as stated, and the experiments should report the operation vocabulary used so the reader can see why the bound holds there.","section":"§IV-E, Eqs. (4)-(5)"}],"minor_comments":[{"comment":"Typos and formatting issues should be corrected: 'Fisrtly' in §III-B1, 'Grpahs' in the §IV-C heading, and 'Sgement Length' in Table VI.","section":"§III-B1, §IV-C, Table VI"},{"comment":"Table IV is difficult to parse as rendered because Leonard's BPpost and Ts are split into DNN/ECT and Train/Correct without explicit subheaders, and the same is true for Dehydrator's MMT/DNN/ECT and HE/Train/Correct columns. Add clear multi-level column headers so the sums shown in the text are unambiguous.","section":"Table IV"},{"comment":"The abstract's 'reduces the storage space by 84.55%' should be qualified as edge-table storage: the paper explicitly equates BPpre with ET and excludes the node table. Although ET dominates, the current wording overstates the reduction for the full provenance graph.","section":"§IV-A and Abstract"},{"comment":"Leonard is excluded from the query comparison because loading its ECT takes several minutes, but the paper does not report that load/decompression time in Table V nor the memory footprint. Either report it as part of the query cost or state explicitly that the comparison excludes cold-start overhead for all systems.","section":"§IV-C"},{"comment":"The claim that DNNs 'inherently support batch queries' is not supported by any experiment in the paper. Add a batch-mode query experiment or qualify the claim to refer to the potential for parallel generation.","section":"§III-C"},{"comment":"The paper states that code and data will be open-sourced upon publication. Provide an artifact repository or a clear availability plan in the revision, especially because the correctness of Algorithm 1 and the ECT procedure can only be fully checked against the implementation.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The Leonard comparison is the main headline risk. The asymmetry is stark: the authors report Leonard's raw uncompressed ECT while counting Dehydrator's own ECT and other components uncompressed, even though they know Leonard's ECT gzips to 68 MB for G1. I also found a likely bug in Algorithm 1 for startTime/endTime, which suggests the artifact should be requested before any accept decision. The dataset scale, component ablation, and the LSR analysis are valuable, so I do not see these as fatal flaws; they are substantive but fixable within the scope of a revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dehydrator is a serious systems paper with a genuinely new encoding idea, but the headline comparison against Leonard is not apples-to-apples. The 16.17x claim counts Leonard's raw uncompressed ECT while Leonard actually stores a gzip-compressed file, and Dehydrator's own ECT is also uncompressed. Under a symmetric on-disk metric, the advantage likely reverses.\n\nThe genuinely new piece is hierarchical encoding: grouping all incoming edges of a node by operation, time offset, and source node, then feeding that compact structure to a single-layer transformer with an error-correction table. That's a real extension of the ELISE/Leonard line, and the evaluation on seven datasets with over a billion log entries is substantial. The derivation of the davg >= 3 applicability threshold is a nice analytical touch, and the paper is honest about being a cold-storage system with query latency well above Neo4j's.\n\nThe main soft spot is the Leonard comparison. The authors explicitly report Leonard at 3,991 MB by counting the raw ECT JSON file, but they also note that Leonard's ECT gzip-compresses from 3,592 MB to 68 MB for G1. Leonard's actual stored artifact is that gz file plus the model, about 69 MB, while Dehydrator's BPpost counts its own uncompressed ECT (over 90% of its bytes), averaging 247 MB. So the 16.17x ratio compares Dehydrator's on-disk footprint to Leonard's decompressed intermediate. If you applied gzip to Dehydrator's ECT, the ratio would shrink or flip. This doesn't refute the absolute 84.55% reduction of the edge table, but it invalidates the third headline claim.\n\nSecondary issues: no code or data released yet, no error bars or run-to-run variance, and query evaluation stops at depth 4 with Dehydrator slower than PostgreSQL and far slower than Neo4j. The authors acknowledge the inference bottleneck and position the system for append-only cold data, which is fair but narrows the practical impact.\n\nWho this is for: researchers in provenance graph storage or learned storage systems. The central technique is plausible and the evaluation is large enough to warrant referee time, but the metric problem needs a major revision. I'd recommend conditional acceptance after the authors redo the Leonard comparison with both systems measured as stored on disk, and ideally report gzip-compressed sizes for Dehydrator's ECT as well.","headline":"A genuinely new encoding for provenance graph storage, but the 16.17x claim over Leonard is an artifact of comparing against Leonard's uncompressed ECT.","tokens_in":24732,"tokens_out":4544,"would_cite":false,"duration_ms":39332,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Dehydrator claims lossless provenance graph storage at one-sixth the original size while keeping queries exact.","keywords":["provenance graph","storage compression","hierarchical encoding","field mapping encoding","sequence generation","error correction table","causality analysis","audit log"],"falsifier":"Compress Dehydrator's three stored artifacts (merge mapping table, model weights, and error-correction table) with gzip or zstd and compare the total against the reported 247 MB and against the closest baseline's compressed footprint; if the compressed total approaches or exceeds the baselines' totals, the 84.55 percent and 16.17x claims do not survive a uniform compression metric.","tokens_in":23774,"feed_emoji":"🗜️","tokens_out":8942,"duration_ms":83959,"temperature":0.7,"pith_summary":"This paper proposes Dehydrator, a storage system for provenance graphs built from kernel audit logs, and argues that it can store such graphs losslessly in about one-sixth of their original space while still answering the reverse queries analysts use for attack investigation. Across seven datasets with over one billion log entries, the paper reports an average reduction of 84.55 percent, from roughly 1,598 MB of edge-table data to 247 MB of stored artifacts. The reason the reduction is possible, the paper argues, is that provenance graphs carry two distinct kinds of redundancy: repeated field values within entries and repeated structure across the many parallel edges connecting the same node pair. Dehydrator removes both kinds before training a small transformer to regenerate the encoded edge information on demand, with an error-correction table guaranteeing that every returned query is exact. If the claim holds, provenance storage can be made dramatically cheaper without forcing the lossy pruning that earlier compression approaches accept.","feed_headline":"Provenance graphs stored 84.55 percent smaller with query support","feed_subtitle":"A small transformer regenerates compactly encoded edges, with an error-correction table fixing any misprediction.","key_machinery":"The load-bearing object is the hierarchical edge table $ET_{hi}$ produced by Algorithm 1. For each node $v$, Dehydrator stores a record $[v, startTime, endTime, U_v, MergedEdge]$, where $U_v$ indexes the distinct source nodes and $MergedEdge$ is a nested list $[Operation:[timeOffset:[nodeOffset]]]$ that folds all incoming edges into one dense structure. This encoding converts the storage problem from storing each edge separately into storing one compact record per node, which raises information density enough that a small transformer can fit the data in a few epochs. The error-correction table, which records mismatches between model output and true data, then makes the system content-lossless even when the model is imperfect.","core_discovery":"Dehydrator's central claim is that structure-level redundancy, not field-level redundancy, dominates the storage cost of provenance graphs, and that eliminating it through hierarchical encoding makes DNN-based lossless storage practical. The system first maps unique, repetitive, and incremental field values to short codes and offsets, then regroups the encoded edge table so that each node appears once with all of its incoming edges merged into a nested list keyed by operation, time offset, and source-node offset. A single-layer decoder-only transformer is trained on these dense sequences, and an error-correction table records every position where the model's generated output differs from the true data, so queries combine model output with table corrections to return exact results. On the seven evaluated datasets the stored size drops from an average of about 1,598 MB to 247 MB, which the paper reports as an 84.55 percent reduction, and as 7.36x smaller than PostgreSQL, 7.16x smaller than Neo4j, and 16.17x smaller than Leonard.","pith_inferences":["The 84.55 percent headline likely depends on the choice to measure Dehydrator's error-correction table uncompressed while the closest baseline is compared using its own reported sizes; applying gzip or zstd to Dehydrator's stored artifacts could change the comparison, since the error-correction table dominates Dehydrator's footprint.","The same hierarchical encoding idea should transfer to other high-degree directed graphs such as dependency graphs and system call traces, where parallel edges between entity pairs are common; a testable extension is to run Dehydrator's pipeline on non-security provenance graphs and check whether the degree-3 threshold still predicts when encoding helps.","Because model inference accounts for over 99 percent of query latency, non-autoregressive generation or speculative decoding could make Dehydrator competitive with graph databases on reverse BFS queries without changing its storage format.","An adaptive error-correction scheme that corrects at the sub-sequence level rather than the character level could cut the error-correction table further, pushing the stored footprint below the reported 247 MB average."],"forward_implications":["Average storage overhead on the seven datasets falls from about 1,598 MB to 247 MB, a reported 84.55 percent reduction.","Under the paper's metric, Dehydrator stores edge tables 7.36x more compactly than PostgreSQL, 7.16x more compactly than Neo4j, and 16.17x more compactly than Leonard.","Reverse causality queries at depths 1 through 4 complete in times comparable to PostgreSQL, while Neo4j remains faster; beyond depth 4, autoregressive generation becomes prohibitively slow.","Hierarchical encoding is shown to be beneficial only when the average node degree is at least 3, giving Dehydrator a clear applicability boundary and a lower-bound regime at degree 1.","The Latency-to-Storage Ratio peaks at a dataset-dependent model capacity, so the system has an operating point chosen by trading storage size against storage latency."],"supporting_citations":[{"why":"Closest DNN-based provenance storage baseline; the paper compares Dehydrator's 16.17x storage improvement against Leonard's reported sizes and questions Leonard's gzip-compressed ECT metric.","marker":"[40]"},{"why":"Prior system combining high-frequency field mapping encoding with representation learning, which Dehydrator extends with hierarchical encoding.","marker":"[39]"},{"why":"SEAL's query-friendly compression of repeated fields motivates the field mapping encoding stage.","marker":"[37]"},{"why":"Encoding-based provenance storage achieving about 10 bytes per event, used as design context for compact edge representation and reverse causality queries.","marker":"[38]"},{"why":"DeepZip shows DNNs can model compression as sequence prediction, the conceptual basis for learned storage.","marker":"[33]"},{"why":"Transformer architecture from which the single-layer decoder-only model is drawn.","marker":"[59]"},{"why":"char2vec converts encoded edge strings into numerical vectors for model training.","marker":"[70]"},{"why":"DEPIMPACT dataset supplies G7 and illustrates the dependence explosion that motivates reverse BFS query support.","marker":"[48]"},{"why":"DARPA TC E3 datasets (G1-G4) are the evaluation source for most storage experiments.","marker":"[45]"},{"why":"SPADE framework collected the provenance logs for datasets G1-G6.","marker":"[72]"}],"fun_headline_variants":["Provenance graphs shrunk 84.55% by Dehydrator encoding","Deep sequence model cuts provenance graph storage 84.55%","Dehydrator: hierarchical encoding makes provenance graphs 84.55% smaller","Transformer-driven storage reaps 84.55% provenance graph savings","Learn to encode provenance graphs: storage down 84.55%"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The headline storage comparison assumes that measuring Dehydrator's error-correction table in uncompressed bytes while using the closest baseline's reported sizes is the right metric; because the error-correction table makes up over 90 percent of Dehydrator's stored size, a standard compressor applied to both systems' artifacts could shrink the claimed advantage.","fun_headline_variants_meta":{"raw":{"variants":["Provenance graphs shrunk 84.55% by Dehydrator encoding","Deep sequence model cuts provenance graph storage 84.55%","Dehydrator: hierarchical encoding makes provenance graphs 84.55% smaller","Transformer-driven storage reaps 84.55% provenance graph savings","Learn to encode provenance graphs: storage down 84.55%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000172,"raw_usage":{"total_tokens":1276,"prompt_tokens":948,"completion_tokens":328,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":564,"completion_tokens_details":{"reasoning_tokens":233}},"tokens_in":564,"tokens_out":328,"duration_ms":3304,"temperature":1.0,"reasoning_tokens":233,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T22:51:03.692680+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Compress Dehydrator's three stored artifacts (merge mapping table, model weights, and error-correction table) with gzip or zstd and compare the total against the reported 247 MB and against the closest baseline's compressed footprint; if the compressed total approaches or exceeds the baselines' totals, the 84.55 percent and 16.17x claims do not survive a uniform compression metric.","supporting_citations":[{"cited_title":"{Back-Propagating} system dependency impact for attack investigation,","cited_arxiv_id":null,"evidence_quote":"DEPIMPACT dataset supplies G7 and illustrates the dependence explosion that motivates reverse BFS query support."},{"cited_title":"{ELISE}: A storage efficient logging system powered by redundancy reduction and representation learning,","cited_arxiv_id":null,"evidence_quote":"Prior system combining high-frequency field mapping encoding with representation learning, which Dehydrator extends with hierarchical encoding."},{"cited_title":"{SEAL}: Storage- efficient causality analysis on enterprise logs with query-friendly com- pression,","cited_arxiv_id":null,"evidence_quote":"SEAL's query-friendly compression of repeated fields motivates the field mapping encoding stage."},{"cited_title":"{SLEUTH}: Real- time attack scenario reconstruction from {COTS} audit data,","cited_arxiv_id":null,"evidence_quote":"Encoding-based provenance storage achieving about 10 bytes per event, used as design context for compact edge representation and reverse causality queries."},{"cited_title":"A Joint Model for Word Embedding and Word Morphology","cited_arxiv_id":"1606.02601","evidence_quote":"char2vec converts encoded edge strings into numerical vectors for model training."},{"cited_title":"Darap3 transparent engagement 3,","cited_arxiv_id":null,"evidence_quote":"DARPA TC E3 datasets (G1-G4) are the evaluation source for most storage experiments."},{"cited_title":"Spade: Support for provenance auditing in distributed environments,","cited_arxiv_id":null,"evidence_quote":"SPADE framework collected the provenance logs for datasets G1-G6."}],"review_version":1}