← All capabilities

7 capabilities

Workflow & Governance

How work gets routed, approved and proven across every module

The problem

Approval is where governance is usually weakest. Sign-off happens in email, the approver who was on leave is worked around, the person who raised the item approves it themselves, and six months later nobody can reconstruct who agreed to what. The control exists on paper and nowhere else.

How it works

01

Workflow Engine

Multi-step workflows with conditional routing, sequential or parallel stages, and assignees resolved at runtime from the record itself

  • Multi-step workflows with conditional routing, so the path depends on the record rather than being one fixed chain
  • Stages run sequentially or in parallel depending on how the approval actually works
  • Assignees can resolve at runtime from the record itself, which means a workflow keeps working after a reorganisation
02

Approvals & Maker-Checker

Reusable approval templates per document type, with maker-checker refusing self-approval and every decision recorded against the instance

  • Approval templates are defined once per document type and reused, so the same class of item is approved the same way every time
  • Maker-checker refuses self-approval. The person who raised it cannot be the person who approves it
  • Every decision is recorded against the instance with its outcome and its author
03

Delegation & Extensions

Reassign a pending decision when an approver is on leave, or grant a deadline extension, both on the record rather than by email

  • A pending decision can be delegated when an approver is unavailable, on the record rather than by forwarding an email
  • Deadline extensions are requested and granted explicitly, so an overdue approval is a decision rather than a drift
  • Each approver has a pending queue, which is what stops an approval sitting unseen
04

Access Control & SoD

Multi-role permissions as a union, with segregation-of-duties conflicts flagged at assignment and overrides requiring a reason

  • A user holds a primary role plus any number of secondary roles, and effective permissions are the union of them
  • Over 1,100 permission gates across the API, with denials audited like any other event
  • Assigning a role that creates a segregation-of-duties conflict requires a recorded override reason, so the conflict is a decision someone owns
05

Audit Trail & Verification

Every action hash-chained and signed, verifiable by an outsider without an account

  • Every record carries an HMAC of its own contents plus the hash of the record before it
  • Editing a row breaks its HMAC. Deleting or reordering rows breaks the chain. Both are detectable after the fact
  • Records and reports are signed with published keys, and a public endpoint lets an outsider verify them without an account
  • A failed audit write lands in a dead-letter table rather than being lost, because an audit log with silent gaps is not an audit log
06

Documents & Retention

Folders, classification and retention schedules, with legal holds that genuinely block destruction

  • Documents carry folders, classification and a retention schedule per type
  • Retention runs dry by default, so a schedule is reviewed before it destroys anything
  • Legal holds genuinely block destruction for their subjects rather than flagging it, which is the only version that survives litigation
07

Data Migration

Guided importer with column mapping and presets that reports what it skipped instead of dropping it

  • A guided importer with column mapping, including detection, suggestions and reusable presets
  • Rows that do not map are reported loudly rather than dropped quietly, so a migration cannot silently lose history

What it produces when someone asks for proof

A decision trail per instance showing who decided, when, and on what

Maker-checker enforced by the system rather than by convention

Segregation-of-duties conflicts recorded with the reason they were overridden

An audit log whose integrity a third party can verify without trusting us

The rest of the platform

GRC

6

The risk register, the obligations that bind it, and the controls that answer them

Internal Audit

6

The full engagement lifecycle, from a risk-based plan to a closed finding

Resilience & Conduct

5

What happens when a risk materialises, and the conduct obligations around it

Intelligence & Monitoring

7

Continuous assurance over live operational data, not a point-in-time sample

Reporting & Analytics

3

What the work produces, for the people who have to act on it

Want this mapped against your terms of reference? We will go through it line by line, and tell you plainly where it does not yet reach.

Request a demo