A workflow is the structural backbone of automated work in Xema. It is written in the @xemahq/dsl grammar, compiled to a typed IR, and executed on the Xema Workflow Runtime. Each job in the workflow may call an agent or a full composition, emit artifacts, pass through a gate, or branch on matrix outputs. Phases are structural — they sequence jobs and stamp phaseKey on emitted artifacts — but they are not a config-resolution dimension on their own. Workflows are first-class objects (XemaObjectKind.Workflow) and biomes ship them through contributions.

Calling constrained capabilities

A step that calls a capability marked callerConstraint: "workflow-step" runs as one of the biome's own components. A biome that declares components and contributes workflows names that component in workflowConfig.runAs:

1{
2  "xema": {
3    "workflowConfig": { "runAs": "mailops-api" }
4  }
5}

runAs is a component key (a service or worker the biome declares). A content-only biome declares no components, omits runAs, and its constrained calls are refused with CAPABILITY_CALLER_CONSTRAINT_UNMET. A Bridged store installation runs as its installed workload biome-workload:<installationId>:<apiName>; an unbridged install or a lock member fails the step with WorkflowStepCredentialError stating the reason.

Each constrained call carries a per-call step credential minted for the target's receiver audience (see capability).

A run started under an org delegation asserts the Organization subject through the router's replay child. authorizedBy is provenance only and never grants authority. Every call is capped by the delegation's lend.