Nothing worries me more than watching a business hand a decision to an AI that can’t tell you why it made it.
“Ask it again and see what it says.”
Try it. Give a chatbot a customer’s details and ask whether they qualify for something. Then ask again, worded slightly differently. You’ll often get a different answer, delivered with exactly the same confidence. That’s fine for a holiday itinerary. It’s a disaster for mortgage underwriting, insurance claims, a tax decision or a sanctions check.
Rainbird exists to fix that. So here it is in plain English: what it is, how it works, and where it fits alongside the AI you already use.
Why most AI can’t be trusted with a decision
A large language model is a prediction machine. It has read most of the internet and it is astonishingly good at guessing which words should come next. That’s why it writes so well and reads so well.
But guessing the next word isn’t reasoning. Ask it to decide something and it isn’t applying your policy. It’s producing something that looks like your policy being applied, based on what similar text tended to look like. Sometimes that lands. Sometimes it doesn’t. And you can’t tell which from the outside, because both come out sounding equally sure.
In a regulated business, “usually right” isn’t good enough, it’s most likely a breach. The regulator doesn’t ask whether your model is clever. It asks whether you can show, for this customer, on this day, exactly why you decided what you decided.
So the question isn’t how to make the language model smarter. It’s how to stop it doing the one job it’s bad at.
More context isn’t the answer
The usual fix is to give the model more to read. Upload the policy PDF. Connect it to the document store. Bolt on a search tool so it can look things up. Give it memory so it remembers what you told it last week. Context windows keep getting bigger, so the instinct is to fill them.
It doesn’t solve the problem. A context window is working memory. It’s the pile of paper on the desk. Putting your rulebook on the desk means the model can see it. It doesn’t mean the model follows it. It reads the rule and then does what it always does, which is produce the most plausible next sentence. It can quote your policy word for word and misapply it in the same breath. And the bigger the pile, the more it loses track of what’s in it.
Memory is the same trick with a longer shelf life. Remembering what you said on Tuesday does nothing for whether Wednesday’s decision is right.
Some teams have gone a step further and pasted a knowledge graph into the prompt. Better structure, same problem. The graph has become something the model reads about, not something the machine executes. Nothing enforces it. You’ve handed a map to someone who was always going to guess the route.
Knowledge has to be a first-class citizen. Not a document the model happens to have seen, and reinterprets time after time, but the thing that actually runs: held outside the model, in a form a machine can execute, test, version and audit. A rule described in your policy isn’t a hint. It’s the program.
Two jobs
Here’s the split that makes everything else make sense.
Most tasks people hand to AI contain two different jobs. The first is understanding language: reading the document, pulling out the facts, talking to the customer, summarising the file. Language models are brilliant at this and getting better. These jobs happen at the boundary.
The second is applying rules to those facts to reach a decision, the same way every time, with the working shown. That’s reasoning, and it’s a job you want done by something that doesn’t guess. These decisions are at the core.
Rainbird does the second job. We call it the decisioning layer. The language model handles the words, Rainbird handles the decision, and each does the thing it’s best at.
The decisioning layer comes down to three pieces at its core, and two more around the edges.
Part 1: the core
Start with the rulebook.
Every organisation already has one. It’s the policy documents, the regulations, the credit manual, the underwriting guide, and the twenty years of judgement in the head of the person everyone goes to when a case gets complicated.
In Rainbird that knowledge becomes a map. Not a wall of text, a map: the things that matter (a customer, an income, a jurisdiction, a risk), how they relate to each other, and the rules that connect them. It’s a particular type of knowledge graph, but one where rules are encoded (Which is not typical for a knowledge graph). Think of it as your best expert’s way of thinking, mapped out so a machine can follow it. Not a linear process, but a whole knowledge domain.
The part that matters is that it’s built by people who know the domain, not learned from a pile of data, and it lives outside the model, where the reasoning engine, logical to its core, runs it rather than reads it. If the rule changes on Monday, you change the rule in the map. You don’t retrain anything, and you don’t hope the model noticed amongst all of its other weights.
Next, the reasoning engine.
This is the bit that walks the map.
You give it a question, “does this customer qualify?”, and whatever facts you already have. It works backwards from the question, not forwards from the facts. What would it need to know to answer that? Which rules could settle it, and which facts do those rules need? It goes and finds those facts, in what you’ve given it or in the systems it’s connected to. If one is missing, it doesn’t invent it. It stops and asks, either a person or a system, for that piece and nothing else. Then it carries on until the question is answered.
Same facts, same rules, same answer. On Tuesday, on Wednesday, and in front of the regulator in eighteen months’ time. That’s what deterministic means, and it’s the basis of trust.
It also copes with the grey areas. Real rules aren’t all black and white, so the engine can weigh evidence and tell you how confident it is, and why. What it never does is make things up.
Then the working.
Every decision Rainbird makes comes with the reasoning behind it: which facts it used, which rules fired, in what order, and what would have changed the outcome.
If you were ever told in a maths exam that you don’t get the marks without showing your working, that’s the idea. A regulator is a maths teacher with a budget for enforcement. A confident answer with no trail is not enough. A decision with its rationale attached is something they can read, and sign off.
That’s the core: a rulebook written by your experts, an engine that follows it exactly, and a full account of how it got there.
Everything above is what we’ve built at Rainbird, and it’s what banks, financial services and insurers, plus others, use to make regulated decisions today. Built with their experts, tested against their real cases, and every decision explained.
You can try it yourself. There’s a free Community Edition, and a growing library of ready-made accelerators you can download. If you’d rather talk it through, get in touch.
Right, two more pieces.
Part 2: around the edges
Building it fast.
The fair objection to all this used to be time. Writing your expertise down as a map was a craft, and a slow one: weeks of a knowledge engineer sitting with your experts.
That’s what changed. We built RAKE, which uses language models to do the first draft. Point it at your policy documents and it builds the graph in hours rather than weeks. Someone who knows the policy reviews it, tests it against real cases, and puts it live. The language model does what it’s good at, reading and drafting. The map it produces then runs deterministically, so no guessing.
We’ve also published accelerators: pre-built graphs for common regulated decisions, such as adjudicating a transaction monitoring alert or checking a stablecoin issuer against the US GENIUS Act. They’re free, open source, and a starting point you can pivot to your own policy.
Plugging it in.
The last piece is where it sits: your workflow or applications, or increasingly the answer is behind your AI agents.
Everyone is building agents now. The agent reads the email, pulls the customer file, drafts the reply. Somewhere in the middle of that flow it has to decide something that matters. That’s the moment it should stop guessing and delegate to Rainbird.
Rainbird makes that simple. You can hold all your rulebooks in one place and route each question to the right one, so an agent, yours or one built on any of the big platforms, can ask “can I do this for this customer?” and get back a yes, a no, or “I need to know one more thing first”, with the reasoning attached. The agent does the legwork. Rainbird makes the decisions that are policy-precise, deterministic and auditable.
Put it together
A language model at the edges, doing language. A map of your expertise in the middle, held outside the model rather than stuffed into it. An engine that follows the map exactly. A record of every step.
A fast way to build it and a simple way for your agents to call it.
Leave out the reasoning layer and you get an AI that’s confident, fluent and occasionally, invisibly, wrong. That’s the version that keeps risk and compliance teams awake at night, and stops your project going live. Put Rainbird in and you have automation a regulator can read, your experts can correct, and your customers can trust.
That’s Rainbird. The plain English version.
