GraphFlow — Release Safety Intelligence

Release pipelines as a live dependency graph — see blast radius, not just red X's.

Comment 1

Inspiration

Every CI/CD tool can tell you that a job failed. Very few can tell you what that failure means for the release.

In a simple pipeline, a red job is easy to understand. In a real production release, especially for payments, healthcare, fintech, commerce, or enterprise SaaS, one failed check can affect database migrations, approval gates, canary rollout, rollback safety, compliance evidence, and multiple downstream services. Teams often answer the important questions manually:

  • Can production still ship?
  • What exactly is blocked?
  • Is this failure on the critical path?
  • What should we fix first?
  • What evidence do we need for audit or change review?

Today, those answers usually live in job logs, Slack threads, tribal knowledge, and the head of the person who wrote the pipeline.

GraphFlow was built from one idea: a release pipeline is not a list of jobs. It is a graph of dependencies, risks, gates, and decisions. If we model it as a graph, we can reason about release safety automatically.

Simple positioning:

SonarQube checks code quality.
Snyk checks dependency and security risk.
GraphFlow checks release-flow risk.

GraphFlow answers the question that matters most before production:

Is this release safe to continue?

What It Does

GraphFlow is a release intelligence layer that sits on top of existing CI/CD. It does not replace GitLab, GitHub Actions, Jenkins, or any pipeline runner. CI/CD still runs the jobs. GraphFlow watches those jobs, maps them onto a release dependency graph, and turns pipeline status into release decisions.

For this hackathon build, GitLab is the first integration. A project adds a GraphFlow workflow config and a few CI jobs that register the graph, report node status, and call the release gate before production.

When a node fails, GraphFlow does more than mark it red:

  • It propagates the failure through the graph and marks downstream nodes as blocked.
  • It calculates the critical path so teams can see whether the failed node threatens production.
  • It evaluates a deterministic release gate: PASS, WARN, or FAIL.
  • It returns HTTP 409 on unsafe releases, so GitLab can block production as a required gate.
  • It records run state, timeline events, and compliance evidence.
  • It provides an optional agent explanation that summarizes why the gate failed and what to do next.

The important design choice is that the LLM never decides whether a release passes or fails. The gate is deterministic. The agent explains a decision already made by the graph engine.

One sentence:

GraphFlow turns CI/CD events into a graph-native release safety decision.

How We Built It

We built GraphFlow around a deliberate split: release topology and live execution state are different problems, so they should not be forced into the same database shape.

Aurora PostgreSQL stores the durable workflow graph:

  • tenants and projects
  • workflow definitions
  • release nodes
  • dependency edges
  • policies and audit-ready evidence

This data is relational, structured, and important to query correctly. Aurora is the right fit for workflow topology, constraints, graph-like joins, and durable release definitions.

DynamoDB stores the live run state:

  • run metadata
  • node status updates
  • CI event timeline
  • blocked node state
  • recent release history

This data is write-heavy and keyed by tenant, project, workflow, and run. DynamoDB gives us low-latency reads for dashboards and on-demand scaling for high-volume pipeline events.

EventBridge provides the event-driven foundation. Ingest APIs can accept CI updates without tightly coupling themselves to every future consumer. Lambda is used as the execution-worker foundation and can process node events independently as the system grows.

Vercel hosts the Next.js dashboard and API layer:

  • workflow registration API
  • GitLab ingest API
  • release gate API
  • run overview API
  • compliance export API
  • optional agent explanation API

The demo repo, checkout-service, behaves like a realistic production service. Its release graph includes build, unit tests, integration tests, dependency risk, static risk, migration review, approval, staging, smoke tests, canary, rollback planning, and production deployment. When the security scenario fails, GraphFlow blocks production and shows the downstream impact in the dashboard.

The architecture was built to degrade gracefully. If Aurora is not configured, the app can fall back to DynamoDB or static demo data. That made the demo resilient while still using real AWS databases in the deployed path.

Why This Is Different

Traditional CI/CD tools are excellent at execution. They run jobs, store logs, and show statuses. But release safety is not only an execution problem. It is a dependency problem.

A failed security scan, database migration review, payment contract check, or approval gate may have different meaning depending on where it sits in the release graph. GraphFlow understands that structure.

Instead of asking engineers to mentally trace the pipeline, GraphFlow computes:

  • blast radius
  • downstream blockers
  • critical path
  • bottlenecks
  • production gate verdict
  • audit evidence

That makes it useful for platform teams that need one standard release-safety layer across many repositories without forcing every team to rewrite their CI/CD.

Challenges We Ran Into

The hardest challenge was keeping the release gate trustworthy.

It was tempting to let the LLM make the final decision because it can produce persuasive summaries. But a production release gate must be explainable and repeatable. We made the deterministic graph engine the only authority for PASS, WARN, and FAIL. The agent can explain the verdict, but it cannot change it.

The second challenge was designing the data layer correctly. A release graph and live CI event stream have different access patterns. Aurora is excellent for graph definitions and evidence. DynamoDB is excellent for high-volume run state. Splitting them made the system more scalable, but it required clear read paths and fallback behavior.

The third challenge was making "blocked" meaningful. A blocked node is not just a UI state. It has to come from graph traversal: if a failed node is upstream of a production path, every affected downstream node must be marked and explained correctly.

The final challenge was cost discipline. This was built on a real AWS account with hackathon credits, so Aurora deployment is kept deliberate, DynamoDB uses on-demand capacity, and infrastructure changes are automated through CI/CD where appropriate.

Accomplishments That We Are Proud Of

We built an end-to-end release intelligence flow instead of only a dashboard mockup.

The system can:

  • register a workflow graph from a project config
  • ingest CI node updates
  • store graph definitions in Aurora PostgreSQL
  • store live run state in DynamoDB
  • calculate downstream blockers
  • calculate critical path and bottlenecks
  • return a deterministic release gate response
  • block unsafe production releases with HTTP 409
  • show the live release graph in the dashboard
  • export compliance-style release evidence
  • generate optional agent explanations through a swappable LLM provider

Most importantly, the demo proves the product thesis:

CI/CD tells us what ran. GraphFlow tells us whether the release is safe.

What We Learned

We learned that release pipelines become much more powerful when modeled as graphs instead of job lists. Once the graph exists, several high-value capabilities become natural: blocked-path analysis, blast radius, critical path, policy enforcement, and audit evidence.

The biggest product lesson was that GraphFlow should not compete with CI/CD. It should integrate with it. The value is not running jobs better. The value is helping teams understand whether the release those jobs represent is safe.

What's Next

The MVP focuses on one realistic GitLab-integrated checkout-service release. The next step is to turn GraphFlow into an enterprise release governance platform.

Planned next features:

  • multi-repo orchestration with parent releases and child project runs
  • rollback groups for services and database migrations
  • organization-level policy CRUD and enforcement
  • approval workflows with audit trail, RBAC, and SSO/SAML
  • database migration risk intelligence
  • release history, pattern detection, and bottleneck analytics
  • integrations with GitHub Actions, Jenkins, CircleCI, ArgoCD, Datadog, PagerDuty, and Slack
  • richer SOC 2 and PCI evidence exports
  • scalable agent layer using Gemma/Gemini now and paid managed inference later

The long-term vision is a control plane for release safety:

One standard release gate across many teams, many services, and many CI/CD systems.

Built With

Share this project:

Updates

posted an update —

To answer the "Why not just use GitLab YAML?" question—here is the TL;DR:

GitLab is an execution engine (it runs jobs). GraphFlow is a decision engine (it decides if a release is safe).

Here is why larger teams need that separate layer:

-Centralized Rules: Instead of updating gitlab-ci.yml in 100 different repos to enforce a new security check, you manage the policy in one place.

-Blast Radius: If a pipeline fails, GitLab just shows a red "X". GraphFlow calculates the critical path to tell you if production is actually blocked, or if it was just a minor doc check.

-Multi-Tool Unification: Most big teams don't just use GitLab. GraphFlow acts as a single source of truth across GitLab, ArgoCD, and external security scanners.

-Painless Audits: It automatically captures the exact reasons a gate opened or closed, giving you instant SOC 2 / PCI evidence without digging through raw job logs.

Log in or sign up for Devpost to join the conversation.