Capability 01
Plenty of organizations have an AI policy. Far fewer can demonstrate, on a specific decision made last Tuesday, what their systems did and on what basis. RPR builds the layer that makes the second thing true: oversight, lineage, guardrails and a traceable record, engineered into the systems themselves.
The problem
An automated system acts thousands of times a day. Unless something was deliberately built to capture it, each of those actions leaves behind only its effect — the order that moved, the record that changed, the message that went out. The reasoning is gone.
That is tolerable right up until somebody asks a specific question. Then the absence of a record stops being a technical detail and becomes the whole problem, because the honest answer is that nobody knows.
In our experience the question arrives commercially well before it arrives legally — in security reviews, insurance questionnaires, enterprise procurement, and the board meeting after something goes wrong.
Questions your systems should be able to answer
If the answer to the last one is no, the rest are opinions.
The approach
Put oversight, policy and the record in the control path rather than in the model, and two useful things follow: the controls apply no matter which provider is answering, and swapping provider costs you a configuration change instead of your entire audit history.
What we implement
These are the things we actually build. None of them is a certification, a badge or a claim about your regulatory position — they are engineering controls that make your obligations, whatever they turn out to be, answerable.
Autonomy is a dial, not a switch. Every automated actor has a threshold above which it stops and waits for a named person — and the approval, the approver and the moment it happened become part of the record rather than a message in someone’s inbox.
For any automated outcome you should be able to walk backwards: which action was taken, under which policy, on which inputs, drawn from which systems, in what state, at what time. Lineage is what turns "the model said so" into an account somebody can check.
What a system may do is declared once and enforced where the action happens — not left to a carefully worded prompt. Guardrails bound the blast radius: which systems, which records, which operations, and what must never be touched under any circumstances.
Records are written append-only and kept queryable, so producing evidence is a query rather than a project. The test we hold ourselves to is simple: can you answer a pointed question about a specific decision, from the record, in minutes, without calling an engineer.
The difference between an assistant and an agent is that an agent changes something. Every write an automated actor can make is enumerated in advance, scoped, reversible where reversibility is possible, and logged whether it succeeds or fails.
Governance that lives inside a vendor’s platform leaves with that vendor. Ours sits around the model: policy, oversight and the record are ours and yours, so changing provider — or running several at once — is a configuration decision rather than a governance rebuild.
Lineage in practice
Every automated action follows the same path, and every step of that path is written down. This is what makes an answer possible months later, when the person who built it is on holiday and the customer wants an explanation today.
Our governance technology
Still Horizon is RPR’s own governance technology — the intellectual property behind how we capture and seal decision records. It is what lets us offer the same traceability guarantees across very different customer environments instead of rebuilding the mechanism each time.
Customers do not buy Still Horizon as a separate thing, and they do not need to understand how it works. They get its outcome: a record that is complete, ordered and hard to quietly revise. Implementation details are covered under a separate program and are shared under NDA where an engagement genuinely calls for it.
Available as part of an RPR engagement. Technical briefings by request.
Where to start
Before anything is built, we establish what your automated systems can currently account for. That assessment is useful on its own — several customers have used it to answer a procurement questionnaire they were already stuck on.
Which automated systems are running, what they can do, and what they currently record.
The specific questions your systems cannot answer today, written down plainly.
Controls implemented against the highest-exposure systems first, not everything at once.
Governance holds as the estate changes, because it is part of the integration rather than a layer on top.
Bring us a specific automated decision your business made this week. We will walk through what you could establish about it today, and what you could not. That conversation costs nothing and is usually clarifying.