A release graph succeeds by removing edges

Graph Engineering pattern 9 of 15: the Release Pipeline Graph. Governance as topology — the guarantees are the missing edges, and the deliverable is provenance, not just the artifact.

Every other pattern in this series adds edges to gain capability. This one succeeds by removing them.

More communication edges are not necessarily better.

Context for new readers: pattern 9 of 15 in the Graph Engineering series, on designing agent organizations as graphs. A release is governance, and its graph should deliberately not be highly interconnected — which makes it the clearest illustration of the series' second thread: structure is a governance instrument.

The problem

Work must reach production having provably passed a sequence of checks — build, unit tests, integration tests, security, staging — with an accountable approval before promotion. The organizational requirement is not speed or creativity. It is that no path exists around the process.

The topology

  Build -> Unit -> Integration -> Security
                                     |
     Production <- Approval <- Staging

  no lateral edges - no skip edges
  approval: the only edge into production

Stages in a strict linear DAG. Each stage receives its input only from the previous stage's verified output and passes work forward only on success. Failure at any stage stops the line; the work exits the pipeline and re-enters the appropriate development graph (patterns 2, 3, 4), returning through the full pipeline. The approval stage is an explicit gate — typically human-held — and it is the only edge into production.

The guarantees are the missing edges

There is no edge from build to production, so unbuilt work cannot ship. There is no edge around the security stage, so unscanned work cannot ship. There is no lateral channel by which an agent can negotiate with a downstream stage. In most patterns, restricting communication costs capability; here the restriction is the capability — because the deliverable is not the artifact but the provenance of the artifact, the fact that it took this path and no other. A free-communication agent organization can produce a release. Only a restrictive DAG can produce a release you can make claims about.

Where it breaks

• The emergency bypass that persists. Every organization eventually adds a hotfix path. The discipline is to make it an explicit alternative pipeline with its own tighter gate — not a quiet extra edge that becomes the default under pressure.
• Gates that always pass. A stage that has not failed in months is either guarding nothing or being fed pre-sanitized input. Gate effectiveness is a system property; monitor it.
• Developing inside the pipeline. Push, fail, tweak, push means development is happening in the governance graph. Failures exit to a development pattern.

The dimension answers

Where rysh fits

Gates need enforcement that does not depend on agent cooperation. rysh's policy engine ships seven rule classes — bash allow/deny, auto-approve, always-gate, budget ceilings, proxy-required and secret-required — enforced with rule-ID citation, and an org policy that merges strictest-wins. And policy fails closed on every agentic path — including the case where a configured org policy file has gone missing, which blocks execution rather than degrading to no policy.

Honest scope

• The pipeline is an organizational design; what rysh ships is the policy engine and gates you build it from.
• Budget ceilings above are one of seven rule classes — they are a cost control, and rysh's own docs are explicit that a metering outage allows rather than refuses, deliberately.
• rysh is open-core: the CLI is Apache-2.0, the server is proprietary. It runs on Claude, with your own key.

Next: pattern 10, the Hierarchical Fleet Graph — what happens between five agents and fifty.

Building this with design partners → rysh.ai/design-partner