Workflows

Enforced, evidence-verified playbooks. A workflow is markdown steps plus gates, and the gates are not checklists: they collect answers and run real engine checks against your live model. Think of them as MCP skills with teeth. Reading a playbook is free; running one with enforcement is Pro.

An instruction an assistant can ignore is a suggestion. A workflow gate is a wall the engine holds: the step does not pass until the required inputs are answered (or explicitly declined with a reason) and the verify checks actually run. The result is a repeatable, accountable way to perform a task, whether a person or an AI assistant is at the controls.

#In the Studio

The Workflows tab has two modes. Run mode shows the library rail (stock and your own workflows, each with a gated-or-free pill and its triggers), a step rail, and a gate panel where you answer or decline each question, submit, and watch the engine record its verify evidence (a rejection quotes the exact unanswered questions). Design mode builds a workflow as a chain of step cards, with action chips drawn from the live tool catalog so they cannot drift, and emits the markdown file deterministically (the file stays the artifact).

#Over MCP

Reading and following a playbook is free; the enforced run is the paid part.

list_workflows                         # the library: step count, gated/free, parse errors
get_workflow new-measure               # the full definition: instructions, gate inputs, verify checks
start_workflow new-measure             # begin an ENFORCED run (Pro when any gate enforces)
get_workflow_run                       # the live run state + the current step's questions
submit_workflow_step answers={...}     # submit; the ENGINE runs the verify checks
skip_workflow_step reason="..."        # accountable skip (a reason is recorded)
abort_workflow                         # stop; the partial record is preserved as data

list_workflows and get_workflow are free (the funnel): use them to follow a playbook manually, or to preview what a run will enforce. start_workflow is the one Pro chokepoint when any gate enforces (a workflow whose gates all resolve to off runs free). The finished run's full record (answers, declines, evidence) is appended to your experience log.

#How a gate verifies

The engine evaluates every gate, never the assistant. A step's verify checks are run against the live model and include:

• DAX probes: a value you supply as known-good is compared to the measure's live result.
• Equivalence proofs: a rewrite is proven to return identical values to the recorded original across a filter-context grid before it is accepted.
• BPA-clean and readiness-rescan diffs: the active findings are diffed against a start-of-run snapshot, so a step is judged on what it changed, never blamed for pre-existing violations.
• Benchmark budgets: a query's measured cost is checked against a budget.

Answers accumulate across the run, so a later step's probe can reference a value recorded earlier. Every input is answer-or-decline, a skip requires a reason, and when a check cannot run offline it is honestly marked skipped, never silently passed.

#Strictness and the enforcement toggle

Each gate resolves to a strictness: hard (a failure blocks the step), warn (it is recorded and the step passes), or off (skipped). Above all of that sits a model-wide enforcement toggle, the accountable owner's kill-switch:

get_workflow_enforcement               # read the model-wide mode
set_workflow_enforcement mode=off      # turn every gate off for quick tasks (ask the user first)
set_workflow_enforcement mode=default  # restore each workflow's own strictness

When enforcement is off, every gate is skipped with an honest note, runs record no verified evidence, and gated workflows start free. The setting is persisted beside the model and re-broadcasts the library so both doors see the gated flags flip.

#The stock library

Semanticus ships 32 stock playbooks beside the engine, authored from the semantic-model journey: from new-measure, import-table, make-ai-ready and pre-deploy-validation through optimize-dax (a hard equivalence gate on the recorded original) to a graded measure-authoring family (from author-simple-measures up to the fully benchmarked verified-measure). Each workflow carries a short when-to-use hint so your assistant picks the right grade for the job. A stock workflow is read-only; opening one to customise it creates a copy in your project's .semanticus/workflows that shadows the stock version, and deleting the copy reverts to stock. There is even author-a-workflow, a playbook whose hard gate is the admission check on the workflow it just wrote for you.

#Curate the menu, require a workflow

Two per-project controls shape how the library is used, both persisted beside the model and applied to both doors:

set_workflow_enabled name=... enabled=false   # take a workflow off the menu (still listed, easy to re-enable)
set_workflow_binding op=create_measure ...    # require a workflow for a task: bare edits are routed to it
get_workflow_policy                           # one call: what is enabled, gated and required in this project

A required workflow means a bare operation (say, create_measure) is refused with a plain explanation and pointed at the playbook; the edit is welcome at the workflow's own authoring step. The requirement reads independently of the strictness toggle, so relaxing gates for a quick task never silently removes a team mandate. Requiring a workflow is Pro; curating the menu is free.

#Authoring your own

A workflow is a skill definition: gate-free means pure instructions (it runs free), and gates make it Pro-enforced. Author or edit one with save_workflow, which parse-validates first: a file the parser refuses is never written and the error comes back verbatim.

save_workflow name=... markdown=...    # parse-validate then write (a bad file is never saved)
check_workflow name=...                # admission dry-run: resolve triggers/ops + gate inputs
replay_check_workflow name=...         # rehearse each step op through dry_run, model untouched
delete_workflow name=...               # remove a user workflow (a shadow reverts to stock)

check_workflow is the admission dry-run: it parses the file, then statically resolves it against the live tool surface and its own gate inputs (every referenced op must be real, and every verify must name an input some gate collects). replay_check_workflow goes further and rehearses each step op through dry_run, so the model is never touched. Both are free and read-only.

list_workflow_templates                 # the stock templates you can start from
get_workflow_template name=...           # read one, including the blanks to fill in
instantiate_workflow_template ...        # fill the blanks, get a runnable workflow
save_workflow_template name=...          # save your own template
delete_workflow_template name=...        # remove a template you added