CARBON — Engineering ConfidenceUser Guide
CHAPTER 33 / 60 Pro

/proof

Automatically select a consequential code property and attempt bounded local Lean verification with CARBON.

Jay · Your AI test managerProof & release confidence

When to use it

A consequential code property has a small, supported formal scope.

Before you start

Bare /proof ranks source-grounded candidates and attempts one supported property automatically. Lean is required. Toolchain installation needs approval. Supported restricted Python Boolean and finite JavaScript state-transition models are not general proofs of arbitrary application code.

Try this in your coding agent.

/proof Inspect src/orders/state.js and attempt a Lean-backed proof of our documented order-transition rules. Keep unsupported behavior explicit.

Replace sample paths with your project. Slash names are shorthand; your host may use a plugin prefix or a skill picker. Invocation help →

Read the verdict precisely.

PROVED
The recorded model property holds in its stated domain under its assumptions.
COUNTEREXAMPLE
A concrete failure has replay evidence. Preserve the input and regression fixture.
UNPROVED
Unsupported semantics, missing Lean/isolation, unresolved obligations or budget exhaustion. Not automatically a bug.
STALE
The fingerprint or dependencies changed. Fresh preparation and checking are needed.

Lean is mandatory: no native-only fallback. New toolchain downloads/container setup need explicit permission. Default automatic verification is one bounded attempt; manual selection is opt-in. A successful setup or generated Lean file is not a proof result.

Illustrative Lean: a tiny status model

This teaching example is not runtime-generated output or proof of the application. It only demonstrates the shape of a narrow model claim.

inductive Status where
  | pending | paid | shipped | cancelled
  deriving DecidableEq

def allowed (a b : Status) : Bool :=
  match a, b with
  | .pending, .paid => true
  | .pending, .cancelled => true
  | .paid, .shipped => true
  | _, _ => false

theorem cancelled_stays_closed (next : Status) :
    allowed .cancelled next = false := by
  cases next <;> rfl

ILLUSTRATIVE WALKTHROUGH

Order-status transition contract

An expanded teaching example, not a recorded or live execution. The report stays visible while the replay explains how to read it.

  1. 01Rank targets
  2. 02State the contract
  3. 03Build Lean model
  4. 04Check + replay
  5. 05Qualify the result

Coding-agent conversation

Rank targets

Rank consequential payment, authentication and data-integrity paths; select a supported target.

State the contract

Use documented order transitions as the independent requirement. Keep assumptions explicit.

Build Lean model

Translate supported finite state logic into a Lean model; record the original source fingerprint.

Check + replay

Attempt the bounded Lean check and retain original-source replay evidence separately.

Qualify the result

Report the exact property, domain and limitations; unsupported behavior remains UNPROVED.

CARBON

Example report

Illustration
State → permitted transition → evidence
State → permitted transition → evidence — TestBucks teaching screen

TestBucks course screen with illustrative analysis. The screenshot supplies context; the demo does not establish a newly observed bug.

  1. Order status
  2. Independent contract
  3. Qualified model claim

Illustrated outcome

Illustration: only documented one-step order transitions are accepted by the model.

Evidence to inspect

Compare an independent status/transition contract with the selected lookup, guard and status-assignment code. Retain original-source replay separately from the Lean verdict.

Still untested / not established

No Lean compiler runs in this booklet. Source/model equivalence, arbitrary JavaScript, long event sequences, callers and whole-app correctness are not proved.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For order-status transition contract, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Compare an independent status/transition contract with the selected lookup, guard and status-assignment code. Retain original-source replay separately from the Lean verdict. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

No Lean compiler runs in this booklet. Source/model equivalence, arbitrary JavaScript, long event sequences, callers and whole-app correctness are not proved.

The next decision

Decide whether the evidence calls for a focused check, a reviewed fix or more context. Do not convert a plausible example into a verified finding.

Adapt the example to your project

  1. Replace order-status transition contract with a real feature, path or decision in your project.
  2. State the expected rule and its source. Include safe fixtures, constraints and a budget where appropriate.
  3. Ask for exact evidence and remaining gaps. Approve consequential actions separately.
/jay Review the /proof result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-test →/carbon-generate →

Content checked against the local command definition: skills/proof/SKILL.md. Examples adapted from the homepage’s TestBucks walkthroughs. Availability is edition- and host-dependent.