DAG Cards: Structured Artifacts for DAG Analysis

• DAG Cards are structured artifacts that encapsulate various representations of directed acyclic graphs, including ML pipeline documentation, causal inference units, and algebraic components.
• They integrate flow-level and run-level data to enhance reproducibility and provide a unified approach to tracking metrics, parameters, and testing in complex workflows.
• By employing standardized profiles and compositional methods, DAG Cards facilitate efficient workflow governance, clear causal reasoning, and precise measurement of DAG-ness.

DAG Cards are structured artifacts organized around directed acyclic graphs, but the term does not denote a single universal object. In the cited literature, one usage defines a DAG Card as documentation for a machine learning pipeline represented as a DAG; another organizes causal-DAG concepts, adjustment logic, and software workflows into card-sized units for use with DAGitty; and a third defines a DAG card for a directed network as the 5-tuple $\text{DAGCard}(G) = (A(G), F(G), M(G), S(G), D(G))$ in a continuous DAG-ness framework (Tagliabue et al., 2021, Textor, 2015, Csikos, 20 Jun 2026).

1. Terminological scope

The principal uses of the term in the cited works can be summarized as follows.

Usage	Underlying object	Core contents
Pipeline DAG Card	ML pipeline DAG	Flow-level and run-level documentation
DAGitty-style cards	Causal DAG	Definitions, rules, algorithms, workflows
DAG-ness card	Directed network	$(A,F,M,S,D)$ profile

In the pipeline-documentation sense, a DAG Card is a documentation artifact for a machine learning pipeline represented as a directed acyclic graph. In the DAGitty manual, the relevant material is explicitly organized into “card-sized pieces” covering causal DAG semantics, d-separation, adjustment sets, instruments, and workflow operations. In the continuous DAG-ness framework, a DAG card is a compact standardized profile of a directed graph based on four orthogonal components and their composite score (Tagliabue et al., 2021, Textor, 2015, Csikos, 20 Jun 2026).

These uses are related by format rather than by a single formal definition. This suggests that “DAG Card” functions as a presentation pattern for DAG-centered reasoning: a DAG is treated as the object around which documentation, inference rules, or structural diagnostics are organized.

2. Pipeline-level documentation in data-centric AI

In "DAG Card is the new Model Card" (Tagliabue et al., 2021), a DAG Card is a documentation artifact for a machine learning pipeline represented as a directed acyclic graph. The subject of documentation is the whole pipeline rather than an individual model. The proposal is grounded in a data-centric AI perspective, under which what happens before and after training becomes crucial for real-world deployments. The motivating claims are that modeling has been increasingly commoditized, that deep learning and pre-trained models often provide strong out-of-the-box performance, and that MLOps work around data collection, preparation, labeling, quality, testing, serving, monitoring, and drift handling is at least as important as model choice.

The pipeline is formalized using Metaflow’s terminology. A Flow is the DAG as a whole, a Step is a node of the graph, a Task is the unit of execution yielded by steps, data artifacts are task state such as variables and model weights, and a Run is a tracked execution of a Flow. This representation is intended to capture the fact that real-world ML systems are pipelines of interdependent tasks rather than stand-alone scripts. The card therefore aggregates both flow-level information, such as ownership and pipeline structure, and run-level information, such as parameters, training behavior, and metrics.

The documentation agenda is explicitly broader than model-centric reporting. DAG Cards are meant to cover data ingestion and access, preprocessing and feature engineering, model training, evaluation, behavioral testing, deployment and execution environment, and repeated runs. The paper treats behavioral tests as black-box stress tests over carefully chosen input-output pairs, including checks on specific subsets of users, regression tests, and edge cases. In this formulation, the DAG Card becomes a versioned documentation-as-code artifact tied to the implemented workflow rather than to a static prose report.

3. Structure, generation, and governance functions

The sample DAG Card described in the same work has two major levels: Flow-level data and Run-level data. Its sections include a title and menu keyed to the Flow name, a DAG description automatically rendered from the Flow class docstring via obj.__doc__, ownership information showing users and the distribution of runs per user, a structure-and-parameters section showing the DAG visualization plus parameters and input files, model architecture and training information for the last $k$ runs, loss-or-accuracy-per-epoch charts, and a behavioral-tests section (Tagliabue et al., 2021).

The run-level training section is described in terms of tuples such as

$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$

where $\theta_i$ are hyperparameters, $\mathcal{A}_i$ is the architecture summary, and $$\mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i$$ are per-epoch training and validation losses. The paper’s implementation path combines code introspection, Metaflow execution metadata, automatic file tracking, and third-party APIs such as Weights & Biases. The result is rendered as a vanilla web page. A stand-alone prototype is reported on GitHub, and a first implementation integrated into Metaflow’s official codebase is also reported.

Three design principles are emphasized. Low effort means that, if code is well-commented and decorated, updating the code automatically updates the documentation. Versioning means that cards can be generated after each run and can point to datasets, model weights, and artifacts, enabling debugging and reproducibility. Extensibility means that new sections, interactive elements, and metadata from other tools can be added. The governance function follows directly from these properties: the card is proposed as a one-stop repository linking structure, lineage, metrics, and test evidence for developers, engineers, product stakeholders, and, where applicable, auditors or compliance teams.

4. Causal-analysis cards and DAGitty

In the DAGitty manual, the relevant material is explicitly partitioned into “card-sized pieces” that define and operationalize core causal-DAG concepts (Textor, 2015). DAGitty itself is a web-based tool for drawing and analyzing causal diagrams. It assumes that the user’s DAG encodes the causal assumptions and then uses fast graph algorithms—d-separation, moralization, and path search—to answer causal identification questions. It does not learn DAGs from data.

The manual’s foundational card is the causal DAG itself. Nodes represent variables, arrows $X \to Y$ represent direct causal effects, and the functional semantics are given by

$Y := f_Y(X_1,\ldots,X_n,\epsilon_Y),$

with $\epsilon_Y$ jointly independent of all parents. The absence of an arrow $(A,F,M,S,D)$0 is treated as an assertion that no direct effect of $(A,F,M,S,D)$1 on $(A,F,M,S,D)$2 exists. The manual also insists that arrows should respect temporal order.

Subsequent cards define path types and blocking rules. For an exposure $(A,F,M,S,D)$3 and outcome $(A,F,M,S,D)$4, a causal path has the form

$(A,F,M,S,D)$5

whereas a biasing path is any other path between $(A,F,M,S,D)$6 and $(A,F,M,S,D)$7. DAGitty highlights open causal paths in green and open biasing paths in red. The d-separation card gives the blocking rules for chains, forks, and colliders and the implied conditional independence statement

$(A,F,M,S,D)$8

when all paths between $(A,F,M,S,D)$9 and $k$0 are blocked by $k$1.

A further cluster of cards concerns adjustment. A set $k$2 is a sufficient adjustment set for the total effect of $k$3 on $k$4 if all biasing paths are closed and all causal paths remain open. A minimal sufficient adjustment set is sufficient with no sufficient proper subset. The manual distinguishes total from direct effects, warns explicitly against adjusting for colliders or their descendants when estimating causal effects, and notes that DAGitty can report that no valid adjustment set exists when forced adjustment destroys identifiability.

Additional cards cover instrumental variables, conditional instruments, testable implications, moral graphs, correlation graphs, and workflow procedures. The workflow proceeds from defining the question, listing variables, and drawing the DAG, through marking exposure, outcome, unobserved, and adjusted nodes, to computing minimal sufficient adjustment sets, inspecting remaining red and green paths, and, when needed, seeking instrumental variables or checking testable implications. In this usage, “DAG cards” are not a separate software object; they are compact conceptual and procedural units for causal reasoning around a user-specified DAG.

5. DAG Cards as continuous DAG-ness profiles

"A Continuous Multi-Component Measure of Directed Acyclicity (DAG-ness)" defines a DAG card as a compact standardized profile of a directed graph based on four orthogonal components and their composite (Csikos, 20 Jun 2026). The framework is motivated by the claim that many directed networks are “almost DAGs”: they may contain small local loops, noisy back-edges, or symmetric edges while retaining a largely hierarchical flow. The paper replaces a previous five-component formulation with a strictly orthogonal four-dimensional framework designed to avoid topological redundancy, overlapping cyclic penalties, and the “Dilution Trap.”

A central construction is the filtered graph $k$5, obtained by deleting every symmetric edge pair. On this basis the framework defines: $k$6 which measures the volume of feedback via a heuristic minimum feedback arc set on $k$7;

$k$8

which measures alignment of flow relative to an Eades–Lin–Smyth ordering $k$9;

$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$0

which measures the macroscopic locality of feedback through the largest strongly connected component in $$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$1; and

$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$2

which measures dynamical pathway complexity using the spectral radius of the adjacency matrix of the raw graph. The composite score is

$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$3

with default uniform weights

$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$4

In this framework, the DAG card is the 5-tuple

$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$5

The fields are explicitly interpreted as feedback volume, hierarchical alignment, size of the worst feedback trap, dynamical recurrence, and overall DAG-ness score. The paper emphasizes that two graphs may share the same composite $$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$6 while having different profiles, and it presents radar and 2D embedding visualizations as natural display formats.

The paper also supplies canonical examples.

Graph	$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$7
Kaprekar	$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$8
Collatz	$$\text{RunInfo}_i = (\theta_i, \mathcal{A}_i, \mathcal{L}^\text{train}_i, \mathcal{L}^\text{val}_i),$$9
Modified Collatz	$\theta_i$0

These examples are used to show that Kaprekar and Collatz are structurally almost DAGs with a dynamical penalty due to recurrence, whereas the modified Collatz graph becomes a mathematically pure DAG with DAG-ness exactly $\theta_i$1.

6. Compositional and algebraic interpretations

A more abstract “card” interpretation appears in the algebraic literature on DAGs with interfaces. "The Algebra of Directed Acyclic Graphs" presents DAGs compositionally as morphisms in a PROP, and the accompanying explanation explicitly recasts this viewpoint as a component-library perspective (Fiore et al., 2013). In that perspective, a DAG with interface $\theta_i$2 has input and output ports, and a “DAG card” is naturally treated as a morphism $\theta_i$3 in the PROP $\theta_i$4 of finite abstract interfaced DAGs.

The generating operations are

$\theta_i$5

with the symmetric monoidal theory $\theta_i$6, where $\theta_i$7 is the theory of degenerate commutative bialgebras and $\theta_i$8 is the theory of a single node. Composition plugs outputs into inputs, while tensor juxtaposes components side by side. The explanation states that a “DAG card system” would treat each card as a morphism $\theta_i$9 in $\mathcal{A}_i$0, allow composition along matching interfaces, and use algebraic laws to optimize, normalize, or check equivalence of card assemblies.

This compositional sense differs from both pipeline documentation and DAG-ness profiling. It is not a reporting artifact and not a scalar diagnostic profile; it is a formal semantics for building complex DAGs from primitive cards such as duplication, merging, source, sink, and node operations. A plausible implication is that the phrase “DAG card” can denote either an explanatory wrapper around a DAG or a reusable DAG component, depending on whether the emphasis is documentation, analysis, measurement, or composition.