Summary
Automation is only useful to an operating company if it can run, explain what happened, and hand uncertainty to a person without losing the thread. We use four recurring shapes to make that possible: pipelines maintain data, jobs initiate automatic work, services expose capabilities, and review surfaces carry stateful human intervention.
Problem
Many workflows need all four. A domain may ingest source material, run on a schedule, apply reusable policy, and stop when the evidence is not strong enough to continue. Collapsing that into one abstraction feels simpler because there are fewer names and files. In practice, it hides which part owns truth, which part owns execution, and where repair is supposed to happen.
Principle
Choose the shape by responsibility. Pipelines should not wait for a person. Jobs should not hide durable review state. UI routes should not become the only place business behavior exists.
Platform Shape
Pipelines live under pipelines/ and perform deterministic ingestion and transformation. Jobs live under jobs/ as executable wrappers around services, libs, integrations, or pipelines. Services under services/ own reusable capabilities. Review surfaces combine API, UI, services, and OLTP state so ambiguity has an identity, evidence, and a next action.
Together they form an escalation path. A job runs the automatic portion. When the workflow reaches genuine business ambiguity, it records an issue or review task instead of improvising. A person resolves that state through a surface, and automatic work can resume with the decision attached. The handoff becomes part of the system rather than another fact someone has to remember.
Tradeoffs
Four shapes create more explicit seams than a single script or workflow file. Those seams are worth maintaining when the work crosses time, callers, or human judgment. For truly local deterministic work, the smallest fitting shape is still the right one.