Forgeplane assemblies and dependency graphs

A Forgeplane assembly coordinates multiple template operations as a directed acyclic graph (DAG). It is useful when infrastructure delivery has dependencies: downstream nodes wait for upstream outputs, approvals, or successful completion before they become eligible.

Explore an assembly run

Step through a published example to see output bindings, independent branches, and a node approval gate. Each event is simulated and advances only when you choose it.

One graph. Independent branches.Interactive demo

All nodes, outputs, approvals, and workers are simulated. This illustrates scheduling, not the exact product UI. Nothing connects to Forgeplane or changes infrastructure.

service-stack · published v1.0.0
The demo starts after publication, with Network already running.

Step 1 of 7

Wait for upstream outputs

Network is running. Database and Monitoring wait for its network_id output. Application waits for Database's endpoint.

Network

Running

Output: network_id (string)
Not available

Database

Waiting for network

Input from Network
network_id (string)
Not available

Output: endpoint (string)
Not available

Monitoring

Waiting for network

Input from Network
network_id (string)
Not available

Independent of Database's approval.

Application

Waiting for database

Input from Database
db_endpoint (string)
Not available

What an assembly contains

Each node references a template operation. Edges define execution order, and typed bindings pass compatible upstream outputs into downstream inputs. Secret-marked inputs use secret-catalog bindings; secret values are materialized only for execution and are not stored inline in the graph.

Forgeplane validates node references, edges, bindings, input compatibility, and acyclicity before publication. A graph with a cycle cannot become an executable version.

The editor uses the server’s flattened contract fields for mapping suggestions and excludes sensitive fields from ordinary mapping choices. Manual advanced paths remain available for server validation; composite and array schemas do not gain extra suggestions from a separate browser schema reader.

If a template version’s contract is invalid or unavailable, that whole version is unavailable in the editor rather than appearing partially loaded. Use the contract error/retry state while continuing to edit other nodes.

Drafts and immutable versions

Assembly edits happen in a draft. A draft lock gives one editor control of mutations and prevents concurrent edits from silently overwriting one another.

Publishing creates an immutable assembly version. Only published versions can run. The version diff shows node, edge, binding, and configuration changes before an operator publishes or executes a modified graph.

A running assembly remains tied to the published version selected at start. Editing a later draft does not change the graph of an active assembly run.

Assembly execution

Starting an assembly creates an assembly run tied to one published version. The coordinator schedules a node only when its dependencies and bindings are satisfied. Each node also has its own run record, while the assembly record tracks graph-level progress.

A typical dependency flow is:

1. publish the template versions used by the graph;
2. create or validate the assembly draft;
3. acquire the draft lock and inspect the version diff;
4. publish the immutable assembly version;
5. start an assembly run;
6. wait for upstream nodes and bindings to become eligible; and
7. review node results and the assembly-level outcome.

Node approvals

A node can require approval before its execution intent is queued. The Assembly node remains pending approval; dependent nodes wait for that decision while unrelated eligible branches can continue.

Approving this gate requires assembly:approve and the owning Team’s team.metadata.write action. The coordinator checks the actual Assembly Run and node, not the latest published version. An authorized approval of a node that is no longer pending returns 409; missing or inaccessible targets return the same generic 404.

Authorization

Assembly lists, details, versions, and nested Run views require team.metadata.read plus either assembly:read or workload:read. Visibility alone grants no editing, execution, or approval authority.

Creating, editing, deleting, restoring, and publishing require assembly:write plus team.metadata.write. Starting, canceling, and resuming through Assembly endpoints require assembly:run plus team.metadata.write. Direct Run endpoints retain their separate Run permissions. See Permissions for the platform-role and Team-role mapping.

The server rechecks current Principal, ownership, Team, lifecycle, and relevant execution state inside each mutation transaction. A previously visible UI action or successful access review is not permission to bypass that check. The execution Environment must belong to the Assembly’s Project.

Cancel and resume

Cancel stops further node scheduling and requests cancellation of active node runs where possible. Cancellation of a running tool is best-effort. Completed node results remain part of the assembly-run record.

Resume re-evaluates the stored DAG state and schedules remaining eligible work. It does not replay nodes already recorded as complete or replace the published assembly version.

Operating checklist

• Publish before execution; drafts are not executable.
• Compare version changes before publishing a modified graph.
• Hold the draft lock while editing.
• Keep secret values in the secret catalog, not graph definitions.
• Check Assembly approval permission separately from direct Run approval permission.
• Review cancel and resume at both assembly and node level.

See Templates, Runs, and Approval workflows.