Governance and audit
Governance belongs in the execution, not in a report written afterwards.
Identity, permissions, separation of duties, secret handling and the evidence record are properties of the run itself. The same controls apply whether the step is a visual action, a code node, a model call, an infrastructure change or a human decision.
Every step is attributable
Identity, permissions and evidence travel with the run, so the outcome and the reason for it stay in the same place.
- through your identity provider
- SSO and MFAthrough your identity provider
- with separation of duties
- RBACwith separation of duties
- inputs, outputs and results
- Per-nodeinputs, outputs and results
- per execution
- One recordper execution
The principle
An after-the-fact reporting layer explains failures. It does not prevent them.
Many organizations automate first and reconstruct the evidence later from logs held in several systems. That approach produces a narrative that is expensive to assemble and difficult to defend.
Reporting after execution
Evidence is reassembled
- Controls live in documents rather than in the process
- Logs sit in several systems with different retention
- Approvals live in mail threads and ticket comments
- Credentials are shared because nothing scopes them
- Questions are answered from memory
Governance during execution
Evidence is a by-product
- Checks and thresholds are steps the engine enforces
- Every node keeps its own inputs, outputs and result
- Approvals are nodes with reviewer, decision and reason
- Secrets are referenced from a vault, never inlined
- Questions are answered from the run
Identity and access
Who can build, run, approve and publish.
Access control is the first governance question, and it is answered with the identity infrastructure the organization already trusts.
Single sign-on and multi-factor authentication
Nexus authenticates users against the identity provider the organization already runs, so joiners, movers and leavers are handled once. Multi-factor requirements are inherited from that provider rather than maintained separately in the platform.
Directory integration
Active Directory and LDAP groups can be mapped to platform roles. Membership changes in the directory flow through to what a user may see, run, approve or publish.
Role-based access control
Permissions are granted to roles, not to individuals. Viewing a workflow, editing it, running it, approving a step and publishing a revision are distinct rights that can be held by different people.
Separation of duties
The person who builds a workflow does not have to be the person who publishes it, and the person who requests an action does not have to be the person who approves it. Those boundaries are configured, then enforced by the engine at run time.
Workspace boundaries
Workflows, credentials, connections and execution history belong to a workspace. Teams, business units and environments stay separated, and access is granted per workspace rather than globally.
Service and machine access
Automated callers use scoped credentials with their own permissions, so a webhook or scheduled job cannot quietly act with a named user's authority.
Secrets
Credentials are referenced, never embedded.
Automation is only as safe as the way it holds the keys to the systems it touches.
Vault-backed storage
Connection credentials, API keys, certificates and service accounts are held in the secret store and resolved at run time. Workflow definitions carry a reference, so an exported or reviewed workflow does not expose a secret.
Scoped by workspace and role
A credential belongs to a workspace and is usable by the roles permitted to use it. A builder can use a production connection without being able to read the value behind it.
Use is recorded, values are not
Runs record which credential authorized which call. Secret values are kept out of execution logs and out of node outputs, which keeps the record safe to share with reviewers.
The record
What an execution leaves behind.
The value of the audit trail is that it is produced by the same engine that performed the work, so it does not depend on anyone remembering to write it down.
Execution history
Every run is retained with its trigger, the identity or event that started it, start and end times, and final status.
Per-node results
Each step keeps its own inputs, outputs, duration and outcome, so a failure or an unexpected value can be traced to the node that produced it.
Approval history
Human decisions record the reviewer, the decision taken, the reason given and the data presented at the time of the decision.
Change history
Workflow revisions record what changed, who changed it and who published it, which separates a behaviour change from a data change.
Credential references
Runs record which credential was used, not the credential value. Use is provable without the secret appearing in the log.
Observability signals
Run metrics, failures and queue behaviour can be exported to the monitoring and log platforms already operating in the estate.
Attribution
Every kind of step answers the same questions.
What ran, on whose authority, against which data, with what result. The answer should not depend on whether the step was clicked together, written in code, produced by a model or decided by a person.
Workflow steps
The version of the workflow that executed is recorded with the run, so behaviour can be reconstructed even after the workflow has moved on.
Code nodes
Code runs as a versioned part of the workflow revision. Inputs, outputs and errors are captured in the same execution record as visual steps.
AI steps
The model endpoint used, the input supplied, the output returned and any retrieved knowledge references are retained with the run, so a model result can be reviewed later.
Infrastructure actions
Cluster, environment, target and parameters are recorded alongside the result, which keeps a change to running infrastructure traceable to the process that requested it.
Human decisions
Reviewer identity, role, decision, reason and timestamp are captured as structured fields, not as a comment in another tool.
System write-backs
The target system, the payload sent and the response received are stored, which links the authorized decision to the change it produced.
Worked example
A high-impact change, approved by the right role, evidenced end to end.
Supplier bank detail changes are a common fraud target, which makes them a fair test of whether governance is real or documented.
- 01
Trigger
A supplier bank detail change is submitted, carrying the requester identity from the authenticated session.
- 02
Integration
Connector and database steps retrieve the existing supplier master record, recent payment activity and the original onboarding evidence.
- 03
Rules + Code
Deterministic checks compare the request against the record, test the change against policy thresholds and confirm that the requester is not also an authorized approver for this supplier.
- 04
Sovereign AI
A self-hosted model summarizes the supporting correspondence and highlights inconsistencies for the reviewer to consider.
- 05
Human Approval
A finance controller with the required role reviews the assembled case and approves, corrects or rejects with a recorded reason. Above a defined value the case routes to a second approver.
- 06
System Action
Only after approval does the workflow write the change to the ERP using a vault-backed credential scoped to that operation.
- 07
Audit
The request, retrieved data, rule outcomes, model output, both approvals, the payload sent and the ERP response are retained as one execution record.
- 08
Review
An auditor can open the run months later and see what was known, who decided, on what basis and what changed.
Policy and change
Publishing controls and revisions.
Changing what an automation does is itself a governed action. Treating it as one is the difference between a controlled platform and a shared scripting host.
Draft, test, publish
Changes are made in a draft revision and tested before they take effect. Publishing is a separate, permissioned act, which keeps editing and releasing apart.
Revisions are retained
Earlier versions remain available, so a run can be explained against the logic that was live at the time rather than the logic that is live today.
Environment separation
Development, test and production workspaces hold their own credentials, connections and permissions. A change is promoted deliberately instead of being edited in place on production.
Policy expressed as workflow logic
Approval thresholds, mandatory checks, segregation requirements and routing rules are configured as steps in the process, which means they are enforced during execution rather than reported on afterwards.
Controls apply to code and AI equally
A code node and a model call sit inside the same workspace permissions, the same secret handling and the same execution record as a visual step. Extensibility does not create a governance gap.
Evidence
Supports verifiable evidence and a clear chain of custody.
Nexus produces a first-hand record of what the platform did. That record is generated by the executing engine and retained inside your environment, which is what makes it defensible.
First-hand, not reconstructed
The evidence is the execution, captured as it happened, rather than a summary written later from several partial sources.
Custody stays inside your boundary
Execution history, approval records and model inputs and outputs are stored in the deployment you control. Nothing has to leave the environment for the record to exist.
Export to your systems of record
Records and events can be forwarded to the log platform, archive or evidence store your organization already uses for retention, so platform retention is not the only copy.
Careful wording on assurance
Nexus supports verifiable evidence for the actions it performs. It does not assert that a process is compliant. That judgment belongs to your auditors, against your control framework.
Boundaries
Operating responsibilities.
Your organisation defines controls and approval thresholds. Nexus enforces configured policies and records the work it executes.
Configured controls and evidence
Nexus enforces the controls you configure and records their application. Your organisation uses those records in its compliance and audit processes.
Execution-record boundaries
The record covers work performed through the platform. Manual steps taken outside it remain outside the execution record.
Organisation-owned control design
Separation of duties and approval thresholds have to be defined by the organization. The platform enforces them once they are configured.
Evidence for your audit
Execution records support review of your controls and operating procedures. Auditors assess your environment and its evidence against applicable requirements.
Control review
Bring your control framework, and we will map it to the execution.
Most governance conversations stall on where the evidence lives. Walk through a real process with our team and see which controls become workflow steps and what the resulting record contains.