Governance
What our software refuses to do
A system that never says no is a system nobody should trust with a ward rota, a patient record, or a payment run. Every refusal below is enforced in code, shown with its reason, and cannot be overridden by asking nicely.
Uncertainty
It never guesses
- It will not act on a low-confidence readAnything below the configured threshold is held for a person rather than entered. A silent wrong entry costs more than a held one.
- It will not improvise around a screen that has changedIf a system's structure moves, the run halts and reports. No blind retries, no clicking something that looks similar.
- It will not treat a success message as proofAfter every submission it re-reads the record to confirm the change persisted. A confirmation banner is a user interface event, not evidence.
- It will not report silence as successAn instrument that has stopped reporting is treated as a fault, not an all-clear. This is the failure mode that hides every other failure mode.
Boundaries
It never crosses a boundary
- It will not take clinical action without human oversightPermanently out of scope. Not a roadmap item.
- It will not make or assist a clinical decisionWe build software that carries out decisions already made by clinicians and encoded in rules. It does not form new ones.
- It will not substitute a grade or a skillWhere a role, band or competency is specified, no substitution is made in either direction.
- It will not act past a compliance dateExpired clearance, registration, training or right to work blocks the action outright — checked against the date the work happens, not today's date.
- It will not exceed an agreed limitA rate above the client cap, or a working-time breach, stops and waits for authorisation. It never quietly agrees.
- It will not move one client's work onto another client's systemEnforced at every permission level, including our own administrators.
Money
It never acts alone where money moves
- It prepares payment runs. It does not release them.The system assembles one hundred per cent of a batch and releases none of it. A named person clicks release.
- The person who prepared it can never be the person who approves itEnforced by the system, logged, and offered with no override. This is a design choice, not an unfinished feature.
- It will not advance an unfunded batchMoney in is matched to money out before anything moves. Short-funded and unfunded batches are separated and held.
Every refusal is shown with its reason, so a person can resolve it — instead of working around a system that went quiet.The principle behind all of the above
And what we will not sell you
Out of scope, permanently
Never in scope
Autonomous clinical action
Software that acts on a patient without a person in the loop.
Never in scope
AI-assisted clinical decisions
We do not build diagnostic or triage judgement into automation.
Not in scope
Automated coding submission
Submission to national tariff coding is outside what we take on.
Roadmap
Some specialty classification
Certain specialty-specific document classification is in development. If your requirement lands here we will tell you in the first meeting.
On automating someone else's system. Where a supplier publishes an interface, we use it. Where none exists, we work through the same screens your team uses — and that is a contractual question before it is a technical one. We get written agreement from you, and check the platform supplier's terms, before a single automated sign-in. That is step one of any engagement, not an afterthought.
And the other half
Refusing is only useful if somebody can verify it refused
Every refusal on this page is logged, and a second system independently confirms the first one behaved as it should. A machine that says it stopped is not the same as a machine that stopped.
This page exists because the rest of the site makes claims
Anyone can list capabilities. The useful question is what a system does when it is not sure — and whether the supplier will tell you before you find out.