What Is an Artifact
Dependency Graph?
An artifact dependency graph maps which repositories across an organisation consume which shared infrastructure artifacts — Terraform modules, Docker base images, Helm charts, CI templates, internal packages — so you can read the blast radius of changing any one of them instead of reconstructing it by hand.
An artifact dependency graph is a directed graph of consumer-to-producer
relationships between the infrastructure artifacts an organisation shares across its
repositories. Each producer node is an artifact one repository publishes: a Terraform
module, a Docker image, a Helm chart, a reusable CI template, an internal Go or npm or
Python package. Each edge is a consumption relationship declared in a manifest somewhere
else in the org: a Terraform source block, a Dockerfile FROM
line, a Helm dependency, a go.mod require, a GitLab CI include.
Built across every repository at once, the graph answers one question directly: if this
artifact changes, which repositories break.
The defining property is that the edges are parsed from source, not declared in a catalogue and not inferred from text. The graph is derived from the files that already define the relationships, so it stays current as the repositories change, and it is deterministic rather than probabilistic.
The short form of the term, used as the contrast to a symbol graph, is simply the artifact graph.
"Artifact dependency graph" gets used for three different graphs. This is the one symbol tools can't see.
The phrase is older than this page and it is not used consistently. Three established meanings travel under nearly the same words, and they are genuinely different graphs built for different jobs. The fastest way to understand the cross-repo infrastructure sense is to put it next to the other three.
It is not a symbol graph.
A symbol graph indexes the functions, classes, and imports inside your code.
Sourcegraph's SCIP is the best-known example, and it is excellent at what it does:
jump-to-definition, find-references, and impact analysis at the level of language
symbols. But a symbol graph stops at the language boundary. It does not parse a
Dockerfile FROM, a Terraform source, a Helm dependency, or a
CI include, because those are not language symbols. They are the
infrastructure edges that run between repositories rather than between functions.
Symbol graphs and artifact graphs are different categories, and the artifact layer is
precisely the one a symbol graph cannot reach. This distinction is worked through in
full in
Symbol graphs and artifact graphs: why Sourcegraph stops where infrastructure starts.
It is not the supply-chain ADG, and it is not your SBOM. There is a second, well-established meaning of "artifact dependency graph" in the software supply-chain world. The OmniBOR specification defines an ADG as a Merkle tree of hashes that records every input transformed by a build, recursively, down to the source files that produced a compiled binary. The US DHS Science and Technology Directorate, with CISA, has funded ADG-generation work under exactly that name, aimed at vulnerability response and secure-by-design practices. That graph is real and the work is important. It is also pointed in the opposite direction. A supply-chain ADG looks down into a single build to prove what went into one artifact. The cross-repo artifact graph looks across an organisation to find what consumes one artifact. One is build provenance for one binary. The other is blast radius across many repositories. They answer different questions, the same way an SBOM lists what is inside one artifact while the cross-repo question asks which products ship an affected component. That second distinction is the subject of The CRA's 24-hour clock is a cross-repo question. Your SBOM answers a different one.
It is not a modelled catalogue. A developer portal like Backstage, or a modelling platform like Port, lets you describe your system as entities and relations and then keep that description current. Port's Blueprints can model almost anything you are willing to define. The difference is the source of truth. A modelled graph is the catalogue you describe and then maintain. A parsed graph is the dependency graph your repositories already declare, read directly from the manifests. Modelled graphs are powerful for relationships that live nowhere in code. The artifact graph is for the relationships that do, which is why it can be auto-discovered and never declared. The architectural contrast is laid out in Modeled graphs and parsed graphs.
Same words, four different graphs. This page is about the cross-repo infrastructure one: the consumers of your shared artifacts, parsed from source, across the whole org.
The artifact graph, cross-repo dependency mapping, and cross-repo context
The artifact graph is the object. The practice that produces it is cross-repo dependency mapping: enumerating every repository, parsing the manifests, resolving the references, and assembling the directed graph. When an AI coding agent consumes that same graph at planning time, the platform and AI-tooling communities increasingly call the consumed form cross-repo context. The three terms describe one primitive from three angles: the graph, the practice that builds it, and the structured knowledge read out of it at decision time. The relationship between the practice and the consumed form is covered on the sibling page, What is cross-repo dependency mapping?
The highest-blast-radius edges are the ones no code tool indexes
Shared infrastructure artifacts fan out. A base image gets pulled by every service in the org. A Terraform module is sourced by forty repositories. A reusable CI template is included by eighty pipelines. These are the changes with the widest blast radius, and they are exactly the edges that live between repositories rather than inside any one of them.
Without an artifact graph, that knowledge has nowhere to live except in the heads of the few engineers who have been around long enough to hold it. The graph is real whether or not anyone has written it down. The only question is whether it is queryable, or whether it gets reconstructed by hand, under time pressure, every time something needs to change.
Edges outside the language
A Dockerfile FROM, a Terraform source, a Helm dependency, a CI include. None of them is a code symbol, so symbol-graph tools never see them.
Relationships between repos, not within one
The edge that matters lives in the relationship between two repositories. It is invisible from inside either one, which is where most tooling looks.
Widest fan-out, least visibility
Shared artifacts are consumed broadly by definition. The change you most need to scope is the one whose blast radius is hardest to see.
From raw repos to a queryable artifact graph
- 01
Enumerate
Every repository in a GitLab group or GitHub organisation is listed via the platform API. No manual inventory.
- 02
Clone
Each repository is shallowly cloned at its default branch. Only the source tree is needed.
- 03
Parse producers
Each repository is inspected for what it publishes: a Docker image, a Terraform module, a Helm chart, an internal package.
- 04
Parse consumers
Manifests that declare a dependency on a shared artifact are parsed: Terraform source blocks, Dockerfile FROM statements, Helm Chart.yaml dependencies, go.mod requires, package.json, CI include and workflow calls, and more.
- 05
Resolve
Parsed references are resolved against the org, internal registries, and public registries, connecting each consumer to the producer it actually points at, including transitively.
- 06
Build the graph
A directed, queryable graph of consumer-to-producer relationships is assembled across the whole organisation, ready for blast-radius analysis.
Because the graph is built from what is actually in the manifests rather than from maintained metadata, it stays current as repositories change, with no catalogue to update.
What an artifact graph spans
A useful artifact graph is cross-ecosystem, because real systems are. A Terraform module change can affect a Docker build, which feeds a CI pipeline, which drives a Helm release. Single-ecosystem tools miss exactly these cross-boundary edges.
- Terraform modules
- Docker base images
- GitLab CI templates
- GitHub Actions workflows
- Helm chart dependencies
- Ansible roles & collections
- Python packages
- Go modules
- npm packages
- Kubernetes & Kustomize
- ArgoCD applications
The deeper treatment of how each ecosystem is parsed, and where each one fights back, is in Auto-discovering infrastructure dependencies across 10 ecosystems.
Most valuable for teams that own shared infrastructure
-
Platform engineers
Maintain shared modules, images, charts, and templates consumed by dozens of other teams, and own the breaking changes to them.
-
DevOps & SRE
Need blast-radius analysis during an incident, to trace what depends on a failing component without grepping the org by hand.
-
Engineering managers
Coordinate breaking changes across teams without days of manual dependency discovery.
-
Organisations past ~50 repos
Polyrepo setups, especially with more than one infrastructure ecosystem in play.
The problem typically becomes acute past roughly 50 repositories and critical past 100, and it is worst for teams running several ecosystems at once rather than a single tool.
Why AI coding agents need the artifact graph specifically
An AI coding agent working across more than one repository hits the same wall a human does. The infrastructure edges that decide whether a change is safe live outside any single repository, which means they live outside the agent's context window. The agent can read the repository it has cloned. It cannot see, from inside that clone, which other forty repositories source the module it is about to change.
The artifact graph, exposed as a queryable API, is what closes that gap. And the property that matters most for an agent is the one in the definition: the edges are parsed, not inferred. A confidence score is fine for suggesting better code. It is the wrong guarantee for a deploy gate, where the question is not "what probably depends on this" but "what does." The argument for why a parsed graph and an inferred one are different machinery is in Inferred context is not a dependency graph. The cross-repo failure mode the graph prevents has its own name, defined on the sibling page What is AI agent blast radius?
Reconstruction is expensive
An agent re-deriving the graph from raw files pays the cost on every invocation. A precomputed graph is paid for once.
Freshness beats training
A model trained months ago does not know the repositories your team created last week. Last night's scan does.
The interface outlasts the model
Models change every few months. The artifact graph does not. A stable API over the graph has the same shape whichever agent is calling it.
Riftmap: an artifact dependency graph for your org
Riftmap is a change impact engine for multi-repo systems. It scans a GitLab or GitHub organisation with a single read-only token, parses every cross-repo infrastructure dependency from the actual source across all 12 ecosystems, and builds an interactive artifact graph with visual blast-radius analysis. The same graph is served as an HTTP API that AI coding agents can query during planning. No per-repo configuration. No catalogue to maintain.
Common questions
01 What is an artifact dependency graph?
An artifact dependency graph is a directed graph of which repositories in an organisation consume which shared infrastructure artifacts, such as Terraform modules, Docker base images, Helm charts, and CI templates. It is built by parsing the manifests that declare those relationships across every repository, so it shows the blast radius of changing any artifact directly, and stays current because it is derived from source rather than maintained by hand.
02 How is an artifact dependency graph different from a symbol graph?
A symbol graph indexes the functions, classes, and imports inside code. Sourcegraph's SCIP is the best-known example. It stops at the language boundary and does not parse infrastructure edges like a Dockerfile FROM, a Terraform source, or a Helm dependency. An artifact graph is built from exactly those edges, which run between repositories rather than between code symbols. They are different categories, and the artifact layer is the one a symbol graph cannot reach.
03 Is an artifact dependency graph the same as an SBOM or the OmniBOR / DHS ADG?
No. The OmniBOR specification and the DHS-CISA ADG work use "artifact dependency graph" for build provenance: a record of what went into producing one compiled binary, down to its source files, for supply-chain security. That graph looks down into a single build. The cross-repo artifact graph looks across an organisation to find what consumes a shared artifact. An SBOM, similarly, lists what is inside one artifact, while the cross-repo graph answers which repositories are affected when that artifact changes. Same words, opposite direction, different job.
04 How is it different from a service catalogue like Backstage or a modelled graph like Port?
A service catalogue or a modelling platform is the graph you describe and then maintain. An artifact graph is the graph your repositories already declare, parsed directly from their manifests. Modelled graphs are powerful for relationships that live nowhere in code. The artifact graph covers the relationships that do, which is why it can be auto-discovered and never declared, and why it does not go stale the way a hand-maintained catalogue does.
05 How is an artifact dependency graph built?
By static analysis across an entire Git organisation. Every repository is enumerated and shallowly cloned, each is inspected for what it publishes and for the manifests in which it declares dependencies on shared artifacts, and those references are resolved against the org and the relevant registries to connect consumers to producers, including transitively. The result is a directed graph assembled from source files rather than from declared metadata.
06 Why do AI coding agents need an artifact dependency graph?
Because the infrastructure edges that determine whether a cross-repo change is safe live outside any single repository, and therefore outside the agent's context window. An agent can read the repo it has cloned but cannot see which other repositories source the artifact it is changing. A queryable artifact graph answers that in a single lookup, it is parsed rather than inferred so it can gate a deploy, and it stays fresh between model releases.