Pith. sign in

REVIEW 3 major objections 4 minor 1 cited by

Learning Lineage Constraints for Data Science Operations

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This vision paper proposes that data lineage for unknown, black-box operations can be learned from small perturbed examples, without ever seeing intermediate data states.

desk verdict A well-scoped vision for cross-library lineage with a novel tag-based IR, but the small-container learning mechanism has a real blind spot for value-triggered operations like the paper's own dropna example. read the letter →

arxiv 2506.18252 v1 pith:IE45WWKH submitted 2025-06-23 cs.DB

Jinjin Zhao This is my paper
classification cs.DB
keywords datalineageprovenancecross-libraryworkflowsintermediaterepresentationlineage-constrainttagsblack-boxoperationlearninginformationleakagedetectionqueryrewrite
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Data science workflows mix libraries with different data models, so lineage—which input elements produced a given output element—typically stops at library boundaries. This vision paper proposes XProv, a system that captures lineage across those boundaries by reducing all data to multidimensional arrays and annotating each operation with lineage-constraint tags that assert what kind of influence the operation can create. The central claim is that for operations never seen before, these tags and their lineage tables can be learned by probing the operation with small, perturbed example containers, without seeing internal data states or the underlying implementation. If the claim holds, lineage queries that today require either coarse dataset-level tracking or expensive memory-level instrumentation become possible across any library, enabling applications such as leakage detection and execution reordering.

What carries the argument

The load-bearing objects are the lineage-constraint tags: named assertions parameterized by dimension or index, each with an assertion function that validates whether a lineage instance matches, and an optional maximum constraint function that returns the most permissive lineage table consistent with the tag. They sit on top of a unified data model of multidimensional arrays with ordered indices, and below them are materialized influence-lineage tables stored relationally. The learning algorithm is the other main mechanism: it constructs small containers by taking index subsets, perturbs individual elements in the style of the direct and indirect influence definitions, re-runs the operation signature, and then relies on a machine-learning model (envisioned as few-shot) to choose the tags that fit all examples. The tags and their max-constraint functions then approximate the black-box operation's lineage.

What would settle it

Take a real data-science operation whose implementation is size-dependent (for example, a library routine that switches to a parallel or blocked algorithm above a certain container size, or one with random tie-breaking), run the paper's small-container perturbation procedure on it, and compare the learned lineage with the lineage obtained by instrumenting the implementation on a large input. If the predictions diverge on any operation, the proposed small-to-large generalization is falsified.

Watch

Extended reading notes

Core claim

XProv's central proposal is that logical lineage in a cross-library workflow can be represented as a combination of materialized lineage graphs and abstracted lineage-constraint tags, each tag being an assertion over the operation's lineage and its input and output containers (for example, One-to-One, Slice[DIM], Identity, Conditional[DIM, INDEX]). A tag maps to an operation signature if and only if every possible node signature containing that operation signature satisfies the tag. For unknown operations, the paper argues that lineage can be learnt: by taking a subset of indices of an intermediate container, perturbing random individual elements, applying the operation signature to those small containers, and observing outputs, a downstream model can infer which tags hold and, via each tag's maximum constraint function, approximate the lineage as the intersection of all valid tag constraints. The paper states that in this manner lineage can be captured without exposure to any intermediate data states and without the underlying modifying structure, trading guaranteed correctness for tunable uncertainty.

Load-bearing premise

The method assumes that the lineage patterns observed on small, perturbed example containers match the lineage that the same operation produces on full-size input containers; if a real operation takes different code paths or behaves nondeterministically on larger data, the learned tags will be wrong.

Editorial extensions

If this is right

  • If lineage-constraint tags can be learned for unknown operations, cross-library queries that were previously impossible become answerable—for example, asking whether an operation is a Slice[0] (row-wise) to detect leakage before a train/test split.
  • Applications such as rule-based execution reordering become feasible: a downstream tool can assert that two adjacent operations both slice on the same dimension and that the first is Identity, and safely switch their order.
  • Storing tags rather than full lineage tables offers compression and faster assertions, since queries can first search the knowledge base and only fall back to lineage tables when needed.
  • Provenance systems would no longer need to choose between dataset-level tracking and heavy memory-level instrumentation; a middle tier with tunable uncertainty becomes available.
  • Learnt lineage could be accepted for low-risk tasks like leakage inspection while exact lineage is still required for correctness-sensitive reordering, with the origin log letting users calibrate that risk.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The assumption that small-container patterns generalize to full-size inputs is untested in the paper; if real operations have size-dependent code paths (for example, switching to a parallel algorithm over a threshold) or hidden nondeterminism, learned tags will mislead. A natural first experiment is to test known library operations with such behavior.
  • The intersection-of-maximum-constraints idea could be carried further: instead of returning a single set of tags, a learner could output a distribution over tags, letting downstream applications weigh the risk of wrong lineage against task tolerance.
  • The same intermediate representation could double as a data-validation layer: lineage-constraint tags resemble data contracts, so learned tags might also serve as automatically inferred schema or quality contracts for data pipelines.
  • The paper's early LLM experiments suggest a testable extension: use LLM-generated hypotheses as candidate lineage tags for the learning step, rather than only human-authored tags, and verify them against the small-container probes.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. This vision paper proposes XProv, an architecture for cross-library data lineage in data science workflows. XProv represents all significant data as multidimensional arrays (data containers), materializes low-level lineage graphs, and augments them with human-defined or learned 'lineage-constraint tags' such as One-to-One, Slice, and Condition. For unknown operations, Section 3 proposes to learn these tags by executing the operation on small perturbed containers derived from a recorded input, then generalizing the learned pattern to full-size inputs. The paper also sketches applications to information-leakage detection and operation reordering, and reports anecdotal LLM experiments. There is no implementation or empirical evaluation; the paper explicitly states that evaluation is future work.

Significance. The core idea of a parameterized, cross-library provenance IR with a tunable uncertainty-capture trade-off is timely and could be a useful organizing concept for the provenance community. The paper gives explicit definitions for influence lineage and constraint tags, connects the proposal to verified lifting and prior provenance systems, and is honest about its limitations (no evaluation, 2023 draft). However, the central learnability claim rests on a single unvalidated mechanism in Section 3.1, and that mechanism has a concrete blind spot for value-triggered operations such as the paper's own dropna example. The contribution is therefore conditional on fixing the learning algorithm and on at least a small proof-of-concept evaluation.

major comments (3)
  1. [§3.1 (steps 1–3) and §2.3] The perturbation-based algorithm cannot learn value-triggered lineage for operations where output membership depends on a value that does not occur in the sampled subcontainer. In the paper's own motivating example, pandas.dropna deletes a row when any element in that row is NULL (Section 2.3). Steps (1) and (2) deliberately preserve the domain of elements from the initial container, and step (3) perturbs only individual elements within that domain. If the subset of indices chosen in step (2) contains no NULL values, then no perturbation can create a row-deletion event, so the learned lineage is Identity/One-to-One rather than Slice/Condition. This contradicts the claim in Section 3.1 that 'there would exist some perturbation that would affect all indirectly influenced output elements': for the row-deleting entity, no such perturbation exists inside the permitted domain. Because this small-example probing is the only concrete mechanism proposed for black-box lineage capture, the Section 1 promise of capturing lineage 'without exposure to any intermediate data states' is not established for standard value-dependent operations. The algorithm should be extended to allow perturbations outside the observed domain (e.g., sentinel values such as NULL), or the scope of the learned-capture claim must be narrowed accordingly.
  2. [§3.1 and §4.1] The generalization assumption from small example inputs to full-size input containers is explicitly acknowledged but unvalidated, and it is load-bearing: if operations have scale-dependent code paths, data-dependent short-circuiting, or nondeterminism, tags learned on small containers will be wrong on production inputs. This is not a flaw by itself in a vision paper, but the claim that 'lineage from small example inputs can generalize to larger inputs' requires at least a concrete falsifiable evaluation plan (e.g., comparing learned tags against known ground-truth lineage for operations like filter, sort, and dropna across container sizes). Without this, the paper's central promise of capturing lineage for unknown operations is a plausibility argument rather than a supported design.
  3. [§2.3 and §3.1] The formal basis for the learning claim is under-specified: the domain A of possible values for A[a] is never defined. If A is the set of values occurring in the container, then value-triggered indirect influence is undetectable by definition; if A is the full domain of the data type, the step (3) perturbation procedure does not sample from it. Moreover, the phrase 'Under the assumption that the set {A} has a size of 1' (Section 3.1) is unclear because {A} is defined per output index in Section 2.3 and does not have an obvious global analogue. The learnability argument should either be restated in terms of explicit sampling distributions and coverage assumptions, or reframed as an open problem with a precise formal statement.
minor comments (4)
  1. [Algorithm 1] The pseudocode in Algorithm 1 contains confusing negations: `d ← !assert_tag(nop_sig, 'Slice', n.DIM)` appears to negate the slice assertion, and then `|d| != 0` is used as if `d` were a set of valid dimensions; similarly, `double_slice` uses `d` both as a boolean-like result and as the dimension parameter in the second assertion. The `row_wise` procedure adds nodes that are *not* Slice[0], which contradicts the text's description of ensuring row-wise operations. Please clarify whether `!` is a typo and define the return type of `assert_tag`.
  2. [Table 1 and §2.4] The definitions of One-to-One, Identity, Slice, and Condition in Table 1 are not mutually exclusive and are too informal to serve as assertion functions; for example, One-to-One and Identity both relate each output entity to one input entity, and Slice[DIM] as defined would also cover Identity when DIM has size 1. Since the tags are the system's core IR, formal semantics (or at least a precise statement of intended non-exclusivity) would strengthen the proposal.
  3. [§4.5] The LLM experiments are reported without methodology: no prompts, no dataset, no number of trials, and no model version beyond 'GPT-3.5'. They are better framed as motivating anecdotes or moved to future work.
  4. [Global] The manuscript has many typos and template artifacts, including 'XProv all significant data' (§2.1), 'linage' (Table 1), 'back-box' (§3.1), incorrect CCS Concepts from a different template, and a 2018 ACM reference-format placeholder. A careful proofread is needed.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the lineage-learning proposal is an inductive black-box method with explicit assumptions, and the DSLog self-citation is not load-bearing.

full rationale

The paper is a vision proposal, and the central claim is not derived from a fitted quantity. Section 3.1's perturbation procedure is an empirical operationalization of the counterfactual influence definitions in Section 2.3: it probes an opaque operation by executing it on perturbed small containers and then hypothesizes tags (Section 3.2) that generalize to full containers. The generalization step is explicitly flagged as an assumption ('it does make the assumption that the operation signature is executable, and that lineage from small example inputs can generalize to larger inputs'), and the paper defers evaluation ('In the future, we would like to evaluate this capture method in terms of accuracy, coverage, and performance'). An untested assumption is a correctness risk, not circularity. The skeptical NULL-domain example shows that value-triggered behavior can be missed when the triggering value is absent from the sampled domain; this is a sampling blind spot, not a reduction of the prediction to its inputs. The only self-reference is DSLog [37], cited in footnote 1 and Section 2.3 as a lineage storage format; it is not load-bearing and does not force the central proposal. No uniqueness theorem from the authors' prior work is invoked, and no parameter is fit and then renamed as a prediction. Therefore no circular step can be exhibited.

Assumptions & free parameters 0 free parameters · 5 assumptions · 4 invented entities

All of XProv's value depends on a small set of unvalidated modeling assumptions about data representation, operation behavior, and generalization. These are domain assumptions rather than standard math, and each is load-bearing for a different part of the architecture.

assumptions (5)
  • domain assumption Lineage patterns learned on small example containers generalize to full-size input containers.
    Section 3.1 states this explicitly; it is the load-bearing premise for learnt lineage capture, and the paper does not test it.
  • domain assumption The counterfactual set {A} has size 1 for operations of interest, so perturbing individual elements reveals all direct and indirect influences.
    Section 3.1 step 3 relies on this to argue that perturbations eventually expose indirect lineage; no evidence is given that this holds for real operations.
  • domain assumption All relevant data containers can be faithfully represented as multidimensional arrays with unique index sets per dimension.
    Section 2.1 adopts this array data model; relational tables, dataframes, and tensors differ in ordering, duplicate keys, and missing values, so this representation may be lossy.
  • domain assumption A static data dependency graph can be produced for arbitrary Python code.
    Section 2.2 says this is relatively straightforward, but dynamic typing and opaque library internals make it non-trivial; the paper admits DAG generation outside Python is open.
  • domain assumption LLMs can reason about provenance well enough to serve as a capture method for the knowledge base.
    Section 4.5 relies on informal GPT-3.5 experiments and public claims; the paper itself notes hallucination and coverage limits.
invented entities (4)
  • Lineage-constraint tags
    purpose: Annotate operation signatures with assertions about lineage and input/output containers so queries can be answered at a semantic level.
    Introduced in Section 2.4; no external validation or falsifiable prediction.
  • Maximum constraint functions
    purpose: Return the largest lineage table consistent with a tag, used to approximate lineage for black-box operations.
    Mentioned in Section 2.4 but not formally specified or implemented.
  • Provenance equivalence and partial provenance matches
    purpose: Allow one provenance type to be computed from another to reduce storage and compute.
    Conceptually introduced in Section 4.2; no formal definition.
  • XProv architecture
    purpose: The proposed system for cross-library lineage capture and querying.
    The paper is a proposal; no prototype exists.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Learning Lineage Constraints for Data Science Operations." pith.science (2026). https://pith.science/paper/IE45WWKH

@misc{pith2026250618252,
  author       = {Pith},
  title        = {Pith review of: Learning Lineage Constraints for Data Science Operations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IE45WWKH}},
  note         = {Machine review of arXiv:2506.18252}
}
read the original abstract

Data science workflows often integrate functionalities from a diverse set of libraries and frameworks. Tasks such as debugging require data lineage that crosses library boundaries. The problem is that the way that "lineage" is represented is often intimately tied to particular data models and data manipulation paradigms. Inspired by the use of intermediate representations (IRs) in cross-library performance optimizations, this vision paper proposes a similar architecture for lineage - how do we specify logical lineage across libraries in a common parameterized way? In practice, cross-library workflows will contain both known operations and unknown operations, so a key design of XProv to link both materialized lineage graphs of data transformations and the aforementioned abstracted logical patterns. We further discuss early ideas on how to infer logical patterns when only the materialized graphs are available.

Figures

Figures reproduced from arXiv: 2506.18252 by the authors.

Figure 1
Figure 1. We show (A) a simple example pipeline where a Pandas, DuckDB, and scikit-learn operations are applied to (B) a sample dataframe [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. For the example code, we show the envisioned data lineage DAG stored in XProv. data model is to be deliberately broad to encapsulate a wide range of data such as dataframes, relational tables, spread￾sheets, arrays, and tensor. This allows lineage to be tracked across different data framework within the life cycle of a data science project. XProv reduces the native data type to arrays by deter￾mining the number of d… view at source ↗
Figure 5
Figure 5. We represent the architecture of XProv to enable (learnt) capture and query of lineage tables and semantic tags [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figures from the paper (1 more)
Figure 6
Figure 6. Figure 6: XProv enables capturing lineage with uncertainty, which reduces the capture cost of lineage and increases the type of operation lineage that can be captured. supported high-cost lineage capture with certainty. XProv re￾duces the cost of capture when some uncertainty is…

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. AuditWeave: A Tamper-Evident, Auditor-Navigable Evidence Layer for AI-Assisted and Data-Transformation Workflows

    cs.LG 2026-06 conditional novelty 4.0 of 10

    A no-dependency Python library records RAG and tabular workflow steps in one hash-chained ledger, enabling end-to-end evidence navigation and detectable tampering at tens of microseconds per event.

Reference graph

Works this paper leans on

38 extracted references · 33 canonical work pages · cited by 1 Pith paper

  1. [1]

    T. Baeyens. Introducing soda data contracts, November 2023. Accessed 2025-06-22

    work page 2023

  2. [2]

    T. B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert- Voss, G. Krueger, T. Henighan, R. Child, A. Ramesh, D. M. Ziegler, J. Wu, C. Winter, C. Hesse, M. Chen, E. Sigler, M. Litwin, S. Gray, B. Chess, J. Clark, C. Berner, S. McCandlish, A. Radford, I. Sutskever, and D. Amo...

    arXiv 2005

  3. [3]

    Chapman, P

    A. Chapman, P. Missier, G. Simonelli, and R. Torlone. Capturing and querying fine-grained provenance of preprocessing pipelines in data science. Proceedings of the VLDB Endowment , 14(4):507–520, 2020

    work page 2020

  4. [4]

    Cheney, L

    J. Cheney, L. Chiticariu, and W.-C. Tan. Provenance in databases: Why, how, and where. Found. Trends Databases, 1(4):379–474, apr 2009

    work page 2009

  5. [5]

    Cheung, A

    A. Cheung, A. Solar-Lezama, and S. Madden. Optimizing database- backed applications with query synthesis. ACM SIGPLAN Notices , 48(6):3–14, 2013

    work page 2013

  6. [6]

    Derakhshan, A

    B. Derakhshan, A. Rezaei Mahdiraji, Z. Abedjan, T. Rabl, and V. Markl. Optimizing machine learning workloads in collaborative environments. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data, pages 1701–1716, 2020

    work page 2020

  7. [7]

    Gable.ai raises $7m in seed funding, September 2023

    Gable.ai. Gable.ai raises $7m in seed funding, September 2023. Ac- cessed 2025-06-22

    work page 2023

  8. [8]

    Glavic et al

    B. Glavic et al. Data provenance.Foundations and Trends® in Databases, 9(3-4):209–441, 2021

    work page 2021

Show all 38 references
  1. [9]

    Grafberger, J

    S. Grafberger, J. Stoyanovich, and S. Schelter. Lightweight inspection of data preprocessing in native machine learning pipelines. InConference on Innovative Data Systems Research , 2021

    2021

  2. [10]

    T. J. Green, G. Karvounarakis, and V. Tannen. Provenance semirings. In Proceedings of the Twenty-Sixth ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems , PODS ’07, page 31–40, New York, NY, USA, 2007. Association for Computing Machinery

    2007

  3. [11]

    J. M. Hellerstein, V. Sreekanti, J. E. Gonzalez, J. Dalton, A. Dey, S. Nag, K. Ramachandran, S. Arora, A. Bhattacharyya, S. Das, et al. Ground: A data context service. In CIDR. Citeseer, 2017

    2017

  4. [12]

    Huang, W

    L. Huang, W. Yu, W. Ma, W. Zhong, Z. Feng, H. Wang, Q. Chen, W. Peng, X. Feng, B. Qin, and T. Liu. A survey on hallucination in large language models: Principles, taxonomy, challenges, and open questions. ACM Transactions on Information Systems , 43(2):1–55, Jan. 2025

    2025

  5. [13]

    Interlandi, K

    M. Interlandi, K. Shah, S. D. Tetali, M. A. Gulzar, S. Yoo, M. Kim, T. Millstein, and T. Condie. Titian: Data provenance support in spark. In Proceedings of the VLDB Endowment International Conference on Very Large Data Bases, volume 9, page 216. NIH Public Access, 2015

    2015

  6. [14]

    Kapoor and A

    S. Kapoor and A. Narayanan. Leakage and the reproducibility crisis in ml-based science, 2022

    2022

  7. [15]

    Kaufman, S

    S. Kaufman, S. Rosset, C. Perlich, and O. Stitelman. Leakage in data mining: Formulation, detection, and avoidance. ACM Trans. Knowl. Discov. Data, 6(4), dec 2012

    2012

  8. [16]

    Macke, H

    S. Macke, H. Gong, D. J.-L. Lee, A. Head, D. Xin, and A. Parameswaran. Fine-grained lineage for safer notebook interactions. arXiv preprint arXiv:2012.06981, 2020

    2012 arXiv

  9. [17]

    Mezhanskiy

    G. Mezhanskiy. The best data contract is the pull request, September

  10. [18]

    S. Murray. Executive q&a: All about data contracts, May 2023. Accessed 2025-06-22

    2023

  11. [19]

    M. H. Namaki, A. Floratou, F. Psallidas, S. Krishnan, A. Agrawal, Y. Wu, Y. Zhu, and M. Weimer. Vamsa: Automated provenance tracking in data science scripts. In Proceedings of the 26th ACM SIGKDD international conference on knowledge discovery & data mining , pages 1542–1551, 2020

    2020

  12. [20]

    Narayan, I

    A. Narayan, I. Chami, L. Orr, S. Arora, and C. Ré. Can foundation models wrangle your data?, 2022

    2022

  13. [21]

    Neumann and M

    T. Neumann and M. J. Freitag. Umbra: A disk-based system with in-memory performance. In Conference on Innovative Data Systems Research, 2020

    2020

  14. [22]

    Palkar, J

    S. Palkar, J. J. Thomas, A. Shanbhag, D. Narayanan, H. Pirk, M. Schwarzkopf, S. Amarasinghe, and M. Zaharia. Weld: A common runtime for high performance data analytics. 2017

    2017

  15. [23]

    Petersohn, W

    D. Petersohn, W. W. Ma, D. J. L. Lee, S. Macke, D. Xin, X. Mo, J. E. Gonzalez, J. M. Hellerstein, A. D. Joseph, and A. G. Parameswaran. Towards scalable dataframe systems. CoRR, abs/2001.00888, 2020

    2001 arXiv

  16. [24]

    Phani, B

    A. Phani, B. Rath, and M. Boehm. Lima: Fine-grained lineage tracing and reuse in machine learning systems. In Proceedings of the 2021 International Conference on Management of Data , pages 1426–1439, 2021

    2021

  17. [25]

    Pirahesh, J

    H. Pirahesh, J. M. Hellerstein, and W. Hasan. Extensible/rule based query rewrite optimization in starburst. InProceedings of the 1992 ACM SIGMOD International Conference on Management of Data , SIGMOD ’92, page 39–48, New York, NY, USA, 1992. Association for Computing Machinery

    1992

  18. [26]

    Psallidas and E

    F. Psallidas and E. Wu. Smoke: Fine-grained lineage at interactive speed. arXiv preprint arXiv:1801.07237, 2018

    2018 arXiv

  19. [27]

    B. M. Randles, I. V. Pasquetto, M. S. Golshan, and C. L. Borgman. Using the jupyter notebook as a tool for open science: An empirical study. In 2017 ACM/IEEE Joint Conference on Digital Libraries (JCDL) , pages 1–2, 2017

    2017

  20. [28]

    Sculley, G

    D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J.-F. Crespo, and D. Dennison. Hidden techni- cal debt in machine learning systems. Advances in neural information processing systems, 28, 2015

    2015

  21. [29]

    Shang, E

    Z. Shang, E. Zgraggen, and T. Kraska. Alpine meadow: A system for interactive automl

  22. [30]

    M. Tang, S. Shao, W. Yang, Y. Liang, Y. Yu, B. Saha, and D. Hyun. Sac: A system for big data lineage tracking. In 2019 IEEE 35th International Conference on Data Engineering (ICDE) , pages 1964–1967. IEEE, 2019

    2019

  23. [31]

    Vaswani, N

    A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, and I. Polosukhin. Attention is all you need. CoRR, abs/1706.03762, 2017

    2017 arXiv

  24. [32]

    E. Wu, S. Madden, and M. Stonebraker. Subzero: a fine-grained lin- eage system for scientific databases. In 2013 IEEE 29th International Conference on Data Engineering (ICDE) , pages 865–876. IEEE, 2013

    2013

  25. [33]

    Y. Wu. Is a dataframe just a table? In PLATEAU@UIST, 2019

    2019

  26. [34]

    D. Xin, S. Macke, L. Ma, J. Liu, S. Song, and A. Parameswaran. Helix: Holistic optimization for accelerating iterative machine learning.arXiv preprint arXiv:1812.05762, 2018

    2018 arXiv

  27. [35]

    C. Yan, Y. Lin, and Y. He. Predicate pushdown for data science pipelines. Proc. ACM Manag. Data, 1(2), jun 2023

    2023

  28. [36]

    Zaharia, A

    M. Zaharia, A. Chen, A. Davidson, A. Ghodsi, S. A. Hong, A. Konwinski, S. Murching, T. Nykodym, P. Ogilvie, M. Parkhe, et al. Accelerating the machine learning lifecycle with mlflow. IEEE Data Eng. Bull. , 41(4):39–45, 2018

    2018

  29. [37]

    Zhao and S

    J. Zhao and S. Krishnan. Compression and in-situ query processing for fine-grained array lineage, 2024

    2024

  30. [2022]

    Learning Lineage Constraints for Data Science Operations [Vision] Conference acronym ’XX, June 03–05, 2018, Woodstock, NY

    Accessed 2025-06-22. Learning Lineage Constraints for Data Science Operations [Vision] Conference acronym ’XX, June 03–05, 2018, Woodstock, NY

    2025

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.