This page introduces the SADAR Process — SADAR's mechanism for grounding and propagating multi-step process flows across agents, tools, and organizations — and describes the SADAR Process Definition (SPD), the flow grammar an SPD carries, and the per-node request interfaces that drive runtime discovery. It stays at the architectural level; the full normative specification lives in the Process Flow Specification companion document.
Audience: enterprise architects, process and integration architects, planner-agent implementers, and enforcement-layer implementers responsible for grounding and executing SADAR Processes.
A SADAR Process is a multi-step flow, named by an IRI, that expresses what is to be done and in what order. Processes in SADAR are not exclusively business processes. They include both business-oriented workflows — insurance claims processing, credit risk analysis, patient registration — and purely technical processes — document ingestion, data transformation, content indexing, asynchronous job orchestration. The same mechanism grounds both.
Conceptually, a SADAR Process is similar to a RosettaNet PIP: a defined, multi-step flow that several parties can participate in without bilateral pre-coordination. SADAR generalizes the idea across arbitrary frameworks and standards — grounding process intent in references such as APQC PCF concepts or X12 transactions — and allows those references to be composed in any way an author requires.
A SADAR Process is consumed in two ways. A planning agent reads a process to understand an optimal flow — its steps and their predecessors, defined both within the participating agents and by the process itself — and to assemble an execution plan. An enforcement layer reads the same process at runtime to apply ordering and other operational policy. A process may also define SAGA-like compensating transactions for rollback; those are an extension consumed by the enforcement layer, not substrate behavior (see Boundaries).
The SADAR Process is the IRI — it names intent. The SADAR Process Definition (SPD) is the structured artifact that realizes that intent: a signed manifest carrying the actual flow. Because processes are composable, there is no single canonical flow for a given intent — one organization's order-placement flow may legitimately differ from another's, and multiple SPDs may realize the same grounding concept.
An SPD is a signed manifest — the same kind of registry artifact as any other SADAR manifest, with the same isolation, signing, JWKS-published key, and immutability-per-version properties. What distinguishes it is a single added field: the flow. There is no separate dereferencing step to reach the flow; to obtain a process, an agent searches the registry on the criteria it cares about and receives the SPD, with the flow as a field on that manifest.
Beyond the fields every manifest carries, an SPD adds the following.
Because an SPD declares its input and output through the standard Provider interface, an SPD is itself a provider. A node in one process's flow may resolve, at discovery, to a subordinate SPD just as readily as to an agent or tool — which is how processes compose. Whether a node resolves to a subordinate process or to a non-process provider is determined at discovery, not declared in advance.
An SPDFlow is a directed graph written in a Cypher-inspired path notation. A flow with parallel branches is a graph, not a list: a step may split into parallel branches, branches may nest, and branches converge at joins. The notation captures that structure compactly, one statement per line, typically opening with a namespace prologue that binds short prefixes for readability.
Nodes and references. A node is written in parentheses. A work node is a namespaced name — for example (apqc:10279) — whose entry in SPDComponents supplies the criteria SAI uses to find a provider for it at runtime. A structural node expresses graph shape (a split, a join, or a reserved system boundary) and does not resolve to a discovered provider.
Two edge operators connect nodes. The left-hand side of a statement is always a node.
Function labels are metadata. A node may carry a label such as fanout, fanin, or SYSTEM. These hint a node's role to a consuming planner or enforcement layer; the substrate preserves them but does not interpret them. The substrate's role is to carry the graph, preserve every name and reference intact, and resolve each work node through discovery — not to orchestrate. The process author and the selection resolver are accountable for defining each node's criteria correctly and selecting correctly; what is found operates as the criteria specified.
Nesting is emergent, and discovery happens once. Nested parallelism needs no flag — a split/join pair on a path inside another pair simply is nested, recoverable from the graph itself. And a node is discovered at its first occurrence; every later reference to the same node, including one appearing on two arms of a branch, reuses that single selected provider. Node identity is the resolution key.
An organization (“acme”) extends APQC's definitions with two internal steps — select among the quotes from an earlier step, then verify budget — before finding a provider to create and issue the purchase order. Every edge is a single handoff; the flow emits its result through the terminal boundary.
Each bracket-form target is a work node with one SPDComponents entry. The terminal (SYSTEM:return) is structural and has none.
This flow requests quotes from two vendors concurrently, joins the results, and selects among them. The split declares its branch set in one bracket statement; each branch emits into the join with the arrow form; the join hands off to the selection step.
The work nodes — acme:quote_vendor_a, acme:quote_vendor_b, acme:select_quote — each have a request interface; the structural nodes fanout:quotes and fanin:quotes do not. How the join behaves — wait for both, or release on the first — is expressed in the criteria the join resolves to and applied by the consuming layer, not defined by the substrate.
An SPD is published into a registry and discovered exactly as any other manifest. There is no process-specific ingestion validation and no process-compatibility evaluation: an SPD becomes a candidate because it matched the requester's criteria. When a process is selected and run by a consuming layer, each of its work nodes drives a further discovery through SAI — resolved once per node and reused across the flow.
Composition across organizations follows from this. An entity does not declare an entire end-to-end chain in its manifest; it declares the steps it implements, and the chain lives in the SPD that composes them. Different participants can satisfy different nodes of the same process without coordinating, because every node is resolved independently at discovery.
The SADAR Process grounds and propagates flow; it does not execute it. Several adjacent concerns are out of scope for the substrate and live elsewhere.
Where to Learn More