Governance: presets, instructions & the publish floor

Workflows describe work; governance decides who signs off on it, which model performs it, and what a graph must contain before it may be published. This page covers the four levers you'll actually touch: gates as decisions, presets, node instructions, and the publish floor.

Nothing approves itself: no gate auto-resolves unless you explicitly opted that specific gate in — and the separation-of-duties floor never can be.

Gates are decisions

Every gate a running workflow reaches becomes a card in your Decisions queue. The run pauses; the card carries the gate's label, its instructions, and any typed fields the author asked you to fill. You resolve it with one of three verbs:

• Approve — the gated step resumes once every step before it has completed.
• Skip — cancels the gated step; the run continues without it.
• Fail — fails the step, and the workflow's failure routing takes over.

Or do nothing: an unresolved gate just waits. Nothing moves until someone decides.

One rule sits above all three: you never approve your own proposal. The identity that resolves a gate must be different from the one that proposed the work, and a gate raised by an agent always requires a human. If ARDS cannot attribute the resolver, it refuses the resolution rather than guessing.

Never automatic by default

No gate auto-approves out of the box. Auto-resolution is a per-gate opt-in: you grant it explicitly, for that one gate, and every automatic resolution is logged. The grant is also tied to the exact content it was given for — if what the gate guards changes, the gate comes back and asks a human again.

Even with opt-ins, one floor never moves: the separation-of-duties gate that stands between a mission's accepted work and your project can never be made automatic — not by configuration, not by waiver. Runs are accepted by you; the promotion past that point is decided by you too.

Presets

A preset is a named bundle of model and provider choices (plus the tool transport that goes with them) used by a workflow's generative nodes. Rather than hard-coding a model on every node, you bind a preset and manage the choice in one place.

Presets carry a scope — global, project, or customer — and the most specific one wins: a project-level binding beats a customer-wide one, which beats a global one.

Two facts matter in practice:

• Presets resolve at dispatch, not at publish — when a run starts, the preset bound at that moment wins, even over what was authored on the canvas. Publishing froze the graph, not the model choice.
• Resolution walks a chain — a preset bound at dispatch wins; otherwise the node's authored (pinned) preset applies; otherwise the site-wide default preset fills in. If nothing names a model anywhere, the run refuses to start rather than guessing.

You bind a preset on a draft with the selector in the editor. Fleet profiles are a different lever entirely — container sizing and concurrency, not model choice; see Fleet tuning.

Node instructions

A workflow's coder and agent nodes can carry node instructions — an instruction binding that replaces the node's authored instructions at the next dispatch (for a coder, inputs and the outcome contract are recomposed unchanged; for an agent, the binding replaces its task text), without touching the published graph or its checksum. Exactly one binding applies — the most specific: run beats project, which beats tenant, which beats global.

Today you set node instructions by hand, from the editor or per run when you start one. ARDS proposing a better prompt on its own is not in v1; if that lands, the proposal will arrive as a decision you approve or reject — nothing will ever apply itself.

The publish floor

A workflow counts as governed when your organisation's control catalogue applies to it — in practice, as soon as its graph writes anywhere that matters. For a governed graph, two things happen before publish:

• Every write needs a stage — one of Design, Implementation, Integration, Verification, PreDeployment. The stage tells the floor which controls that write requires.
• The required controls are injected as part of publish — the gates and reviews the catalogue demands land in the published graph as real nodes, visually marked as injected. Publishing from the editor injects them during the publish itself; to review them on the draft before publishing, agents run the workflow_materialize tool, which writes them into the draft exactly like nodes you placed yourself. Publish is refused until the graph is complete.

The check is deterministic: the same graph plus the same control catalogue always yields the same controls — the LLM never synthesizes compliance. And the floor only ever adds: governance can raise the bar above what you authored, never quietly lower it. Publishing itself is covered in the workflow lifecycle.

Waivers

When a required control genuinely doesn't apply, you don't delete it — injected controls are non-negotiable on the canvas. The escape hatch is a waiver: explicit, tied to one control, carrying a written reason, and permanently logged. A waived control stays visible as waived, not absent.

Some controls cannot be waived at all. The 25-year retention rule is one: no reason, however good, removes it.