A back-end pipeline: an immutable Input projected into a mutable Data, walked by a list of named Steps grouped by execution mode, finally projected into a read-only Result handed back to the caller. Maps onto ProcessRunner<TInput, TData, TResult> at runtime. Fields the caller hands to RunAsync. Emitted as an immutable record (C#) / frozen dataclass (Python). Mutable working object shared across steps. Step methods read + write Data via the protected `Data` field on the generated base class. Init from Input is auto-generated for any same-named field; extra fields stay default-initialised. Fields handed back to the caller. Emitted as a read-only record (C#) / dataclass (Python). Auto-projected from Data by the generated BuildResult. The pipeline. Steps run in declaration order; consecutive Parallel ones are batched. Each Step becomes an abstract method on the generated base + an AI-stub override on the user-owned impl class. When true (the default), the runtime auto-resolves a tracking store via ProcessTrackingResolver — DB-backed when AppSettings:Process:Tracking:ConnectionKey is configured, in-memory otherwise. No ctor parameter at the call site: derived classes need NO constructor; callers stay on `new OrderProcess().RunAsync(input)`. Set to false only when you want the resolver bypass to be the type-level default (rare — usually leaving the config key unset gives the same effect). Optional: names the Input property whose value populates the tracking row's key1_name/key1_value columns at run start. Generator emits `SetKey1("X", input.X?.ToString() ?? "")` at the top of InitData. Lets operators find this run via IProcessTrackingStore.FindByKeyAsync("X", "value") without remembering the system run_id. Validated at parse time — must reference an existing Input property name. Optional second key slot — same semantics as key1. Use when one run is queryable by more than one business handle. Optional third (and last) key slot — same semantics as key1. Further dimensions belong in a separate audit table joined on run_id. One step in the pipeline. The generator emits a Base{Name} class with one abstract method per step, plus a user-owned {Name} class that overrides each. The override body is either a deterministic forward (when <Implementation kind="DomainMethod"…/> is present — same shape Service methods use) or an `// AI GENERATION REQUIRED` stub for the implement step to fill, using the step's `documentation` attribute as the spec. Optional declarative binding to a hand-authored domain-service method. When present, the generator emits the impl class's override body as `new {DomainService}().{Method}(Data)` (await-prefixed for non-Sync modes) instead of an AI stub. Omit to keep the step AI-implemented. One- or two-line description of what the step does. Surfaced verbatim in the generated abstract method's XML doc, so the AI-implement step (and any human reader) sees it as the spec for the body. Required in spirit for AI-implemented steps; ignored for declarative-binding steps. Set when `kind="DomainMethod"`. Name of the hand-authored domain-service class the impl class instantiates. Mutually exclusive with `service`. C# emits `new {DomainService}()`; Python emits `{DomainService}()` (paired with the import line driven by `pythonModule`). Set when `kind="ServiceMethod"`. Name of a sibling generated service class. Mutually exclusive with `domainService`. Use this when the step's work is best expressed as a call into another Service in the same backend (a generated REST handler, an existing CRUD endpoint, etc.). Set when `kind="ProcessMethod"`. Name of a sibling generated Process. The parent's step runs the entire sub-Process via `RunAsync`: same-named fields from the parent's Data flow into the sub's Input automatically, the call is awaited, the parent throws on sub-failure, and any same-named fields from the sub's Result are copied back into the parent's Data. Method on the domain-service class to call. Signature contract: takes the generated Data type as its single argument (`void Method(MyProcessData data)` for Sync mode; `Task Method(MyProcessData data)` otherwise). The method mutates Data in place. Optional C# namespace of the target class. When set the C# generator emits a `using` line at the top of the impl file so the bare class name resolves. Python is unaffected — Python consumers add the `from … import …` manually in their impl file (which is WriteIfAbsent-preserved). Kept implementation-agnostic at the XML level: this is the same `namespace` attribute every Service / Process XML root carries, just re-used to name a reference's target. Forward the step to a hand-authored domain-service method. Pair with `domainService=` + `method=`. Forward the step to a sibling generated service method. Pair with `service=` + `method=`. Forward the step to a sibling generated Process. Pair with `process=`. The parent's step runs the sub-Process as one atomic unit; `method=` is ignored (sub-Process entry point is always `RunAsync`). Run synchronously inline; block the caller thread until the step returns. Awaited normally — sequential, non-blocking. Batched with consecutive Parallel steps into a single concurrent fan-out. Steps in the batch must write to distinct Data fields to avoid races. Runs after Result has been returned to the caller. Failures are observed (via the runtime's step observer) but don't propagate.