Published versions are immutable and content-addressed. Editing a workflow produces a new version; nothing already running observes the change. This is what makes an execution that started three days ago still explainable.
Validation happens before publication, not at execution time. Cycle detection by topological sort, dependency resolution, task-type registration and tenant policy are all deploy-time gates, so a broken DAG cannot reach a queue.
An execution binds its version once, at submission. Late binding to 'latest' was rejected: a long-running execution would otherwise change behaviour mid-flight and become impossible to reason about.
Schema evolution rules
Additive only within a major version: new optional fields and new task types are a minor version bump. Removing a field or changing a task's semantics requires a new major version.
Deprecation blocks new executions but never deletes. A version cannot be deleted while any execution references it, which is enforced in the store rather than by convention.
The DSL is validated against a published JSON Schema that ships with the CLI, so the same errors appear locally as in CI as at the API.
Assumptions
Workflow size is capped at 500 tasks, and the cap is enforced at validation. View 31 explains why: a wider DAG concentrates RU and storage on one logical partition.
Task-type registration is a platform-team operation. Self-service handler registration is deferred to V2 because it is a supply-chain question, not a workflow question.
Definitions are assumed to be non-sensitive. Payloads may contain personal data; the DAG structure is not treated as confidential.
