How Dependency Graphs Can Reveal Hidden Scientific Contributors

Getting your Trinity Audio player ready...

Scientific credit usually follows what is visible. The authors of a widely read paper receive citations, invitations, funding, and recognition. Yet many discoveries depend on people whose names never appear prominently: software maintainers, dataset creators, laboratory technicians, proof formalizers, method designers, and researchers who established obscure but essential intermediate results.

Dependency graphs can reveal these hidden scientific contributors by mapping which research outputs, tools, and ideas were necessary for later work. Instead of asking only, “Who authored the final paper?”, a dependency graph asks, “Whose contribution made this result possible?”

This is a more structural view of scientific impact. It does not replace authorship, citation analysis, or peer review. It supplements them by exposing chains of intellectual and technical dependence that conventional metrics frequently miss.

What Is a Scientific Dependency Graph?

A scientific dependency graph is a network in which:

• nodes represent research outputs or contributors;
• edges represent relationships of dependence;
• edge types describe how one contribution supports another.

A node might represent:

• a paper;
• a mathematical theorem;
• a dataset;
• a software package;
• an experimental protocol;
• a laboratory instrument;
• a statistical method;
• a formal proof;
• a technical standard;
• a replication or correction.

An edge from output A to output B means that B depends on A in some identifiable sense.

For example:

Mathematical definition → theorem → numerical algorithm → software library → simulation → published scientific result

The authors of the final publication may receive most of the visible credit. A dependency graph makes the entire chain inspectable.

Software platforms already use a limited version of this model. GitHub’s dependency graph identifies direct and transitive software dependencies from repository manifests, lock files, and submitted dependency information. It can show both what a repository uses and which public repositories depend on it.

Science could apply the same principle more broadly.

Why Scientific Contributors Become Invisible

Scientific work is cumulative, but its credit system is compressed.

A paper may have thousands of intellectual and technical dependencies while containing only a limited bibliography and author list. Some dependencies are omitted because they are considered standard. Others are too indirect, too technical, or too deeply embedded in software and research infrastructure to receive explicit acknowledgment.

Transitive dependencies disappear

A researcher may use software package A, which depends on package B, which in turn depends on packages C and D.

The researcher may cite A but never know that C and D exist. Nevertheless, a defect or abandonment in D could prevent the entire analysis from running.

This is a transitive dependency: the final work depends on an upstream contribution through one or more intermediate layers.

The same structure appears outside software:

• a biological study depends on an image-processing algorithm;
• the algorithm depends on a mathematical transformation;
• the transformation depends on earlier theoretical results;
• the implementation depends on general-purpose numerical libraries.

Only a small part of this chain normally appears in citation counts.

Infrastructure becomes taken for granted

Successful scientific infrastructure often becomes invisible precisely because it works reliably.

Researchers notice a failed database, broken package, or inconsistent standard. They rarely notice the years of maintenance that prevented those failures.

This produces an attribution paradox:

The more dependable an infrastructure contribution becomes, the easier it is for users to forget that someone must create and maintain it.

Negative and corrective work receives little attention

Dependency graphs can also identify contributors who:

• discovered an error;
• repaired a dataset;
• reproduced an experiment;
• maintained backward compatibility;
• documented an undocumented method;
• tested a library across platforms;
• preserved an abandoned research tool.

These activities may not create a new headline result, but later work can depend on them.

Foundational mathematics may be many steps removed

A mathematical concept can influence science without being cited by every downstream user.

A theorem may become incorporated into an algorithm. The algorithm enters a library. The library is used by a scientific application. The application contributes to thousands of studies.

The original mathematical work is structurally upstream, but direct citation tracking may detect only a small portion of its influence.

This is why a broader utility graph for free software and basic mathematics must include conceptual, software, deployment, and outcome relationships—not merely citations.

Which Hidden Contributors Could Dependency Graphs Reveal?

A comprehensive graph could identify several kinds of contributors who are poorly represented by conventional bibliometrics.

Research Software Developers

Modern science relies on source code for simulation, measurement, visualization, data cleaning, statistical analysis, and reproducible workflows.

Yet software is not always cited consistently. The FORCE11 Software Citation Principles argue that software should be treated as a legitimate research product and that citations should support credit, identification, persistence, accessibility, and precise versioning.

A dependency graph could go further than formal citations by detecting:

• declared package dependencies;
• imported modules;
• container images;
• workflow definitions;
• API calls;
• build dependencies;
• reused source-code components;
• transitive dependencies;
• specific software versions.

It could then connect a scientific result not only to the primary application but also to upstream libraries and maintainers.

Dataset Creators and Curators

A dataset may require years of collection, cleaning, classification, and documentation. Later researchers can publish many papers from it while the dataset’s creators receive limited recognition.

A data dependency edge could record that:

• a paper analyzed a particular dataset;
• one dataset incorporated records from another;
• a cleaned dataset corrected an earlier release;
• a benchmark depended on a specific labeling effort;
• a model was trained or evaluated using particular data.

The graph should distinguish casual availability from substantive dependence. Merely downloading a dataset is weaker evidence than using it to generate a published result.

Creators of Methods and Protocols

Researchers frequently reuse methods that have become routine:

• laboratory preparation techniques;
• statistical estimators;
• calibration procedures;
• survey instruments;
• numerical schemes;
• proof techniques;
• classification systems.

Once a method becomes standard, researchers may cite a recent application or review rather than its original creator. This creates citation displacement, in which credit moves from foundational work toward more visible intermediaries.

A dependency graph could trace the method’s lineage and distinguish:

• original invention;
• major improvement;
• implementation;
• validation;
• adaptation to another field;
• routine use.

Maintainers and Reliability Contributors

Authorship records creation more readily than maintenance.

However, scientific reliability can depend on contributors who:

• review patches;
• fix security vulnerabilities;
• maintain compatibility;
• test releases;
• improve documentation;
• answer technical questions;
• manage research databases;
• preserve long-term access.

A graph based only on papers and repository ownership would still overlook much of this work. Contributor records, commit histories, issue trackers, release metadata, and maintenance logs can reveal who kept an output usable.

Replicators and Error Correctors

A replication may confirm that a result is dependable. A correction may prevent hundreds of researchers from building on a mistake.

These are not merely reactions to another contribution. They can become dependencies of later scientific confidence.

A graph could represent:

Original claim → independent replication → accepted use in later research

or:

Published dataset → detected error → corrected release → downstream analyses

The replicator or corrector may therefore occupy a structurally important position even without producing the original object.

Technical and Laboratory Contributors

Not every scientific dependency is digital.

Research may depend on:

• specialized instrument construction;
• sample preparation;
• field collection;
• laboratory management;
• long-term observation;
• technical calibration;
• research engineering.

Contributor taxonomies can describe roles, but dependency graphs add another dimension: they can show which later outputs actually depended on those roles.

Direct, Transitive, and Conceptual Dependencies

Not all dependencies mean the same thing. A useful graph must classify them.

Direct dependency

Output B explicitly uses output A.

Examples include:

• software importing a package;
• a paper analyzing a dataset;
• an experiment following a published protocol;
• a proof invoking a theorem.

Transitive dependency

B depends on A through an intermediate output.

For example:

Study B → analysis tool C → numerical library D → algorithm E

Study B may never mention D or E, but it could not run without them.

Conceptual dependency

A later result uses an idea, abstraction, or mathematical structure derived from earlier work.

Conceptual dependencies are harder to verify than software imports because ideas can be reformulated, independently rediscovered, or absorbed into general knowledge.

They may be detected through:

• explicit citations;
• shared definitions;
• theorem references;
• distinctive terminology;
• derivation histories;
• expert review;
• formal proof dependencies;
• source-code implementations.

AI can suggest such links, but strong conceptual attribution should remain reviewable and contestable.

Validation dependency

A result becomes trusted because of another output.

Examples include:

• replication;
• benchmark testing;
• independent proof verification;
• dataset auditing;
• robustness analysis.

Operational dependency

A project depends on continuing services or maintenance rather than a one-time intellectual contribution.

Examples include:

• database hosting;
• package maintenance;
• instrument calibration;
• security updates;
• compatibility work.

These dependencies are especially important when allocating continuing support.

How AI Could Construct Scientific Dependency Graphs

No single database contains the full structure of scientific dependence. A practical system would combine several evidence sources.

Scholarly records

Citation databases provide relationships among papers, books, datasets, and sometimes software. These links are useful but incomplete.

A citation indicates acknowledgment, discussion, criticism, or reuse. It does not automatically prove necessity.

Software manifests and source code

Machine-readable software metadata can provide stronger technical evidence.

Package manifests specify direct dependencies, while lock files can identify the exact versions installed. GitHub notes that supported dependency graphs may also include indirect dependencies by following dependencies of declared packages.

Additional evidence can come from:

• import statements;
• build files;
• container specifications;
• workflow files;
• package registries;
• software bills of materials;
• release archives;
• code references.

Dataset and workflow metadata

Research workflows can record which data, software, parameters, and computational steps produced a result.

This creates a provenance graph:

Input data → transformation → intermediate output → analysis → figure → conclusion

Where such provenance is available, attribution becomes more precise and reproducibility improves.

Natural-language analysis

AI models can examine papers, documentation, code comments, and method descriptions to propose connections not expressed through formal metadata.

For example, a model might detect that a paper’s algorithm is a modified implementation of an earlier method even when the citation is incomplete.

Such inferences should be labeled by confidence and evidence type. An AI-generated edge is not equivalent to a declared package dependency or verified formal proof.

Contributor identity resolution

The same person may appear under different names, institutions, repository accounts, and identifier systems.

A dependency graph therefore needs careful identity resolution using evidence such as:

• ORCID records;
• repository accounts;
• institutional profiles;
• publication metadata;
• contributor files;
• persistent identifiers.

Automatic identity merging can misattribute work, especially when names are common. Researchers must be able to correct their records.

How Should Dependency-Based Credit Be Calculated?

Counting downstream nodes is not enough. A widely installed but replaceable utility should not automatically receive more credit than a narrow, irreplaceable scientific method.

A responsible model would evaluate several dimensions.

Downstream reach

How many verified outputs depend on the contribution?

Raw reach is useful, but it should be adjusted for duplicated projects, automated forks, and low-quality outputs.

Dependency depth

How far downstream does the contribution propagate?

A result used by a library that supports thousands of applications has extensive indirect reach. However, influence should generally decay with distance to avoid attributing every modern result equally to ancient foundations.

Structural criticality

Would the downstream work fail, become invalid, or become significantly harder without this contribution?

This distinction separates genuine dependency from incidental inclusion.

Replaceability

Could another tool, dataset, theorem, or method easily substitute for the contribution?

A replaceable component can still be valuable, but an irreplaceable component has greater structural importance.

Independent adoption

Use by multiple unrelated teams is stronger evidence than use within one laboratory, organization, or coordinated network.

Contribution share

A dependency graph should not assign all upstream value to one node.

A final scientific result may depend jointly on:

• theory;
• data;
• software;
• equipment;
• validation;
• maintenance;
• domain expertise.

Credit must be distributed rather than duplicated without limit.

Validation quality

A contribution used in well-validated, replicated work should carry stronger evidence than one used primarily by unverified or retracted outputs.

Maintenance burden

For living infrastructure, impact depends not only on original creation but also on continued maintenance.

The graph may need separate credit categories for:

• invention;
• implementation;
• documentation;
• verification;
• maintenance;
• governance.

Dependency Is Not the Same as Merit

A dependency graph is an evidence structure, not a complete moral or scientific ranking.

A contribution can be widely depended upon while being:

• technically mediocre;
• replaceable;
• used only because of historical lock-in;
• maintained by people other than its creator;
• embedded in flawed research;
• popular because of institutional dominance.

Conversely, an excellent foundational result may have few observable dependencies because it is new, difficult to understand, or ahead of available applications.

Therefore:

Dependency indicates that later activity relies on a contribution. It does not, by itself, determine originality, truth, difficulty, or total scientific merit.

Dependency information should be combined with expert evaluation, reproducibility evidence, originality analysis, correction history, and field-specific context.

Preventing Manipulation

Any metric connected to reputation or money will attract strategic behavior.

Possible attacks include:

• creating artificial packages that depend on one another;
• generating fake repositories;
• inflating downloads;
• adding unnecessary dependencies;
• forming reciprocal citation networks;
• falsely claiming conceptual influence;
• splitting one contribution into many nodes;
• impersonating contributors;
• attaching important outputs to unrelated work.

A robust system should therefore:

• weight independent use more heavily;
• discount circular dependency structures;
• verify production or research use where possible;
• distinguish declared from inferred edges;
• preserve evidence for every relationship;
• detect coordinated accounts;
• allow challenges and appeals;
• publish scoring rules;
• avoid relying on one aggregate score.

Dependency information is valuable precisely because it is more concrete than reputation alone. It loses that advantage if its provenance cannot be inspected.

From Hidden Credit to Scientific Funding

Dependency graphs could influence more than academic recognition. They could help direct money toward upstream work that conventional markets and grant systems underfund.

For example, funding could support:

• maintainers of heavily reused research software;
• creators of datasets supporting many independent studies;
• authors of methods repeatedly incorporated into later work;
• replicators whose verification enabled wider adoption;
• developers maintaining critical scientific infrastructure;
• mathematicians whose results have become embedded in algorithms.

The AI Internet-Meritocracy model for scientific funding proposes evaluating verifiable contributions, reuse, dependencies, validation, and usefulness rather than relying only on promises made in grant applications.

Under such a model, dependency graphs would not automatically decide who receives money. They would supply structured evidence to an auditable allocation system.

A defensible process might work as follows:

1. Detect a dependency relationship.
2. Record the supporting evidence.
3. Classify the dependency type.
4. estimate its strength and criticality.
5. Identify the responsible contributors.
6. Allow review, correction, and appeal.
7. Allocate a limited reward under published rules.
8. Recalculate when evidence changes.

This would turn attribution from a static author list into a continuously updated account of how science is built.

Limitations of Scientific Dependency Graphs

Dependency mapping remains difficult.

Undocumented dependencies

Researchers may reuse an idea, dataset, or code fragment without documenting it. No graph can reliably reconstruct every missing relationship.

Tacit knowledge

Some research depends on personal instruction, laboratory culture, or technical skill that leaves little machine-readable evidence.

Ambiguous intellectual lineage

Similar ideas can emerge independently. AI may infer influence where none occurred.

Unequal digital coverage

Software-intensive fields generate more structured dependency data than theoretical, qualitative, or field-based research.

Privacy and security

Some dependencies involve confidential data, private repositories, sensitive infrastructure, or unpublished collaborations.

Credit division

Even after identifying a dependency, determining how much credit belongs to each contributor remains partly normative.

These limitations mean that dependency graphs should expose evidence and uncertainty rather than present an unquestionable ranking.

Building a More Accurate Map of Science

Science is not a sequence of isolated papers. It is a layered system of concepts, proofs, observations, datasets, instruments, code, standards, corrections, and human maintenance.

Citation graphs capture part of that system. Authorship captures another part. Dependency graphs can reveal relationships that both overlook.

Their greatest value is not producing a definitive league table of scientists. It is making previously invisible support structures visible.

A mature scientific dependency graph could show:

• which upstream tools support a discovery;
• whose maintenance keeps a field operational;
• which datasets enable entire research programs;
• which abstract results entered practical technology;
• which replications created confidence;
• where critical infrastructure is underfunded;
• which contributors have generated substantial value without conventional prestige.

The central insight is simple:

Scientific impact belongs not only to the people standing at the end of a discovery chain, but also to the people who made every essential link possible.

Dependency graphs give science a way to see those links—and, eventually, to recognize and support the contributors behind them.