Product
Governed Workflows
Versioned workflow definitions that run only registered operations, check authority before each step and wait for approval bound to the action.
On this page
What it does
Governed Workflows runs multi-step work under rules the platform checks, instead of trusting whoever proposes the steps. A definition is a typed graph, not code: it composes operations from a closed registry and cannot invent one by naming it.
How a run proceeds
- Define. A definition is validated: unknown operations, broken edges, unreachable nodes, unbounded cycles, unpinned approval policies and over-budget graphs are rejected.
- Start. A run is pinned to the passed definition version and stays on it.
- Authorise. Each call step is authorised against the requesting principal immediately before its effect.
- Approve. An approval step waits for a decision bound to the specific action; a proposal does not authorise itself.
- Record. Requested, authorised, attempted, committed and verified are separate rows for each step. A step's effect, its outbox item and the run transition commit in one transaction.
You can start and inspect runs, and decide approvals, from Workflows.
Operating needs
- PostgreSQL; durable run state and the outbox live there, so no message broker is needed.
- A person with authority to decide approvals.
Limits
- A new primitive operation is a code change, not configuration.
- A failed step is retried after a delay and within an attempt budget; the platform does not claim exactly-once effects outside its own database.
- Whether a run achieved its wider purpose is not decided automatically; the platform checks that the recorded effect is present.
Availability
Governed Workflows is running on RJV's own platform. RJV does not sell a licence for it as a separate product today: the commercial terms state what is on sale. It can be part of the result of an engineering engagement, where the written proposal names it, its licence terms and what you would hold at the end. To discuss it, use Work with Us.
Evidence
Validation, authority checks, approval binding and retry behaviour are covered by the platform's own tests. The evidence register lists the graded claims.
Works with
- Audit Chain: Requires. Runs and approvals are recorded in the chain.
- Identity and Access: Requires. Every step is authorised against the requesting principal.
- Process Automation and Agents: Works with. Automation runs on versioned workflows with approval steps.
Where it runs
| Supported target | A customer-controlled Linux host on x86-64 with PostgreSQL 18 (linux-x86_64-customer-controlled). |
|---|---|
| Not yet supported | Windows, macOS, phones and tablets, and Linux on other architectures. Each needs its own installation, update and recovery evidence before it is supported. |
| Check a device | Run rjv2 preflight on it. It reads the operating system, architecture, memory, disk, listen address, configuration, database, database role and schema, changes nothing, and exits non-zero if release 2.0.0-alpha.1 cannot run there. |
| Installed as | One application and a PostgreSQL database. Installing release 2.0.0-alpha.1 (schema 100) installs every system on this site, including Governed Workflows. |
| Data | It stays in the PostgreSQL database you run. The only outside service the release can use is an outbound mail relay that you configure. |
| Updating | A release is a numbered build. The schema is applied by a separate owner step (rjv2 migrate), and the application refuses to serve a schema it was not built for. |
| Backup and restore | rjv2 backup writes a checksummed dump. rjv2 restore restores it into an empty database and checks the checksum, the schema version and the audit chain of every account. |
| Leaving | The data is in your own database and can be dumped at any time. What you may do with the release is set by the terms on deployment and ownership. |
- Published
- 29 October 2026
- Revision
- 1