The controls on every workflow, and where each one stops.
Approvals, health checks, dry runs, the run record, AI budgets and permissions are part of the engine on every plan. Each is described below with what it does, a small illustration, and what it does not cover.
A run waits for a person where you put the step.
A human.prompt step suspends the run and puts a request in front of the people you choose, with the context they need to decide.
- A timeout on every wait. Choose how long the step waits and which branch the run takes when it lapses.
- Route on the answer. Approve and reject are branches like any other, so each outcome has its own next step.
- Recorded with the run. Who answered, when, and what they saw stay with the run.
Limits. Only steps with an approval node wait for a person; where they go is the workflow author’s decision. An approval records a decision, not that the decision was right.
Claim humanApprovals · unverified · checked 2026-09-28 · source: coax-backend human.prompt node and router (evidence register C12, C13, C16; E07 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-033)).
Checked on save and publish, with a named path for each finding.
Workflow Health validates each node against its schema and pre-flights each connection with a harmless call. What it finds goes down one of a few supported repair paths, or to a person.
- Auto Fix, one node at a time. It repairs a broken node, re-runs pre-flight, and moves on only if the fix held. Each repair is a version you can inspect and roll back.
- Code findings to a draft pull request. With the system health workflow installed, a code defect Auto Fix cannot answer goes to your host runner: planned, fixed on a branch, checked, and opened as a draft pull request, or filed as an issue when the fix is not safe to make now.
- Everything else to a person. Expired credentials, external outages and design questions are handed to someone on your team.
Limits. Health finds what its checks cover. A workflow that passes can still fail on real data or on an external system, and not every finding has an automatic repair. Nothing is merged or published without a person.
Claim workflowHealth · unverified · checked 2026-09-28 · source: coax-backend Workflow Health role, Auto Fix worker and the system-workflow-health template in coax-backend src/mantle/templates/data, which the site does not publish (evidence register C12, C13, C16; E07 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-033)).
See the shape of every step’s output before the first real trigger.
A dry run executes the graph with side effects suppressed. It is how you check that each step gets the fields the next one reads.
- What it shows. The path the run takes and the shape of each step’s output, from sample input.
- What it holds back. Writes and sends to connected systems are suppressed rather than made.
- Pair it with a test step. Pin a node’s output or test a single step against a test connection when you need a real response.
Limits. A dry run does not prove a write will succeed: it cannot show whether the target system accepts it, whether live data, limits or permissions match, or whether a code step or custom HTTP call has a side effect of its own. Use test connections for anything that must not be touched.
Claim dryRun · unverified · checked 2026-09-28 · source: coax-backend Workflow Health dry run (evidence register C12, C13, C16; E07 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-033)).
Read what a run did, and who changed what.
Each run keeps its steps with their status, input, output and the connection they used. The audit log records who changed which workflow, connection or setting, and when.
- Where a run is. A paused run says what it is waiting for; each step shows done, waiting or queued.
- What each step produced. Input and output beside the step, with the error when one failed.
- Exportable. The audit log can leave with your auditor.
Limits. The record covers what OCNORA did, not what an external system did with it afterwards. Retention follows your installation’s settings; no retention period is promised here.
Claim runAudit · unverified · checked 2026-09-28 · source: coax-backend run store and audit log (evidence register C12, C13, C16; E07 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-033)).
Every model call on a ledger, against a budget you set.
Each model call is recorded with its tokens and USD cost. Monthly budgets per workspace and per provider, and on Embedded per tenant, are checked before a call and reconciled after it.
- Checked before the call. A call the remaining budget cannot cover is not sent, and the run takes the path you configured.
- Circuit breaker. When a budget is used up or a provider keeps failing, further calls to it are held with a clear reason.
- Usage you can read. Spend by provider and by workflow, from the same ledger.
Limits. The pre-call check works from an estimate, so actual spend can differ from it: a budget is a limit you monitor, not an exact ceiling. It covers model calls made through OCNORA, not other use of the same provider account.
Claim aiBudgetUsage · unverified · checked 2026-09-28 · source: coax-backend AI cost ledger, budget router and circuit breaker (evidence register C12, C13, C16; E07 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-033)).
Who may do what, checked on every API route.
Owner, admin, editor and viewer roles are composed from individual permissions, and each API route checks the one it needs.
- Viewers read, they do not change. Runs and reports without access to a connection.
- Scoped API keys. Each key carries a permission scope and an expiry, and can be revoked.
- Same rules everywhere. The dashboard, the API and MCP clients go through the same checks.
Limits. This covers the four built-in roles; custom roles are not claimed. Permissions decide who may act, not whether an allowed action is a good idea: pair them with approvals on risky steps.
Claim rbacPermissions · unverified · checked 2026-09-27 · source: coax-backend RBAC permission matrix.
Encryption, PII crypto-shredding and tenant isolation are on the security page. For the rest of the platform, see the platform overview.
Walk through the controls on one of your workflows.
In a technical demo we add an approval step, set a budget, run Workflow Health and a dry run, and read the run record with you.