Responsible AI, written as build rules.
A policy page is a promise. These are constraints in the software, and one of them you can test on this page, right now.
Six rules, and none of them are aspirations
Each one is a thing the software does or refuses to do, which means each one can be checked.
It proposes. You approve.
Nothing our software does reaches a real system on its own. It works out what should happen, puts it in front of a person with the evidence behind it, and waits. Automation without a review gate is a faster way to be wrong, and being wrong quickly at scale is the specific risk worth designing against.
It shows its working
Every proposal arrives with what it was based on. If you cannot see why something was concluded, you cannot defend it to an auditor, and you cannot tell a good answer from a confident one. Reasoning you can read is the difference.
It never trains on your data
Your records are used to run the product for you, and for nothing else. Not to improve a model, not to benefit another customer, not aggregated into something we keep after you leave.
It stays inside the job it was given
A tool that reconciles invoices reads invoices. It does not get a general-purpose key to your systems in case it turns out to be useful later. Narrow access is not a limitation we work around; it is most of what makes the thing safe to run.
It says when it does not know
Software that always produces an answer teaches people to distrust every answer it gives. Ours is built to stop and hand over instead, because an honest gap is useful and a confident guess is worse than silence.
A person is accountable, not a model
Every approval is recorded against the person who gave it. When a regulator, a client or a colleague asks who decided something, the answer is a name and a timestamp, never “the system did it”.
Where the guardrails actually live
A limit that is asked for is a request. A limit that is enforced is a guardrail.
Most published AI principles describe how a model has been instructed to behave. That is worth something, but instructions are not constraints: the same sentence that asks a model to stay in its lane is the sentence someone can talk it out of. So the rules above are held in the parts of the system that cannot be argued with.
- 01 Approval is a step in the workflow, not a prompt
- 02 A signed-in user’s access is enforced in the database, not only in the app
- 03 Your data is not sent anywhere it could be trained on
- 04 The record is written, not offered
Which closes off the failure modes people reasonably worry about. Who may read or change what is decided by the database, not by the screen in front of you, so a mistake in the interface cannot widen anyone’s access. It produces a proposal rather than a change, so the acting is done by a person. And the record is written in the same step as the change, rather than by a separate process that can be skipped or fail quietly.
The honest limit of this: guardrails constrain what the software is able to do, not whether its reasoning is right. A proposal can be wrong and still be correctly scoped, correctly logged and correctly held for approval, which is precisely why a person approves it, and why we would rather show you the working than ask you to trust the output.
Test one of these yourself, on this page
The assistant in the corner of this site is built to the rules above, and it is the easiest one to check. Ask it something the site covers and it quotes the passage and links to the page it came from. Ask it something the site does not cover and it says so, rather than guess.
Try what is your refund policy.
It works that way because it retrieves rather than generates. There is no model writing prose about us, so there is nothing that can invent a product we do not sell or a price we have not set. It is less fluent than a chatbot that makes things up. That is the trade, and we would make it again.
It also reports honestly on us. Two questions it currently cannot answer told us the site was missing answers we should have written. That is the rule working in the direction people usually forget: a system that admits its gaps is a system that tells you where you are weak.
What we will not build
These are fixed positions, not preferences.
- Anything that acts on a live system without a person in the loop. Not a faster tier, not an opt-in, not “just for the low-risk ones”. The gate is the product.
- Anything that scores, ranks or filters people (candidates, employees, customers) where a person’s outcome depends on a model’s judgement.
- Anything whose reasoning cannot be shown. If we cannot put the working in front of you, we do not ship it.
- Anything trained on one customer’s data for another’s benefit.
If what you need is one of these, we will say no and tell you why rather than take the work. That is worth knowing before you start a conversation, not after.
How we know it holds
Rules that nobody checks are decoration. Every change goes through an independent QA pass and a validator that audits the QA rather than trusting it, and anything touching authentication, data flow or permissions takes the full three-way path rather than the light one. The step-by-step detail is set out in full on our build page.
What we cannot promise
We are not going to tell you our software is incapable of being wrong. It can be. The control is not that the model is perfect; it is that nothing it produces reaches a real system without a person seeing the reasoning first, and that the trail of who approved what survives afterwards.
We do not hold a third-party AI assurance certification, and we are not going to imply one. What the EU AI Act or your own regulator requires of you depends on your sector and your use, and we will not pretend to settle that on a web page. Tell us what you are held to and you will get a specific answer about what we can evidence and what we cannot.
If something goes wrong
Tell us. A defect that reaches a customer is ours to fix, not yours to work around, and we would rather hear about it from you than not hear about it at all. Anything sensitive has its own reporting route.
Have a question none of this answers?
Especially the awkward ones. If your compliance team has a list, send the list. You will get a straight answer for each, with the evidence we hold behind it.
-
A named human approver
Every change to a real system carries who approved it and when.
-
The working, in writing
What it concluded, and what it concluded it from, kept together.
-
Your data stays yours
Used to run the product for you. Never to train anything.