Workflow Graph Validator

Overview

You send the steps of a workflow and the edges between them, and we tell you whether that graph can actually be run: no step depending on itself, no loop, no edge pointing at a step you never declared, no step declared twice. When something is wrong you get the offending ids back, not just a verdict — the loops, the dangling references, the duplicates, and the independent groups the graph splits into. A broken graph is a normal answer here, so structural problems come back as a report with valid set to false rather than as an error. We only read the graph you send: we run nothing, schedule nothing, and store nothing.

A workflow whose graph has a loop or a dangling edge fails somewhere in the middle of a run, after side effects have already happened. Checking the shape before anything executes turns that into a rejected submission with the offending ids in hand.

When to use it

Scope

Non-goals

• Does not run, schedule, or store the workflow
• Does not order the steps — workflow.topological_sort does that
• Does not invent steps for edges that reference unknown ids
• Does not judge what a step does, only how it is wired

Properties

Capabilities

Cost & billing

Flat rate per invocation

File handling

How we handle your data

Input schema

Output schema

API contract

curl -sS -X POST "$BASE/v1/execute" -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' -d '{"skillKey":"workflow.validate_dag","input":{"nodes":[{"id":"extract"},{"id":"load"}],"edges":[{"from":"extract","to":"load"}]}}'

import { Squillify } from "@squillify/sdk";

const sq = new Squillify({ apiKey: process.env.SQUILLIFY_API_KEY });

const { output } = await sq.execute("workflow.validate_dag", {"edges":[{"from":"extract","to":"transform"},{"from":"fetch-rates","to":"transform"},{"from":"transform","to":"load"}],"nodes":[{"id":"extract"},{"id":"fetch-rates"},{"id":"transform"},{"id":"load"}]});

Errors

Other limits

Limitations

• Does not run, schedule, or store the workflow
• Does not order the steps — workflow.topological_sort does that
• Does not invent steps for edges that reference unknown ids
• Does not judge what a step does, only how it is wired
• Executing or scheduling the workflow
• Graphs where cycles are legitimate, such as state machines with returns
• Ordering steps, which is a separate skill

How to call

POST /v1/execute (requires authentication)

{
  "skillKey": "workflow.validate_dag",
  "input": {
    "edges": [
      {
        "from": "extract",
        "to": "transform"
      },
      {
        "from": "fetch-rates",
        "to": "transform"
      },
      {
        "from": "transform",
        "to": "load"
      }
    ],
    "nodes": [
      {
        "id": "extract"
      },
      {
        "id": "fetch-rates"
      },
      {
        "id": "transform"
      },
      {
        "id": "load"
      }
    ]
  }
}

Examples

{
  "edges": [
    {
      "from": "extract",
      "to": "transform"
    },
    {
      "from": "fetch-rates",
      "to": "transform"
    },
    {
      "from": "transform",
      "to": "load"
    }
  ],
  "nodes": [
    {
      "id": "extract"
    },
    {
      "id": "fetch-rates"
    },
    {
      "id": "transform"
    },
    {
      "id": "load"
    }
  ]
}

{
  "roots": [
    "extract",
    "fetch-rates"
  ],
  "cycles": [],
  "duplicateNodes": [],
  "valid": true,
  "missingNodes": [],
  "_meta": {
    "issuesTruncated": false,
    "cyclesTruncated": false,
    "declaredEdgeCount": 3,
    "componentCount": 1
  },
  "disconnectedComponents": [],
  "edgeCount": 3,
  "nodeCount": 4,
  "issues": [],
  "selfLoops": [],
  "duplicateEdges": [],
  "leaves": [
    "load"
  ]
}

{
  "edges": [
    {
      "from": "a",
      "to": "b"
    },
    {
      "from": "b",
      "to": "a"
    },
    {
      "from": "c",
      "to": "c"
    },
    {
      "from": "c",
      "to": "d"
    }
  ],
  "nodes": [
    {
      "id": "a"
    },
    {
      "id": "b"
    },
    {
      "id": "c"
    }
  ]
}

{
  "roots": [],
  "cycles": [
    [
      "a",
      "b"
    ],
    [
      "c"
    ]
  ],
  "duplicateNodes": [],
  "valid": false,
  "missingNodes": [
    "d"
  ],
  "_meta": {
    "issuesTruncated": false,
    "cyclesTruncated": false,
    "declaredEdgeCount": 4,
    "componentCount": 2
  },
  "disconnectedComponents": [
    [
      "a",
      "b"
    ],
    [
      "c"
    ]
  ],
  "edgeCount": 4,
  "nodeCount": 3,
  "issues": [
    {
      "code": "MISSING_REFERENCE",
      "count": 1,
      "message": "An edge references an id that no node declares, so that dependency cannot be honoured."
    },
    {
      "code": "SELF_LOOP",
      "count": 1,
      "message": "A node depends on itself, which can never be satisfied. Self-loops are also counted as cycles."
    },
    {
      "code": "CYCLE",
      "count": 2,
      "message": "Nodes depend on each other in a loop, so no order can satisfy every edge."
    },
    {
      "code": "DISCONNECTED",
      "count": 2,
      "message": "The graph splits into independent groups. You allowed that, so it does not make the graph invalid."
    }
  ],
  "selfLoops": [
    "c"
  ],
  "duplicateEdges": [],
  "leaves": []
}

Recommended use cases

• Reject a broken pipeline definition at submission time instead of mid-run
• Show an author exactly which steps form a loop
• Confirm a generated or merged graph is still executable

Avoid for

• Executing or scheduling the workflow
• Graphs where cycles are legitimate, such as state machines with returns
• Ordering steps, which is a separate skill

Related skills

Composable with

Safety & privacy

• Runs without calling any external service.
• Your payloads are never stored permanently.
• Telemetry captures metadata only — never your payload contents.
• We never train models on your payloads.
• No human reviews your payloads.

Tags