7.1 The pipeline service: authored like files, run on any verb

A pipeline composes services into a multi-step flow. Because every service speaks the message contract (3.1), a pipeline step can call any mount, and the response flows into the next step. The pipeline service lets you author these flows and mount them at a URL.

Mounting it

{ "path": "/orders", "service": "pipeline",
  "config": { "access": { "write": "A", "invoke": "A" } } }

Two surfaces: authoring and execution

Like query (Part 6), a pipeline mount has two faces (the store-transform pattern):

• Authoring — /<mount>/.pipelines/…, the full store contract (PUT/GET/ DELETE, listings, ETags). Pipeline specs live here; guard with write. A spec's inline access (per-spec execution gating) is operator-only (5.4).
• Execution — every other path under the mount, on any HTTP verb, runs the longest-prefix-matched stored spec, with the request's verb and URL intact.

The stored document (envelope)

A pipeline spec is stored as an envelope, validated and canonicalized at write time (string DSL → typed spec):

{ "pipeline": <typed spec | string-DSL array>,
  "retry": <policy>,
  "input": <request JSON Schema>,
  "output": <response JSON Schema>,
  "description": "…",
  "x-agent": { … } }

input and output are optional, advisory schemas surfaced in discovery and OpenAPI. PUTting an envelope with a malformed spec, condition, URL pattern, JSONata expression, or schema fails at write time, not at execution.

The .root spec: wrap a whole mount

A spec named .root governs the mount root and every otherwise-unmatched subpath. Combined with any-verb execution, this is powerful: a pipeline can transparently wrap another service. Mount a pipeline in front of your data, put a .root spec that adds a security check then forwards to the real data mount, and clients see an unchanged API with new behavior layered in. (This replaces v1's modal "manage mode" header — verbs simply pass through.)

If there's no matching spec and no .root, execution returns 404 pointing at .pipelines/.

Internal calls re-enter dispatch

This is the property that makes pipelines safe and composable: when a step calls a URL, that call re-enters full dispatch — the same routing, authorization, limits, and idempotency that an external request gets. A pipeline isn't a way around your rules; it's a first-class caller subject to them. A logged-in user's principal propagates into the steps, so a pipeline can't escalate past that user's access (5.4).

The one exception is an absolute http(s):// call URL, which leaves the node — gated by the mount's httpOut grants (allowlist-checked before any I/O, credentials injected host-side, principal never forwarded). See 7.3.

Introspection

GET /<mount>/.pipelines/<spec>?$plan returns the canonicalized spec plus its execution plan (segments and warnings) — invaluable after authoring in the DSL, to confirm what the runtime actually stored (7.8).

The next section covers the two ways to write a spec.

← Part 6 — Querying and rendering data · Manual home · Next: 7.2 Typed spec and string DSL →