An immutable left-to-right chain of commands wired stdout -> stdin, with **no shell** involved: each stage's standard output feeds the next stage's standard input directly. The whole chain runs inside one shared kill-on-dispose group, so cancelling, timing out, or disposing the run reaps every stage together. Build it by piping commands (`a.Pipe(b).Pipe(c)`), then run it to completion with the same run-and-capture verbs a single command exposes (`RunAsync`/`OutputStringAsync`/`OutputBytesAsync`/`ExitCodeAsync`/ `ProbeAsync`/`ParseAsync`/`TryParseAsync`). To stream the final stage's stdout as it arrives instead of buffering the whole chain, start a live session with `StartAsync` (→ `PipelineSession`), the pipeline analogue of `Command.StartAsync` → `RunningProcess`. The exit status follows shell **pipefail**: the rightmost stage that did not exit with an accepted code (its `Command.OkCodes`, `{0}` by default) determines the result, unless that stage opted out with `Command.UncheckedInPipe`. When no checked stage failed, the final stage's real outcome and diagnostics are returned; an unchecked voluntary exit remains successful because its actual code is included in the result's accepted codes, not because the outcome is rewritten. Per-stage I/O config that applies inside a pipeline: each stage's `OkCodes` (pipefail) and `UncheckedInPipe`, the last stage's `StdoutEncoding`, `StdoutTee`, and `OutputBuffer` **byte** cap (`MaxBytes` + `Overflow`, applied to the captured stdout — its `MaxLines` never applies to a raw byte capture), stage 0's `Stdin` source (feeding the whole chain), and the chain-level `Timeout` / `CancelOn`. Every stage's stderr is likewise drained under its OWN `OutputBuffer`'s **byte** cap (`MaxBytes` + `Overflow`; a stage without `MaxBytes` set keeps its stderr unbounded, as before), so a chatty stage can never exhaust memory regardless of its position in the chain. Per-stage *stdout/ stderr observation* hooks are still **not** applied — intermediate stages' `StdoutTee`, every stage's `StderrTee`, and `OnStdoutLine`/`OnStderrLine` — because the chain wires stdout into the next stage's stdin and captures only the final stage's output. Observe an individual command by running it on its own, not as a pipeline stage. A stage's `CapturePolicy` is bound by that same boundary — every capture a pipeline makes (the final stdout, and each stage's stderr) is a RAW BYTE capture with no line framing, which is also what leaves `OutputBuffer.MaxLines` inapplicable here — but it is **rejected** rather than left unapplied, because a redaction hook that quietly stops running hands back the secret it was installed to remove (see the rejected-config paragraph below). Per-stage config a pipeline cannot honour is **rejected when the stage is piped** (an `ArgumentException` from `Pipe`, naming the field and stage index), rather than silently dropped: a `Stdin` source on any stage *after the first* (its stdin is always rewired to the previous stage's stdout — only stage 0 may set a source), a per-stage `Timeout` on any stage (only the chain-level `Pipeline.Timeout` bounds a pipeline; `Command.Timeout` on a stage never fires), a per-stage `IdleTimeout` on any stage (a pipeline captures only the last stage's output and does not monitor per-stage output activity, so a stage's own idle deadline can never fire), a per-stage `Retry` on any stage (retry is a verb-layer mechanism, and stages spawn directly, bypassing it), and a per-stage `CancelOn` on any stage (a stage's own `Command.CancelOn` token is likewise a verb-layer mechanism the direct stage spawn bypasses; only the chain-level `Pipeline.CancelOn` cancels a pipeline), `KeepStdinOpen` on any stage (the pipeline exposes no per-stage `RunningProcess.TakeStdin` handle through which the kept-open pipe could be used), a per-stage `CapturePolicy` on any stage (every capture a pipeline makes is a raw byte capture, so the seam has no decoded line to shape — run such a command on its own to scrub what it captured), `StdoutToFile` on any stage (stdout is instead pipeline wiring or final captured output), and `Stdout(StdioMode.Null|Inherit)` on any stage (the pipeline must use a pipe rather than silently override that destination). `StderrToFile` remains supported: it directs that stage's diagnostics to the requested file while the chain continues to carry stdout. Set the deadline on the pipeline, cancel the whole chain with `Pipeline.CancelOn`, feed stage 0, or run the command on its own. `MergeStderr` (a shell `2>&1`) is allowed only on the **last** stage — its stdout is the pipeline's captured output, so merging captures the final stage's combined stdout+stderr. On any earlier stage it is rejected (`ArgumentException`) the moment the stage stops being last (another stage is appended after it): a pipeline wires each stage's stdout into the next stage's stdin, so an OS-level merge on an intermediate stage would inject its stderr into the downstream stage's input data. Observability is whole-pipeline, not per-stage: running the chain emits one `Log.spawn`/`Log.exit` pair (plus `Log.timeout` on a timeout) and one `Diag.runStarted`/`runCompleted`/`runEnded` triple, all sharing a single run id — never one set per stage. Stage 0's `Logger` becomes the pipeline's logger (a per-stage `Logger` on any *other* stage has no effect — set it on stage 0, or observe an individual command by running it on its own); the `program` tag/label is a composite of every stage's name, joined `"a | b | c"` (built only from `Command.Program`, never argv/env, so the argv/env-never-logged invariant holds for a multi-stage run too). Stage 0 likewise owns `StopSignal`, because graceful shutdown broadcasts one soft signal to the whole chain — and, for the same reason, `CancelGrace`/`CancelSignal`: a cancelled chain (`Pipeline.CancelOn` or the verb's own token) is torn down through ONE soft signal and ONE grace window over the shared group, so setting either on stage 0 makes the whole chain's cancellation graceful, and setting it on a later stage is rejected rather than ignored. The chain-level `Pipeline.Timeout` is untouched by that knob and keeps its immediate hard kill. `StreamBuffer` depends on how the pipeline is run. For buffered verbs (`RunAsync`, `OutputStringAsync`, `OutputBytesAsync`, `ExitCodeAsync`, and similar verbs used without `StartAsync`), it is inapplicable because there is no streaming consumer to receive the policy. `StartAsync`, however, returns a live `PipelineSession`: the last stage's `StreamBuffer` policy is applied to the session's stdout channel, including its bounded-buffer/backpressure behavior. `KeepStdinOpen` is rejected with `ArgumentException`, not accepted as a silent no-op. Although `PipelineSession` is a live handle, it does not expose interactive stdin: the pipeline wires each stage after the first from the previous stage's stdout itself, and exposes no user-reachable `RunningProcess.TakeStdin` handle.