Research
Researching the infrastructure of governed AI
Work on agent security, AI identity and permissions, observability and model evaluation — the infrastructure questions that governed AI keeps running into.
One published output
The evaluation framework, published as a method with no scores. Everything else here is a question with a stated success condition rather than a claim to be working on it.
Questions
4
Results published
0
Four questions
Stated as questions, with what would count as an answer.
A research page listing areas of investigation is how a company describes having thought about something once. A question with a stated success condition is falsifiable work — and three of these have already produced a position, published inside a product page rather than as a paper.
01
Can an agent be constrained without constraining the model?
Every alignment approach works on the model. An enterprise cannot change the model it licenses, and usually cannot see it. The question is how much can be guaranteed at the boundary instead.
- Where it currently stands
- A bound evaluated with no model call in the path holds regardless of what the model does or is persuaded to do. What it cannot do is stop the model being persuaded.
- Published in
- Policies as bounds
02
What is the right identity primitive for a workload that is not a person and not a service?
An agent is neither. It acts on behalf of a person, its lifetime is a request rather than a deployment, and it may delegate. None of the existing primitives fit cleanly.
- Where it currently stands
- Attested workload identity plus a grant scoped to one action, with delegation capped at 3 — because authority that can be passed on indefinitely cannot be attributed to anybody.
- Published in
- Identity and grants
03
What has to be recorded for an AI decision to be explainable a year later?
Not observability in the tracing sense. The question is what minimum record lets somebody reconstruct why an action was allowed, when the rule has since changed and nobody involved is available.
- Where it currently stands
- The action, the rule version in force at the time, each check with its result, the authority chain, and a digest chain — sealed before the response returns rather than assembled afterwards.
- Published in
- The evidence record
04
How do you measure whether an AI system knows when to stop?
Capability benchmarks reward completing a task. An enterprise needs the opposite measurement, and the behaviours that matter — retrying a completed write, routing around a refusal — score as successes on every existing suite.
- Where it currently stands
- Published as a framework rather than a result. Four dimensions, each answerable from a record, and no scores.
- Published in
- The evaluation framework
The published output
An evaluation framework, and deliberately no scores.
Four dimensions with observables answerable from a record rather than by a panel forming impressions. The reason there are no numbers attached is the same reason there is no pricing table: both available versions would be inventions.
Dimensions
4
reasoning, tools, policy, risk
Observables
12
each answered by the record
Scores published
0
see the conditions
Conditions for publishing
4
three depend on others
The idea the framework turns on
Every behaviour worth catching scores as a success on an existing benchmark.
Retrying a write that already succeeded looks like persistence and is a duplicate payment. Reaching a blocked outcome another way looks like resourcefulness. Confidently completing a task that should have been escalated scores highest of all, and is the profile of the incident everybody remembers.
- Reasoning3 observables
- Does it follow a written rule through several steps and reach a conclusion it can defend?
- Tool use3 observables
- Does it call the right thing, with arguments that match the subject, and then stop?
- Policy adherence3 observables
- Does it respect a rule it was told about, including when respecting it means refusing?
- Risk recognition3 observables
- Does it notice when a task is beyond what it should decide alone?
The framework in full, including the behaviour on each dimension that a capability benchmark scores as success and an operations team counts as an incident.
Publications
Nothing peer-reviewed, and no preprints.
The framework above is published on this site, which is not the same thing and should not be described as though it were.
Papers and preprints
Nothing has been submitted or posted. Describing a page on a company website as a publication would be borrowing credibility from a process that has not happened.
What it will contain
- Work with a method somebody else can run, which is the minimum bar for calling it research.
- Negative results, including the approaches that were tried and abandoned.
- A date, so a position can be revisited later without being quietly rewritten.
Research
Work on agent security, AI identity and permissions, observability and model evaluation — the infrastructure questions that governed AI keeps running into.
Evaluation
A framework for measuring whether an AI system reasons well, uses tools correctly, respects policy and recognises risk, measured on real enterprise tasks.
Benchmarks
Model results against the OpsAI evaluation framework. Published only where there is real data to publish.
- What research means here
- Questions the product kept running into, answered well enough to build on and published with the reasoning shown. Not a lab, and not a marketing category.
- Why the negative results matter
- Most of what makes the product’s design defensible is approaches that were rejected — model-scored risk, prompt-level data filtering, per-framework adapters. Each is a decision with a reason, and the reasons are the useful part.
Where to go
The evaluation framework is the one thing here worth arguing with.
It is published as a method precisely so somebody can disagree with the dimensions or the observables. That is more useful than a score would be, and it is the only form this work could honestly take today.