What we build

Formal. Enforced. Proven.

Riley Betts builds formal specification and cryptographic enforcement for regulated AI — one architectural spine: describe rules precisely, verify before you ship, and enforce at runtime when AI acts in regulated workflows. Most organisations start with capabilities; these are how the discipline scales.

Platform

CECO - Compliance Operator

Agents propose. Your validator decides—with cryptographic evidence.

Cryptographically Enforced Compliance Operator (CECO)—deterministic agentic governance for regulated AI. AI agents are untrusted; CECO evaluates against your formal policy before execution.

// Security model (illustrative theorem names)
T1 Anti-Replay: each proof-gated action authorised ≤ once
T2 Policy Soundness: acceptance ⟹ policy predicate holds
T3 Selective Disclosure: disclosed data provably consistent
T4 ZK Confidentiality: private data never revealed to agent

Every proposed action is accepted or rejected by the validator—not the AI. A ZK proof can show a rule was satisfied without exposing underlying client data.

  • Deterministic: same state + same action → same allow/deny, always
  • Hash-chained audit log: tamper-evident records at decision time
  • Prompt injection cannot cause non-compliant transitions by architecture
  • Sits above legacy systems—no rip-and-replace
Discuss CECO - Compliance Operator →
Engagement

Agentic governance workshop

Choose where humans decide. Prove that agents can’t overstep.

A short, structured engagement with your architecture, risk, and compliance leads to map where agentic AI is proposing actions today, which of those actions need a rule and a check, and where the gaps are.

  • Shared map of agent actions and the rules that should govern them
  • Clarity on what must never be automated — and how you evidence it
  • A scoped starting point for Compliance Operator or Spec++ work
Book a workshop → Full workshop detail →
Methodology & tooling

Spec++

Write what must be true—not how to compute it.

Spec++ is a mathematics-first specification methodology for AI-first software engineering. You define invariants and allowed state transitions; tools prove properties and generate implementation from that intent.

// Instrument Repository — production financial system
Specification: 11 pages, 26 invariants
Generated: 3,829 lines of production code
Invalid states possible: 0 // proven, not tested
  • Invalid states can be architecturally impossible, not merely unlikely
  • Language-agnostic generation (Python, Java, Rust, Go) from one spec
  • Changes flow through the specification, not scattered code edits
  • Legacy reverse engineering: extract formal specs from undocumented systems
350×
Spec compression vs requirements
0
Invalid states (proven)
90%+
Defect reduction (pilot)
5–10×
Faster delivery (pilot)
Discuss Spec++ → See a worked example →
Development tooling

Spec++ Pipeline

Specifications that diff like code—and fail CI like tests.

Spec++ Pipeline brings Spec++ into daily development: natural language intent → structured Spec++ → canonical AST, with provenance and satisfiability checking in Cursor, GitHub, and GitHub Actions.

  • Clause-level diffs; incremental re-lift on NL edits
  • [NLSource] links every formal obligation back to authoring text
  • CI gates on impossible obligation sets before merge
  • Skills path into specification stewardship for product and QA
Discuss Pipeline early access → Discuss an SDD programme →
For formal methods practitioners

Spec++ in context—not reinventing the wheel.

Spec++ sits in the same broad family as TLA+, Dafny, Alloy, and Rocq extraction: express what must be true, then generate or verify implementations. We are not claiming formal methods are new—we target a different production problem: AI-first regulated systems, where untrusted agents propose actions and a separate validator enforces rules deterministically at runtime, with evidence supervisors can verify.

Plain English: Think “specification + proof + generation + runtime gate”—not “yet another modelling language in isolation.”

Tool / tradition What we share Where Spec++ differs
TLA+ State, transitions, invariants, temporal properties Primary goal is code generation and runtime enforcement in production stacks—not design exploration alone
Dafny / Rocq Proofs, extraction, high assurance AI is an untrusted component at the edge, we architecturally prevent it from being the authority layer
Alloy Concise relational specs, counterexamples Focus on long-lived regulated production systems, not only early sketches
SMT / checking Catching inconsistent obligation sets Embedded in Spec++ Pipeline workflow (in active R&D)—NL → structured spec → check before CI merge
Runtime policy engines Allow/deny on policy Cryptographic evidence and proof-gated enforcement—examination-shaped artefacts, not narrative logs

Most formal tooling optimises for design assurance or proof of implementation. Riley Betts also optimises for operational accountability when agentic AI executes in regulated workflows: policy in checkable form, enforced before action, recorded in a hash-chained audit log with ZK proofs where selective disclosure matters. That is the CECO / Compliance Operator product line—pilot / PoC on domain workflows.

Methodology in customer use

Spec++ — specify, verify, generate. Pilots and engagements today.

Language & verification research

Spec++ research programme — toolchain hardening; labelled research, not quoted from confidential briefings on the public site.

Developer product

Spec++ Pipeline — in active R&D; implements methodology in IDE/CI.

We implement what we specify: SDD adoption programmes and software engineering with Spec++ SDD on customer systems—not licensing alone.

Research collaboration → Compare notes →

Most engagements begin with capabilities, not products alone. Work with us covers SDD adoption and Spec++ SDD engineering — products and pilots follow from there.