Verification-Driven Development

AI that ships code
without the slop.

IronCarapace is a self-hosted autonomous software engineering platform that subjects every AI-generated implementation to formal specification, deterministic quality gates, and adversarial attack before it ships. Not code that looks right. Code that is right.

Request Early Access See the pipeline →
6 deterministic quality gates
≥85% mutation kill rate required to ship
0 external services required for local LLM mode
3 AI agents: spec writer, coder, adversary
The problem

AI writes code.
Who verifies it?

Every AI coding tool on the market generates plausible-looking output. Plausible is not correct. A developer still catches every mistake — which defeats the promise of automation.

Autocomplete is not automation

Copilot and Cursor generate suggestions. A developer accepts, rejects, and reviews every line. The cognitive load doesn't disappear — it shifts.

Autonomous tools don't verify

Cloud-based autonomous agents ship code that compiles and passes their own tests. But much like with humans, the one who implements the code struggles to properly test the code.

Your code leaves your building

Every cloud AI tool is a conduit for your proprietary algorithms, business logic, and IP to reach third-party infrastructure. Regulated industries can't accept that.

How it works

The VDD pipeline

Every task moves through a fixed sequence of phases. Human approval gates block advancement at two points. The implementation cannot ship unless every gate passes.

Click any stage to expand

AI writes the contract

Interfaces, type signatures, acceptance criteria — derived from your description. The spec defines what is in scope and what success looks like.

Human locks the scope

No implementation begins until you review and approve the spec. This is the only moment where intent can be corrected at zero cost.

AI derives tests from the contract

Tests are written before code exists. They flow from the spec, not from what the implementation happens to do.

Tests run against a stub. They must fail.

If tests pass before implementation → pipeline stops. Tests that can't fail don't prove anything. This gate eliminates tests that would rubber-stamp any code.

AI writes production code

Implementation happens only against the approved, tested contract — not against a moving target.

Six checks that don't negotiate

  • Contract
  • Tests
  • Types
  • Behavior
  • Security
  • Mutation

Each gate either passes or stops the pipeline. No partial credit.

On fail

AI reworks and retries. Attempts are capped. If the cap is reached without passing all gates, the task fails — it does not reach adversarial review.

The system challenges what survived the gates

Finds gaps the deterministic gates couldn't see: underspecified behaviors, exploitable assumptions, semantic ambiguities. Uses IronClaw — a dedicated AI reasoning service — to do that work.

A bounded, reviewable change

Only code that survived every gate and adversarial review reaches a human reviewer. The MR is a record of what was proved, not a request for faith.

VDD gates — binary pass/fail, no scores
CONTRACT
Formal spec compliance · 13 traceability checks · no vague postconditions
PASS ✓
STATIC
mypy type safety · ruff lint · bandit security scan
PASS ✓
TESTS
All pytest acceptance tests pass · property tests pass
PASS ✓
MUTATION
88.3% mutants killed · threshold ≥85% · syntactic + semantic operators
88.3% ✓
COMPLEXITY
Empirical log-log slope = 1.04 · declared O(n) · tolerance ±0.3
PASS ✓
REGRESSION
Advisory · baseline comparison · non-fatal
ADVISORY
Built for IronClaw users

IronClaw runs your agent.
IronCarapace proves its work.

IronClaw gives your agent a capable, well-orchestrated operating environment — memory, skills, jobs, sandboxed tools. IronCarapace adds the layer IronClaw wasn't built to provide: independent proof that what the agent produced is actually correct.

The two systems are complementary by design. You bring the agent. IronCarapace holds it accountable.

How they fit together
IronClaw
agent loop · memory · skills
jobs · tools · sandboxing
↓
artifacts + traces
IronCarapace
verify · attack · attribute
prove · audit · evolve
Eight provable capabilities — implemented today, not roadmap
01

Spec-first, human-approved

A formal specification with typed interfaces and machine-verifiable postconditions must be written and approved by a human before a single line of code is generated.

AWAITING_SPEC_APPROVAL blocks pipeline
vague terms auto-rejected at submission
02

Tests must fail first

TDD red-phase is enforced as a hard gate. Every test must fail against the stub. A test that passes against broken code proves nothing and is rejected.

CONFIRMING_RED phase · pipeline blocks
if any test passes the stub
03

≥85% mutation kill rate required

Code cannot ship unless the test suite catches at least 85% of code mutations. Syntactic mutations plus 7 semantic operator classes that mutmut misses.

MUTATION gate · fatal · binary
84.9% is a failure, not a warning
04

Adversarial attack on the spec

The Plan itself is attacked. Interfaces are deleted, postconditions weakened, APIs merged. Any element that survives without a test failure was decorative — and is flagged before it reaches production.

weakness_map · load-bearing vs. decorative
05

Empirical complexity verification

If the spec declares O(n log n), the implementation must prove it. IronCarapace runs the code against a geometric input sequence and fits a log-log regression slope. A mismatch is a fatal gate failure.

log-log slope · tolerance ±0.3
06

Six binary gates — no scores

Contract · Static analysis · Tests · Mutation · Complexity · Regression. Each gate is pass or fail. No weighted averages, no partial credit, no "close enough." One fatal failure blocks everything.

binary pass/fail · no partial credit · one failure blocks ship
07

Full audit trail per run

Every run records model IDs and versions, random seeds per mutation family, and adversarial weight snapshots. The complete record is immutable and stored locally. Built for regulated industries that require auditable decisions.

model ID · seeds · gate verdicts · weight snapshots
stored locally, never transmitted
08

Independent verification layer

The agent that produced the work cannot verify the work. Verification runs in an isolated context with no shared memory, no shared history, and no access to the implementer's reasoning.

memory isolation enforced by role matrix
Architecture

Three subsystems.
One authority each.

Clean separation of concerns is what makes the system trustworthy. No subsystem can override the authority of another.

Subsystem 1

VDD — Verification

The sole arbiter of correctness. Runs deterministic, binary pass/fail gates. Never uses scores, never uses weighted averages. A single fatal issue fails the entire pipeline. VDD cannot be overridden.

Formal Plan schema with typed interfaces and postconditions
Contract validation — vague terms cause immediate rejection
Static analysis: mypy, ruff, bandit in sequence
Mutation testing with ≥85% kill rate requirement
Empirical complexity verification against declared O(n) class
Subsystem 2

IronClaw — Adversary

Runs after VDD passes. Finds weaknesses that deterministic gates miss — underspecified contracts, test suite gaps, fragile implementations. Produces advisories; cannot override VDD verdicts.

Plan mutation: removes interfaces, weakens contracts, merges APIs
Semantic mutation: exception swallowing, loop-bound shifts, accumulator poisoning
Hidden fuzz injection: property tests derived from postconditions
Dirichlet-weighted adversarial scoring — weights not disclosed to implementer
Weakness map ranks each contract element as load-bearing or decorative
Subsystem 3

Chainlink — Orchestrator

Drives the task lifecycle state machine. Does not generate code, does not verify it. Coordinates the agents that do. Routes outcomes: accept, fix-loop, escalate, or reject.

State-machine task lifecycle with deterministic phase replay
Memory isolation: planner, implementer, adversary cannot see each other's reasoning
Human checkpoint gates block advancement until explicitly approved
Every run logs model IDs, seeds, and weight snapshots
REST API — tasks created, approved, and monitored via HTTP
Deployment

Runs on your infrastructure.
Not ours.

IronCarapace is deployed entirely within your network using rootless Podman containers. In fully local mode, nothing leaves your machines: no code, no specs, no test output.

01

Self-hosted on your hardware

Deployed as rootless Podman pods on Ubuntu. No cloud dependency. Runs on a workstation, a server, or an air-gapped facility. Minimal footprint.

02

Two modes: fully local, or cloud API

Local mode: Ollama with open-weight models (Qwen, Llama, Mistral). Nothing leaves your network. Cloud API mode: use your own Anthropic or OpenAI keys. Requests go directly from your host to the provider — IronCarapace is not in that path — but code does reach their infrastructure.

03

Early access, then per-seat licensing

Currently in early access for qualified engineering teams and investors. Designed for per-seat licensing with no usage telemetry leaving your network unless you opt in.

04

Full audit trail

Every task run is recorded with model version, random seeds, weight snapshots, and gate verdicts. Any run can be replayed identically. Built for compliance.

Pod layout (single host)
ironcarapace-orchestrator
vdd-orchestrator · Chainlink REST :9002
claude-dispatcher · task poller
↕ ironcarapace-prod bridge
ironcarapace-core
ironclaw-agent (Rust) :3000
webhook handler :8081
↕
llm-inference
Ollama :11434 · local model weights
↕
ironcarapace-db
PostgreSQL + pgvector :5433
All containers: rootless · UID 1100
Networks: isolated bridge · no host network
Data: bind-mounted SSD · no PVC escapes
Comparison

What other tools don't do

The difference is not model quality. The difference is whether the system holds itself accountable for what it ships.

CapabilityIronCarapaceGitHub CopilotCursorDevin
Fully autonomous (no per-step review)✓××✓
Formal specification before code✓×××
Deterministic pass/fail verification gates✓×××
Mutation testing with minimum kill rate✓×××
Adversarial attack on spec + implementation✓×××
Self-hosted platform — runs on your own machines✓×××
Local LLM support (air-gapped)✓×××
Immutable per-run audit trail (model, seeds, verdicts)✓×××
Human approval checkpoints✓××✓
Who it's for

Built for teams
that cannot afford wrong.

If your team is shipping with AI agents, you need a verification layer the model cannot write for itself.

AI-generated code

The model writes it. IronCarapace proves it.

LLM output is plausible by construction. Six binary gates run between spec approval and merge: mutation kill rate, complexity bounds, adversarial spec attack, interface stability, behavior diff, and coverage floor. What passes is documented. What fails is caught.

Compliance requirements

An audit trail that exists before anyone asks for it.

Every run produces an immutable record: which model generated the code, which spec governed it, which gates passed, and when. No retroactive documentation required.

QA bandwidth

Review for architecture. Not for correctness.

Engineering teams spending 30-40% of bandwidth on correctness checks can redirect that effort. IronCarapace enforces what would otherwise require a senior reviewer on every pull request.

Mutation-sensitive software

Find the gaps before the gaps find you.

Adversarial spec attacks delete interfaces, weaken postconditions, and merge distinct APIs, then check whether your tests catch it. Decorative test suites fail. Specs that constrain behavior pass.

Early Access

Join the early access list.

IronCarapace is in early access. We are onboarding a small number of engineering teams and evaluating qualified investors. Tell us about your setup.

No commitment. We'll reach out to qualified teams within 5 business days.

Theoretical foundations
  1. Hoare, C.A.R. (1969). "An Axiomatic Basis for Computer Programming." Communications of the ACM, 12(10), 576–580. [ACM] Formal preconditions and postconditions — the theoretical basis for VDD contract gates.
  2. DeMillo, R.A., Lipton, R.J., & Sayward, F.G. (1978). "Hints on Test Data Selection: Help for the Practicing Programmer." IEEE Computer, 11(4), 34–41. Original mutation testing paper; established why syntactic code mutations expose test suite weaknesses.
  3. Andrews, J.H., Briand, L.C., & Labiche, Y. (2005). "Is Mutation an Appropriate Tool for Testing Experiments?" Proceedings of ICSE 2005, 402–411. [ACM] Validates mutation testing as a proxy for real fault detection; supports the ≥85% kill rate gate design.
  4. Claessen, K., & Hughes, J. (2000). "QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs." Proceedings of ICFP 2000, 268–279. [ACM] Property-based testing from postconditions — the technique underlying IronClaw's hidden fuzz injection.
  5. Chen, M., et al. (2021). "Evaluating Large Language Models Trained on Code." arXiv:2107.03374. [arXiv] HumanEval benchmark showing frontier LLMs solve ~28–72% of problems correctly; establishes that LLM code requires independent verification.
  6. Pearce, H., et al. (2022). "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions." IEEE Symposium on Security and Privacy (S&P 2022). [arXiv] Up to 40% of Copilot suggestions in security-sensitive contexts were vulnerable; motivates the bandit static analysis gate.
  7. Perry, N., et al. (2023). "Do Users Write More Insecure Code with AI Assistants?" Proceedings of ACM CCS 2023. [arXiv] Controlled study showing AI-assisted developers produce less secure code and are more confident it is secure.