Config declares the plan. It does not start it. Applying reconciles the definition; the run is a separate, deliberate act:That split is what lets an alert name a plan: the plan exists as a durable resource rather than as a side effect of having run something.
Your flows and Roark’s
A flow row names exactly one offlow or system. They resolve through different paths, so a row naming both is refused.
roark simulation template list prints the slug of every curated flow and outcome.
happyPath and edgeCases are alternatives, not a union: asking for both is refused, because omitting both is already how you say “all of it”.
Which line to call
value is the endpoint’s own identifier, spelled the way kind: agent spells it. Omit it when the agent has exactly one endpoint; apply refuses to guess between several rather than dial a different number than you meant.
Everything else has a default
Onlyname, direction, agentEndpoints, metrics, flows and maxDurationSeconds are required. The rest default to what the dashboard would give you:
endCallReasons is worth knowing about if you run scripted flows. A simulated caller hangs up on an end-call phrase (something the agent says) or on one of these conditions. Running out of scripted steps ends nothing, so a flow scripted to a verdict needs a matching reason or the call stays on the line until maxDurationSeconds.
Alerting on the result
An alert scopes itself to a plan by name, which is why the plan’sname is also its stored name:
Apply order
Plans reference agents, flows and metrics, and alerts reference plans, so one apply resolves them in that order regardless of how your files are laid out:For the full field reference of every kind, see the Config DSL reference schema.