← Latest papers
💻 computer science

Towards Automatically Inferring Constraints to Identify Implicit Assumptions in Data Analysis

This paper proposes a unified perspective and a proof-of-concept implementation using static analysis to automatically infer and explicitly represent implicit assumptions in data analysis scripts as code constraints, thereby enhancing reproducibility, runtime verification, and code comprehension.

Original authors: Florian Sihler, Lars Pfrenger, Oliver Gerstl, Matthias Tichy

Published 2026-07-07
📖 4 min read☕ Coffee break read

Original authors: Florian Sihler, Lars Pfrenger, Oliver Gerstl, Matthias Tichy

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to follow a recipe to bake a cake, but the recipe was written by a friend who forgot to write down a few crucial details. They didn't mention that you need a specific type of oven, or that the flour must be sifted before you add the eggs, or that the recipe only works if you have a specific brand of baking powder.

If you try to bake the cake with your own equipment and ingredients, it might fail, or it might taste completely different. In the world of data science, scientists write "recipes" (scripts) to analyze data. The problem is that these recipes are full of hidden assumptions—things the author took for granted but never wrote down.

This paper, written by researchers at Ulm University, proposes a new way to find these hidden assumptions and turn them into clear, written rules.

The Problem: The "Magic" Recipe

Data scientists use languages like R or Python to analyze data. Often, they work in interactive notebooks where they type code, see a result, type more code, and see another result.

The trouble is, these scripts often rely on "magic" that isn't written down:

  • The Right Tools: "I used a specific version of a software tool that I didn't install for you."
  • The Order of Operations: "I ran this step before that one, but I didn't tell you to do it in that order."
  • The Shape of the Data: "I assumed your data had a column named 'Age,' but yours is named 'Years.'"

When someone else tries to run the code, it often crashes or gives wrong answers because these hidden rules were broken. Studies show that a huge percentage of these data scripts simply won't run for anyone other than the original author.

The Solution: The "Detective" Approach

The authors suggest using a technique called Static Analysis. Think of this as a super-smart detective that reads the code without actually running it.

Instead of just looking at the words, the detective looks at the logic to ask:

  • "What version of the software must be here for this line to work?"
  • "What does this data file have to look like for this calculation to make sense?"
  • "Did this script depend on a previous step that isn't included?"

The detective then writes down all these hidden rules as constraints. It's like taking that vague recipe and adding a checklist at the top: "Must use Oven Model X," "Flour must be sifted," "Eggs must be room temperature."

How It Works (The Three Main Clues)

The paper breaks down these hidden assumptions into three main categories:

  1. The Toolbelt (Package Versions):

    • The Assumption: "I used a new feature in my software that you don't have yet."
    • The Fix: The detective looks at the code and says, "This script uses a specific drawing tool that was only invented in 2022. You need software version 2.0 or higher."
  2. The Chain Reaction (Script Dependencies):

    • The Assumption: "I'm using a variable called grouped that I created in a different file, but I didn't tell you to load that file first."
    • The Fix: The detective traces the connections. It realizes, "Hey, this script is missing a piece of the puzzle. It needs to run after that other script to get the data it needs." It creates a map showing the correct order to run everything.
  3. The Shape of the Data (Data Expectations):

    • The Assumption: "I'm assuming the data has a column for 'Score' and that the numbers are whole integers."
    • The Fix: The detective analyzes the math. It adds a safety check: "Before we start, check if the data actually has a 'Score' column. If not, stop and tell the user."

The Goal: Making Science Reproducible

The ultimate goal isn't just to fix one script; it's to make science more reliable.

  • For the Original Author: It helps them write better, self-checking code.
  • For the Reuser: It acts as a clear instruction manual. If you try to use the script with the wrong data or tools, the script will stop and say, "Hey, you're missing a requirement," instead of crashing silently or giving a wrong answer.

The Current Status

The researchers have built a "proof-of-concept" (a working prototype) using a tool called flowR to analyze R code. They tested it on thousands of real-world projects and found that many of them do indeed have these hidden dependencies.

They admit this isn't a magic wand that solves everything (some assumptions are too complex for a computer to guess perfectly), but they believe that simply finding and listing these hidden assumptions is a massive step forward. It turns a broken, confusing recipe into a clear, usable guide for everyone.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →