AI proposes.
Your architecture
decides.
AI systems are no longer just making recommendations; they are taking actions inside regulated workflows. Most governance frameworks were built for reports and scores, not for agents booking trades, releasing payments, or moving clinical records. The risk is simple: rules that must always hold are currently enforced by systems that can still be wrong some of the time.
AI that cannot go rogue isn't a product feature, it's an architectural guarantee. We build the formal specification and cryptographic enforcement layers that make enterprise AI deployable in regulated systems. Not safer prompts. Not more monitoring. Formal proof.
We build the specification and cryptographic enforcement layers—and we deliver alongside your organisation: adoption programmes for specification-driven development (SDD), and joint builds on the systems your regulators will ask about. Products prove the architecture; engagements put it in production.
∀ α ∈ AgentActions :
Γ(St, α) → { accept | reject }
// Agent proposes. Validator decides. Always.
// No AI reasoning overrides this. Ever.
When AI takes the action, your evidence has to keep up.
AI in your organisation is no longer only drafting emails or summarising documents. Agentic AI—software that can book trades, release payments, onboard suppliers, or update client records—is taking actions inside workflows you are accountable for.
Most governance frameworks were built for outputs: model cards, bias reviews, human sign-off on a recommendation. They were not built for actions where a wrong step can be a regulatory breach, a client harm, or a board-level liability question the next morning.
When a supervisor or internal audit asks "Why was this payment allowed?" or "Who approved this onboarding?", you need more than chat logs and post-hoc narratives. You need a tamper-evident record that shows which rule applied, what the system knew at the time, and whether that rule actually held—before the action ran.
That is an architecture question, not a better-prompt question. Riley Betts builds the specification and enforcement layers that produce examination-ready evidence—proof-shaped artefacts a General Counsel or compliance lead can take into a review without asking engineering to reconstruct the story.
We separate reasoning (what the AI proposes) from authority (what your institution allows)—and we leave cryptographic evidence behind every allowed action.
We also work with your teams through SDD adoption programmes and engineering engagements so traceable rules and evidence are built into how you deliver—not bolted on after an incident.
The AI governance debate is asking the wrong question.
Everyone is asking how do we make AI safer? Better prompts, more guardrails, human-in-the-loop checkpoints. These are answers to a question that shouldn't need asking.
The right question is: should AI be the enforcement layer at all?
In any regulated system, financial services, healthcare, payments, procurement, there are rules that must hold. Not usually. Not 99.9% of the time. Always. A probabilistic system cannot provide a deterministic guarantee. That is not a limitation to engineer around. It is a mathematical fact.
The correct architecture separates reasoning from authority. The AI reasons freely. The validator decides, deterministically, every time. And the specification that defines what the validator enforces is itself formally proven, not tested, not reviewed, not hoped about. Proven.
Turn AI risk into an architectural property—and a build you can ship.
Start with a software engineering engagement (Spec++ SDD) on your highest-risk workflow, or roll out SDD adoption so the whole organisation specifies before AI generates. We work with your architects and leads: agents propose, a formally specified validator decides, and every consequential transition can carry evidence you can show a regulator or the board.
Know exactly why every action was allowed.
Your liability question is simple: when an AI-assisted workflow releases a payment, onboards a supplier, or moves client data—can you prove the right rule was applied at the right time? Not after a week of log archaeology. At the moment of decision.
We help compliance and risk teams get there in two ways: SDD adoption programmes that trace policy language into checkable specifications your engineering partners can enforce, and build engagements that deliver examination-ready evidence packs on live workflows. Underneath both sits the same architecture—the Compliance Operator (CECO)—where agents propose and a validator (not the AI) decides, with a hash-chained audit log you can verify independently.
Ship faster by specifying better—with a team that builds alongside you.
Most teams can generate code faster than they can explain intent. SDD adoption programmes upskill your product, engineering, and QA people to keep living, checkable specifications at the centre of agent-assisted delivery—provenance, review habits, CI gates. When you need us in the critical path, software engineering with Spec++ SDD pairs our engineers with yours on regulated or high-stakes systems.
You own the specification—not just the code.
Pair with us on a Spec++ SDD build, or follow the SDD adoption path into specification stewardship—the role that captures rules precisely enough that generated implementation has almost nowhere to go wrong. AI becomes a compiler for behaviour you define, not a black box that replaces you.
Human-in-the-loop is mostly theatre
A compliance officer approving a rebalancing proposal they didn't generate, against mandate data they can barely process in the time given, is not governance. It's a ceremony that makes boards feel better while exposing sensitive client data unnecessarily. If an action cannot be validated at runtime, the automation was wrong. Put the validation in the architecture.
AI is a catalyst for better engineering, not a replacement for it
The firms winning with AI aren't the ones prompting harder. They're the ones whose architecture is precise enough that AI generates reliably excellent output. Vague intent produces vague code. Formally specified intent, entities, invariants, proofs, produces deterministically correct code. AI amplifies the quality of your specification, not the quality of your guesswork.
Most AI governance frameworks are designed for a world that no longer exists
They assume AI outputs, not AI actions. Agentic AI doesn't generate a recommendation for a human to act on, it books the flight, executes the trade, authorises the payment. The governance layer must sit upstream of execution, not downstream of it. A log is not a control. An audit trail reconstructed post-hoc is not evidence. The guarantee must be architectural.
Go deeper on how we work.
The homepage is the thesis. Each page below is a full treatment of one part of the stack—capabilities, evidence, proof, products, research, and why we disagree with the mainstream.
Work with us
SDD adoption programmes and Spec++ SDD engineering engagements—how most organisations start.
Regulatory evidence
Examination-ready records: decision, rule, state, approval, cryptographic proof.
Proof of work
Instrument Repository, agentic compliance, procurement onboarding—with real numbers.
What we build
Spec++, Spec++ Pipeline, and Compliance Operator (CECO)—plus formal-methods context.
Research
Proof-gated architecture, Spec++ language work, neuro-symbolic agents—labelled honestly.
Why it matters
Failure modes, consensus vs. our view, and what this means for engineers.
We have done this before.
Twenty-five years building software for financial institutions, derivatives pricing platforms, trading systems, risk infrastructure. Pioneer of Python in financial services, when Python was still considered an unconventional choice for production systems.
Deep practitioner of agentic orchestration, AI planning loops, and the architectural patterns that make autonomous systems safe rather than merely useful. The specification-first philosophy came from years of watching systems fail not because of bad code, but because of bad specifications.
A successful technology entrepreneur, architect of the Compliance Operator's formal security model and ZK proof infrastructure. Brings a background in systems architecture and a rigorous approach to the hardest problem in enterprise AI: not making AI smarter, but making AI that cannot be wrong in ways that matter.
Author of the policy constrained authorisation model and the Spec++ specification methodology. His insistence on provability over plausibility is the reason Riley Betts products come with theorems, not promises.
Joint Mathematics and Computer Science degree from the University of St Andrews. Academic background in predicate logic, Bayesian inference, statistics, and contemporary AI techniques—precisely the disciplines at the intersection of formal specification design and probabilistic-to-deterministic reasoning.
Where most engineers encounter formal methods reluctantly and late, Jamie started there. That grounding underpins the mathematical rigour of both Spec++ and the Compliance Operator: the ability to reason precisely at the boundary between probabilistic AI behaviour and deterministic enforcement guarantees.
Riley Betts engages as a joint team with your domain and compliance experts. We retain the engineering and cryptographic specialists; you provide the business context and regulatory knowledge. Engagements begin with a fixed-scope pilot designed to prove the architecture on your specific use case before any broader commitment.