What you declare for a workflow
The entry needs a name and a list of steps. A step id is unique in that workflow. A step can name a function or a worker, or it can set human.title and wait. Triggers can start a run from a cron or a table change. kernstack plan shows the steps before a run can use them.
The workflow lives in the same project as the function it calls. A person who must accept a step sees that step by the title you wrote. The run continues after they accept. It does not depend on a second orchestration account.
What stays behind in Step Functions
Amazon States Language is not parsed into steps. Task tokens, activity ARNs, callback patterns, and the state machine role are not copied into resources.workflows.
You write each step. A human step is a title and, when you need them, the fields a reviewer may edit. It is not a Task state with a resource ARN brought across from an exported definition.
AWS Step Functions vs KERNSTACK on European Bare Metal
| Dimension | AWS Step Functions | KERNSTACK Workflows |
|---|---|---|
| Operator | AWS account | KERNSTACK project |
| Manifest | AWS Step Functions console or API | resources.workflows |
| Region | AWS region list | European bare metal |
| Bill | AWS Step Functions line item | One project credit balance |
Frequently asked questions
No. You write resources.workflows and its steps. Amazon States Language, task tokens, and activity ARNs are not copied.
A step with human.title waits until that person accepts. The same run then continues.
A function or a worker in the same project, or an AI step. The target is a name you declare, not an AWS resource ARN.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.