Skip to content
Rivenpath Labs
Research

Mapping the structureof accountable AI

Rivenpath's research programme is narrow on purpose. We work on the parts of AI safety that can be measured, enforced, and shown to someone else — and we publish what we find as we find it.

Research areas
5

Research areas

Active thread
1

Active thread

Publishing cadence
Weekly

Publishing cadence

Drag to rotate · hover a cluster

The thesis

What we believe, and why we work here

Every research programme is a bet about where the important problems are. Ours is written down so it can be argued with.

  1. 01

    Governance is an engineering problem

    The gap between a written AI policy and an enforced one is where nearly all governance failures live. Policy that cannot execute is documentation. The interesting work is compiling human intent into runtime checks that hold under load — which is engineering, not paperwork, and it has been badly under-invested in relative to capability research.

  2. 02

    Evaluation must be continuous or it is theatre

    A model evaluated once before launch tells you about a distribution that no longer exists. Real-world failure modes emerge from live traffic, from prompt drift, from users who use the system in ways nobody designed for. Measurement that stops at deployment is not measurement; it is a certificate.

  3. 03

    Interpretability is an interface problem too

    Most interpretability research asks what is happening inside the model. An equally important question is what the person supervising it can actually see. A perfectly interpretable system whose explanations nobody reads has not produced oversight. We work on both halves, and we think the second is neglected.

  4. 04

    You cannot explain a pipeline you do not own

    Explainability claims made about someone else's weights are claims about a black box you rented. That is why we pre-train our own model from scratch and fine-tune it toward the governance domain — not to compete on capability, but so that every step from data to output is ours to inspect and account for.

  5. 05

    Literacy is a safety control

    Governance that protects institutions from liability while leaving users no better informed has solved the easier half. People who understand a model's limits use it more effectively and challenge it more usefully than people handed a more capable model and no context. We treat education as part of the safety surface, not marketing around it.

Research areas

Where the work is concentrated

R-01

Continuous Evaluation

Measuring bias, jailbreak resistance, grounding, and drift against live traffic rather than a frozen benchmark. Methodology and its limits published openly.

R-02

Policy Compilation

Translating written responsible-AI policy into executable guardrails, and studying where that translation loses fidelity.

R-03

Oversight Interfaces

What a human supervising an AI system needs to see, when, and in what form, for the oversight to be real rather than nominal.

R-04

Domain Model Training

Pre-training from scratch and fine-tuning toward AI governance, so the studio owns its pipeline end to end in a field where explainability is the product.

R-05

AI Literacy

How people build accurate mental models of what these systems do, and how interfaces help or hinder that.

Extracts

What we are publishing

Short, citable notes on the problems we are working through. Published as we go rather than held until a paper is ready.

R-01Continuous Evaluation

Deploy-time evaluation misses the majority of real failures

Guardrails evaluated only at deploy time miss the majority of real-world failures. Risk has to be measured continuously, against live traffic, or it is not being measured at all. The practical consequence is that an evaluation budget spent entirely pre-launch buys less safety than the same budget spread across the deployment's life.

R-02Policy Compilation

Policy that cannot execute is documentation, not control

The gap between a written AI policy and an enforced one is where nearly all governance failures live. Most organisations have the policy. Very few have anything that stops a request violating it. The failure is almost never a missing rule — it is a rule with no runtime.

R-03Oversight Interfaces

Explanations are an interface problem before they are a modelling one

Systems that explain their reasoning to the person using them produce better outcomes than systems that are merely accurate. Interpretability that never reaches a human decision-maker has not produced oversight — it has produced a log file.

R-05AI Literacy

Capability without literacy under-delivers

Teams that understand a model's limits use it more effectively than teams given a more capable model and no context. This has an uncomfortable implication for procurement: the marginal safety return on training your people can exceed the marginal return on upgrading your model.

R-01Continuous Evaluation

Audit trails written after the fact are reconstructions

Only records written at the moment of the decision carry evidentiary weight. An audit trail assembled after an incident is a narrative about what probably happened, and it will be treated as one by anyone assessing it seriously.

R-04Domain Model Training

Notes on training a governance-domain model from scratch

Working notes on why the studio pre-trains rather than fine-tuning a frontier model: in a field where the product is explainability, renting weights you cannot inspect undermines the claim you are selling. Capability is not the objective; provenance is.

Read it as it is written.

Extracts are published here as the work progresses, alongside the reasoning that did not fit on the page.