The platform model
Pyplines separates what a procedure does, where it runs, and what happened when it ran. A team can reuse a Definition across Environments while retaining evidence for each execution.
The main objects
| Object | Meaning | Example |
|---|---|---|
| Action | A reusable operation with typed inputs and outputs, packaged as an OCI image | An Action that inspects a service |
| Definition | Portable YAML describing inputs and ordered Action steps | A service maintenance procedure |
| Environment | Registry mapping, public context, secrets, platform, and runner pool | development or production |
| Pypline | A Definition installed under a name within an Environment | production/service-maintenance |
| Revision | An immutable deployed Definition and its inspected, pinned Actions | Revision 3 of that Pypline |
| Run | An execution of one revision with supplied inputs | Run 42 |
| Attempt | Retained evidence for an individual step execution | The original invocation and a later retry |
A workflow is the procedure you are describing. Pypline is its installed form in Pyplines. A Run is one execution of that installation, not a new deployment.
From Definition to Run
- Select Actions available through the target Environment's registry.
- Write a Definition binding workflow inputs, Environment values, and earlier outputs to Action inputs.
- Deploy it. The server inspects contracts and pins image digests in a revision.
- Start a Run with input parameters. The Run captures its revision.
- Before each step, the server resolves current context and secret versions, validates inputs, and evaluates policies.
- An admitted runner executes the pinned image. The server retains the result and attempt evidence.
Updating a Pypline creates a new revision. It does not rewrite existing Runs. Environment context and secrets are resolved during preparation, so pinning a Definition does not freeze every external value for the lifetime of a Run. Changes can require new preparation and approvals.
Access and execution policy
Access assignments answer who may perform an operation. Execution policies answer what approval and recovery conditions must be satisfied. Permission to start a Run does not bypass its approval policy.
See access and policies, approving a step, and the execution architecture.