Governed Automation

Governed Automation is Novantra’s shared orchestration layer. It is how your organization defines automated workflows that watch for events, check conditions, and take actions across the governance program — without giving up the review, audit, and policy discipline the rest of the program relies on.

A governed automation is declarative: a rule says when it should fire (the trigger), what to check before firing (the condition), and what to do when it does fire (the action, expressed as a call to a registered actioner in another module). It is not arbitrary code, not unrestricted scripts, and not free-form outbound calls. Every action it can take is defined ahead of time; every execution leaves an audit-grade run record.

When you would reach for this

You set up automation when:

A recurring governance task can be triggered by a defined signal (a monitor result, a lifecycle transition, an evidence claim approval, a schedule).
A condition can be evaluated declaratively (a fact, an evaluation projection, a subject reference).
The desired action is one that an owning module already exposes as a safe actioner (open a finding, request evidence, route to a reviewer, propose a lifecycle transition, send a notification).
A workflow currently being done by a person on a schedule is a candidate for automation under governance.

You don’t reach for this for arbitrary integration code, freeform scripting, or direct mutation of another module’s truth tables. Automation invokes registered actioners; it never writes the final truth of another module directly. That’s the boundary that makes automation safe.

The three parts of an automation

Every automation definition has the same shape:

Trigger. What event or schedule causes the automation to consider firing. See Triggers.
Condition. Predicate evaluated against governed facts, evaluation projections, subject references, and context snapshots. The condition decides whether the trigger should result in execution.
Action. The bound actioner from a target module: create a finding, request evidence, propose a lifecycle transition, send a notification, etc. See Actions.

When the trigger fires and the condition is true, the action is invoked — either directly or, where the action is configured to require approval, through the review-approval gate.

Each execution produces a run with run items capturing the actions invoked and their outcomes. See Runs.

What you’ll see in the product

Governed Automation lives under Governance → Automation in the workspace.

Two top-level tabs: Definitions and Runs.

The Definitions list shows every automation with status, trigger kind, target action, recent run count.

The Runs list shows execution history across all automations, filterable by definition, status, date.

A worked thread: a cooperative credit union automates compliance discipline

A cooperative credit union runs a small operations team that maintains the credit union’s regulatory compliance posture: member account reviews, transaction monitoring follow-ups, supplier compliance attestations. Some of this work is well-suited to automation: predictable triggers, simple conditions, well-defined actions. The compliance officer, Sigrid, sets up automation across the next four pages.

She begins by sketching out which workflows are candidates: tasks that are repetitive, that have clear inputs, and where the action lives in an existing module. She rules out anything that needs human judgment in the condition itself, and anything that wants to take an action that isn’t an exposed actioner.

The result, after a few iterations, is six automations:

A weekly automation that checks for member accounts past their KYC review-due date and requests evidence from the relevant account manager.
A daily automation that watches for failed transaction monitor results and opens a finding routed to the AML lead.
A monthly automation that checks supplier compliance attestations approaching expiry and routes a request to renew.
An automation that listens for closed exception records and requests a follow-up assessment of the underlying control.
An automation that, on incident closure, ensures a post-incident review record exists; if not, requests one.
An automation triggered by changes in a regulator’s published rule list (via an external integration) that opens a finding for the compliance team to assess applicability.

Sigrid walks each through definition, dry-run preview, review-approval where required, and finally activation. The next three pages cover the parts of that workflow in detail.

Safety properties

The automation module enforces several properties that make it safe to entrust automation with governance work:

No final-truth writes outside the owning module. Actions invoke registered actioners; the actioner is what writes the target module’s truth. The automation module never short-circuits.
Dry-run is mandatory before any execution that could mutate. Definitions support preview runs that show what would happen without doing it.
Idempotency keys per item. Runs can retry items without double-execution.
Review-approval gates can be required on actions that should never fire autonomously (e.g., anything customer-visible, anything large, anything destructive).
Audit trail per run and per item. Activity, traces, and execution evidence are captured for every execution.
Actioner allowlists define what each definition is permitted to invoke; new actioners aren’t usable until the definition is updated to reference them.

Common workflows

Defining a new automation

Identify a candidate workflow with clear trigger, condition, action.
Automation → Definitions → New. Pick the trigger, define the condition, choose the action and configure its parameters.
Run a dry-run preview to confirm behavior.
Activate (with review-approval gate where applicable).
Monitor runs in the Runs tab.

Investigating a failed run

Open the run.
Walk the run items to see which actions succeeded and which failed.
Address the underlying cause (the upstream system the actioner depends on, the condition that didn’t evaluate as expected, a transient failure).
Retry from the run if applicable.

Retiring an automation

From the definition, transition to retired.
The automation no longer fires; historical runs remain visible.

Triggers - what fires an automation.
Actions - what an automation can do (actioner catalogue).
Runs - the execution evidence.
Findings - automation often creates findings.
Evidence - automation often requests evidence.
Monitoring - monitor results often trigger automation.
Review-Approval - approval-gated actions go through here.