xGRC · anatomy of a control execution
Most people hear "executable" and picture a notification announcing work to be done. The real mechanism is simpler and more radical: the control loads itself, reads your data, reaches a verdict and starts what comes next.
The screens below are illustrative, non-contractual representations, pared back to isolate the mechanism. Real screens carry a density of structured data we do not publish — you will see them in a demonstration.
01
You configure the control once: which process, which task, which data, what cadence, which checklist and which remediation plan. The scheduler then creates every occurrence to come.
There is no campaign to launch, no reminder to send, no tracking sheet to maintain. The administrative weight of control disappears here, not further down the line.
PROCESS · TASK
Claims settlement → Approval
LINKED RISK
RSK-0391
CADENCE
Daily
MODE
Robot — direct
COVERAGE
Full population
OCCURRENCES CREATED BY THE SCHEDULER
PRODUCTION DATA SOURCE
GENERATED SCRIPT
SELECT c.reference, a.approver, a.amount, l.delegation_limit FROM CLM_CASE c JOIN CLM_APPROVAL a ON a.case_id = c.id JOIN REF_LIMIT l ON l.profile = a.approver_profile WHERE c.approval_date = :occurrence_date
02
At the due date, the day's occurrence goes and fetches the production data itself — full population or sample, as configured.
Nothing is replicated, nothing is re-keyed. The time spent reaching the data under control — a real share of control time in a declarative setup — falls to zero.
Where a document has to be prepared by an operator, the request goes out with its deadline and the occurrence waits.
03
The robot path short-circuits more than 90 % of volume: no human analysis, running as permanent control over short periods. The controller path handles the rest, with an overall status or a status weighted by a checklist of minor and major points.
Working a manual control — and even simply viewing its contents — is restricted to members of the execution group it belongs to. A control is not a document you open in passing.
The robot reaches a verdict on every row and triggers remediation on failure. No involvement at all.
2,418 rows processed · 11 failures · 4 s
The controller re-keys nothing: they set the status, or the checklist that weights it. Self-control is not permitted.
Weighted status: 68 % — major failure recorded
Cadence describes the control, not the remediation. Human control is monthly at best, often quarterly; the robot runs continuously. Remediation handling is independent of both and happens continuously.
04
A failure starts the remediation plan and ties it, compulsorily, to a risk. That link is what reveals, over time, which risks were misidentified or misrated.
The plan is not an alert: it carries the actions that fit the failure found. The operator accepts, qualifies the case, adds a voluntary action, or rejects it as a false positive — and can hold the case pending supporting evidence when the document is not yet available.
Pre-emptive remediation names the step that was skipped: the operator learns by doing, and the system improves with no dedicated programme.
This case was approved by a profile whose delegated limit is below the amount committed. Expected step: hierarchical counter-approval before settlement.
OPERATOR RESPONSE
05
There is no single landing screen where everyone hunts for their task. Each role enters through its own worklist and lands directly on the step that concerns them. Nothing is serialised, nothing routes through a central point.
OPERATOR
Documents to supply, with their deadlines. Five, eight or fifteen days for period-end data.
CONTROLLER
Occurrences awaiting a verdict, data already loaded. Only manual controls appear here.
OPERATOR
Cases to handle, colour-coded: robot in the background, manual, awaiting a document.
We configure it and run it in front of you. It is the shortest way to check whether any of the above holds up.