cladding

English · 한국어 · 日本語 · 中文

To trust AI with coding, an organization needs three things — that the code can be trusted,that it's traced, and that it holds up as you scale. cladding builds those three. True to its name (cladding = the outer layer), it wraps your host LLM (Claude Code · Codex · Gemini · Antigravity · Cursor): before it starts, cladding feeds it the project's intent; after it finishes, cladding verifies the result with 41 detectors and a 15-stage gate.

This loop is after one thing — turning the AI's "it's done" from a claim into a proof.

So you can ship AI-written code held to the same standard as human-written code — the three things an organization needs to hand coding to AI:

• Trusted — only code that cleared every check is recognized as done; an "it's done" you can't verify never passes.
• Traced — What shipped is on the record: what was verified is stamped into committed content, who and when land in the local session ledger, and the why lives in the spec — so handoff and review skip the archaeology.
• Scales — adding people and AIs would normally multiply conflicts and drift; because everyone works from one shared spec, those get caught automatically — so you can grow without it breaking down.

cladding builds itself with cladding too — 291 of its 306 features cleared this same gate, the first L4 implementation of the Ironclad standard.

What changes

The same situation, in a vanilla AI setup and in cladding.

Who it's for

• A developer who has an AI write code — when the AI says "it's done," cladding doesn't take its word for it: it checks whether the work actually passes, and only then counts it as done. (Automating it in a loop? That's the loop section.)
• A team of people and AIs — everyone works from the same spec, so when their changes clash or drift apart it's caught automatically, and no one breaks someone else's work by accident.
• An organization that has to prove its work — every done is recorded with the proof that it actually passed, so months later "was this verified? why was it built this way?" is answered by the repo, not by memory.

How cladding wraps your host LLM

Before — inject the intent, so the LLM starts with the right context:

• Only the intent that matters — the why of the feature at hand, its related features, and its acceptance criteria (never the whole spec).
• Project map injected — feature counts, what's in progress, and the last verification result, handed over at the start of every conversation (and now you can see it too ↓).
• Team rules applied — the forbidden and preferred patterns you agreed on, as standing instructions every time.

After — verify the result: the 15-stage gate, 41 drift detectors, and an implementation-blind grader — an agent that checks the work against the spec with no tool to read the implementation, so it can't rubber-stamp what it wrote.

Real-time intervention (map injection · instant block · stop-block) runs fully on Claude Code. On Codex · Gemini · Antigravity · Cursor the same verification runs through in-conversation tool calls plus the git · CI gate.

"done" is earned, not declared

The chronic disease of AI coding is "it's done" declared with nothing behind it. In cladding, status: done is not a value you write — it's a value you earn.

1. Try to write the completion mark yourself → blocked on the spot ("earn it by verifying it").
2. Request completion → all 9 deterministic stages run; recorded as done only if every one passes, else it auto-reverts (the E2E · evidence stages run in CI's full 15).
3. The moment it passes, a verification signature is committed — proof that "this code was verified at this point."
4. Try to end a session on a failure → blocked once (end again on the same failure and it's logged as a known-failing exit rather than let through), and the repair card carries into the next conversation.

Stated plainly: bypass paths exist that the instant block can't see; those are caught by the after-the-fact gate. Instant block is the first line of defense, the gate the second — neither is a standalone guarantee.

cladding backs your AI loop

Loop engineering is a shift in how you use an AI: instead of prompting it step by step, you build a loop that drives it toward a goal and runs on its own — discover, plan, execute, verify, iterate. But a loop is only as honest as its verify step, and an AI left to check its own work just passes itself. So you put something in the loop that can truly say "no" — that's cladding: the check that grades your code against your spec, not the AI's opinion of its own work.

Three things it gives your loop:

• A signal it can act on — every pass you get back a plain, machine-readable result: what failed, where, and how bad. Feed it straight into the loop, no console-scraping (clad check --json).
• An honest stop — the loop ends on the gate, not the AI's word. A feature turns done only when the strict gate is GREEN, and reverts if it isn't. "The AI says it's finished" becomes "the gate let it stand."
• A memory across passes — a local log (.cladding/events.log.jsonl) remembers the last pass's checks, tries, and drift, so the next one doesn't start blind.

Project graph — see it and ask it

This is cladding's internal graph of your project — spec · code · tests · docs, all connected. Now you can see it and ask it.

Why it matters — docs and code don't drift apart. Docs lie as time passes: the code changes, the description doesn't. cladding re-checks that link every time it reads the code, and blocks "done" while the two are out of sync.

Blue = spec (center) · orange = code · green = tests · pink = docs; the more a node connects, the larger it grows and the more it pulls toward the center.

• See — run clad graph serve and the whole project opens in your browser; what connects to what, at a glance.
• Ask — "what breaks if I change this?" The graph answers with the affected code and the tests to run — it doesn't guess.
• Measure — the bigger the project, the more it saves: a median 4× less to read when fixing something (clad measure · how it's measured).

clad graph serve                                  # live graph — localhost:3000, auto-reloads on save
clad graph export --format html --out graph.html  # or a single offline .html file

Requires cladding 0.7.0+.

Under the hood

Spec → Code → Tests as one cycle — the spec records the why, the gate verifies, the detectors block drift.

Spec — the project's long-term memory. An LLM forgets everything between sessions, so the spec is where the project's intent lives: durable, versioned in git, and fed to the model before it starts. It holds the why and the what; the design tier just below holds the how. (It's the memory of intent, not a log of what happened.) Four tiers, top to bottom: intent (A) — sealed until a human signs off — then design (B), code + attestation (C), and audit (D). A outranks all — if the spec and the code ever disagree, the code is the one that's wrong.

Each feature is its own sharded file with an 8-char hash ID, so two devs adding features at once never collide. A feature reads like this — the what, written as a testable acceptance criterion:

# spec/features/checkout-a1b2c3d4.yaml
id: F-a1b2c3d4
slug: checkout-idempotency
status: done
acceptance_criteria:
  - id: AC-9f3e21a0
    text: "When a charge is retried with the same idempotency key, the system
            shall return the original result and never double-charge."
    test_refs: ["tests/checkout/idempotency.test.ts#retry returns the original charge"]

EARS keeps every criterion testable — WHEN <trigger> … the system SHALL <response>, the shape of the text: field above.

→ 4-tier model · hash-based IDs

Gate — the 15-stage Iron Law. One check engine, bundled by cost — 3 run at commit, 9 at push/completion, all 15 in CI:

• Static (6) — Type · Lint · Drift · Commit-clean · Architecture · Secrets
• Test & conformance (4) — Unit · Coverage · Spec-conformance (the impl-blind grader) · Deliverable smoke (blocks the empty green: tests pass but the deliverable never runs)
• End-to-end (3) — Smoke · Performance · Visual