Skip to main content
nika.yaml governs the project around the SDK. A *.nika.yaml file carries one executable workflow. Keeping those roles separate is the foundation of a clean application integration.

​
Two valid released profiles

Use the arm-ready profile when the project clock starts work:
Use the run-policy profile when application code or an operator starts direct workflow runs:
Both are live. They are separate because the current released cadence reader does not yet accept the direct-run traces and registry rungs. The closed project-shape vocabulary remains . An unknown key refuses with its line and the accepted set. A present file that silently ignores a typo would be more dangerous than an absent file, so the parser never drops one.

​
Discover the governing file

The engine walks from the current working directory toward its ancestors and uses the first nika.yaml, like Git finds .git.
DISCOVERY · FIRST PROJECT ROOT WINS
Prefer a cwd at the project root. It keeps workflow paths, project discovery and .nika/ state aligned. The CWD and monorepos page documents the split when a nested process room is intentional.

​
Found and inspect

The init flag lays a commented starter and skips an existing file unless --force is explicit. nika arm validates an arm-ready project and cadence grammar, reports its armed beats and schedules nothing. A direct run consumes the run-policy profile through the normal project discovery path.
Do not pass nika.yaml to LocalNika.run(). The local SDK runs a *.nika.yaml workflow. The engine discovers nika.yaml from cwd and applies its project policy around that run.

​
Continue through the project