Lineage Graphs

View and navigate a project's lineage graphs, inspect their nodes, and check their verification status.

About Lineage Graphs

A lineage graph is an interactive visualizer of a lineage manifest — a cryptographically verifiable record of how a dataset, model, or other asset was produced, generated by the EQTY SDK. It lets you trace and evidence every step of your workflow while flagging any assets that require further verification.

Lineage graphs render each asset and computation in a manifest as a node, and the connections between them as edges, so you can follow exactly how an output was derived from its inputs. Every node can be inspected for its registration details, verification status, and any metadata attached during creation.

Key concepts and actions associated with Lineage Graphs include:

Understanding Lineage Graph scope
Getting a lineage graph into a project
Understanding node types
Viewing a Lineage Graph
Navigating a Lineage Graph
Understanding verification statuses
Viewing node instances

Understanding Lineage Graph scope

Lineage graphs live within a single project and cannot be shared or viewed across projects. A project can contain multiple lineage graphs, each corresponding to a manifest registered by the SDK.

Any project member with access to the project can view its lineage graphs.

Getting a lineage graph into a project

Lineage graphs are created outside Guardian. You record your workflow with the EQTY SDK and register it with Integrity Service under the project. Every project already has a root graph whose ID is the project’s UUID; the SDK registers your workflow as a new graph beneath it.

Install the SDK.
bash
python -m pip install eqty_sdk
Get an API key. Registering needs the Create Declarations permission on the project, which Organization Owners, Project Owners, Implementation Owners, and Implementation Contributors hold. Generate an API key with the Create Declarations and View Project Data scopes, bound to the project, and set it as EQTY_API_KEY where the workflow runs. The SDK reads it from there.
Find the project UUID. Open the project’s Dashboard and select the copy button beside the UUID under the heading.

Record the workflow and register it. For example, lineage.py records a training run in which train.py turns a dataset file into a model directory, and registers it as a graph named Fraud Model Training under the project. from_path fingerprints the contents at each path, so run it after training, beside the files it names:

python

from uuid import UUID

from eqty_sdk import (
    Code,
    Computation,
    Context,
    Dataset,
    Model,
    Service,
    Signer,
    init,
    set_active_signer,
)

# The project's UUID, and a name for the new graph
project = Context.from_uuid(UUID("urn:uuid:fd47f68b-8760-4d0d-94fa-7658924acb25"))
graph = Context.with_parent(project).new("Fraud Model Training")
cfg = init(default_context=graph)
# Creates a signing key on the first run and reuses it, and its DID, after that
set_active_signer(Signer.load_or_create(name="lineage"))

transactions = Dataset.from_path("data/transactions-2026-q3.parquet", name="Transactions Q3")
code = Code.from_path("train.py", name="train.py")
model = Model.from_path("models/fraud-detector-v4", name="Fraud Detector v4")

Computation.new(name="Train Fraud Detector").add_input_cid(
    [transactions.cid, code.cid]
).add_output_cid([model.cid]).finalize()

# Integrity Service is at your platform host followed by /integrityService
service = Service.new("https://guardian.example.com/integrityService")
cfg.get_default_context().register(service)

bash

EQTY_API_KEY=ak_… python lineage.py

View it. In the project sidebar, select Lineage Graphs, then select Refresh. The graph is listed under the name you gave it.

Each run registers a new graph, so running the script again adds a second Fraud Model Training graph rather than updating the first. A registration without Create Declarations on the project is refused with 403 Forbidden. For signing with a key held by Auth Service instead of one created on this machine, and for every class the SDK offers, see the SDK documentation. If you already have an exported manifest, the Integrity Service API registers it directly with POST /manifest/v1; see the Integrity Service API reference.

To fetch a registered graph’s manifest from a script, pass its UUID as graph_ids. The Graph UUID column on the Lineage Graphs page shortens each UUID; hover it to see it in full. The call needs View Project Data on the project:

bash

curl "https://guardian.example.com/integrityService/manifest/v1?graph_ids=<graph UUID>" \
  -H "Authorization: Bearer $EQTY_API_KEY" \
  -o manifest.json

Repeat graph_ids to export several graphs into one manifest. Blobs are included unless you add include_blobs=false.

Understanding node types

A Lineage Graph is made up of nodes connected by edges. Each node represents an asset or computation registered by the SDK. Node types include:

Agent
Benchmark
Benchmark Result
Binary
Certificate
Code
Computation
Configuration
Credential
Database
Dataset
Document
Guardrail
Media
Model
Prompt
Reasoning
Skill
System Prompt
Token
Tool

A node whose type the manifest does not name is shown as Unknown.

An edge between two nodes indicates a direct relationship — for example, a computation node connected to a dataset node means that dataset was either an input to or an output of that computation.

Viewing a Lineage Graph

To view a project’s Lineage Graphs:

Select a project from Projects
In the project sidebar, select Lineage Graphs
Search for a graph by name or UUID, and select the checkbox beside each graph to view
Select View Lineage

A graph registered beneath another graph is nested under it; select the arrow beside a graph’s name to show the graphs beneath it. Select several graphs to open them together in one canvas.

The project's Lineage Graphs page: a search box with the Refresh and View Lineage buttons above a table of four graphs, including Fraud Model Training, with their names, graph UUIDs, and created and last-updated times. Training Data Lineage has an arrow to show the graphs nested beneath it.

This opens the graphs in an interactive canvas:

The Fraud Model Training graph open in the canvas: the dataset input and the code file compute.py feed one computation step that outputs the model output, with a search box, the graph and table view toggle, zoom controls, and Download Manifest.

Navigating a Lineage Graph

Once a graph is open, you can:

Pan and zoom the canvas to explore the graph’s structure
Search nodes by their properties with the search box above the canvas
Select a node to open its detail panel. A group of nodes opens a Group Summary of its members instead.
Select an edge that records an association to open an Association panel naming the two ends and the statement behind it
Toggle between graph and table view using the Graph view / Table view selector in the top-right corner of the canvas
Download the manifest of every graph you opened with Download Manifest. It saves as a JSON file named after the graph, and the download is recorded in Activity Logs.

Node detail panel

Selecting a node opens a detail panel. Its sections appear when the node has data for them:

Registration

Node ID: The node’s unique content identifier (CID).
Timestamp: When the node was registered. Computation nodes use this label; every other node type labels the same field Instance — see Viewing node instances.
Registered By: The signer who registered the node, including any attached user information (such as name or email).
Executed On: The identity of the host the workload ran on, shown as a signer badge. Computation nodes only.
Operated By: The signer who operated the workload. Computation nodes only.
Anchors: Any external anchor recorded for the node, shown as type:txHash, each with a View link to the anchor’s explorer.
Statement: The node’s registration record, and its verification status – with an option to View json.
Credential: The node’s Verifiable Credential attesting to the statement, and its verification status – with an option to View json.

Metadata

Any additional metadata attached to the node during registration, such as description, contact information, license, or other domain-specific fields defined by the SDK user.

Governance

For a node with a governance registration: its context, registration ID, who registered it and when, and the subject and document it links.

Storage

For a node with a storage registration: its context, the data stored, where it is stored, who operated and registered the storage, and when, with an option to View json.

Sigstore Bundles

Any Sigstore bundles attached to the node, each shown with its decoded DSSE payload.

Understanding verification statuses

Each node’s Statement and Credential are independently verified in your browser to confirm they haven’t been tampered with. A node can show one of two statuses for each:

Verified: The statement or credential’s cryptographic proof is valid.
Unverified: The statement or credential’s cryptographic proof could not be validated.

An Unverified status should be investigated — it means the integrity of that particular statement or credential cannot be confirmed, even if the rest of the graph verifies successfully.

Viewing node instances

A node can have multiple instances if the underlying asset was registered more than once — for example, across separate runs. When a node has multiple instances, the Registration and Metadata sections each include an Instance dropdown listing each registration, along with the timestamp for each.

Each dropdown is separate: selecting a different instance in Registration updates that section only, and the one in Metadata updates the metadata shown.

Lineage Graphs — how Integrity Service records lineage and the questions a graph answers
Projects — the project sidebar, where Lineage Graphs lists a project’s graphs
Key Concepts — what CIDs, DIDs, and verified status mean
Glossary — definitions of lineage manifest and related integrity terms