Formal. Enforced. Proven.
Three product lines share one architectural spine: describe rules precisely, verify before you ship, enforce at runtime when AI acts in regulated workflows. Capabilities (SDD adoption and engineering engagements) are how most organisations start—we build with your team; these products are how the discipline scales.
Spec++
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.
- 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
Spec++ Pipeline
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
Designed surface in active R&D—not GA in every environment.
Compliance Operator
Cryptographically Enforced Compliance Operator (CECO)—deterministic agentic governance for regulated AI. AI agents are untrusted; CECO evaluates against your formal policy before execution. Headlines use Compliance Operator; architects often say CECO.
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
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.
Spec++ — specify, verify, generate. Pilots and engagements today.
Spec++ research programme — toolchain hardening; labelled research, not quoted from confidential briefings on the public site.
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.