Proofs

Verified understanding

A proof result is only useful if it tells you something you can act on. C Proof's output reads as understanding of a model: where its required properties hold, where they break, the input that witnesses each break, and the evidence behind every line.

The result

Held, broken, witnessed

Every property lands in one of three states, and each state carries an object you can read.

Holds, proved.

The obligation discharged as an SMT proof. The record carries the property, the domain assumptions, and the solver result.

Holds, validated.

The property ran as property-based validation: sampled, not proven. The record carries preconditions, sample count, and seed. Validation is never relabeled as proof.

Breaks.

The record marks the property disproved and carries the counterexample: the concrete input at which the implementation contradicts the specification. The prose on this site calls it the witness. A break is a finding. It shows where the model stops being valid.

SMT proved

intrinsic_value

A non-negative intrinsic-value property is polynomial and discharges cleanly.

SMT proved, algebraic kernel

put_call_parity_residual

The parity residual proves for the checked algebraic kernel under the stated rate and tenor preconditions. Through the closed-form price path it runs as labeled validation.

validated

black_scholes_call

A normal-CDF path is kept as property-based validation with explicit preconditions and sample count.

disproved

lower_bound_disc

S 150.00 · K 50.00 · r 0.02 · sigma 0.15 · T 0.25

model
100.2394
bound
100.2494
shortfall
-0.0100
Parameter region for the discounted lower bound check: the property holds below the boundary curve, violations occur above it, with the witness marked at tenor 0.25 and moneyness 3.0
Where the check found violations at this slice: the property holds below the frontier, and the witness sits above it. From the same worked example.

Foundation

Formal core

LaCaDiLE, the Lambda Calculus for Differentiable Linear Effects, is the Lean 4 model of the core language: tensors, named-dimension indexing, algebraic effects, linear types, and differentiation. The core rules of the language are machine-checked in LaCaDiLE, more than 85,000 lines of Lean 4 with no unproven placeholders.

The foundation is scoped. It backs language rules and implementation/spec matching; it does not validate every generated program or decide whether every domain requirement is the right one.

In plain terms: the language rules are machine-checked theorems. The design does not rest on anyone having been careful.

type_soundness

Progress.leanPreservation.lean

Mechanized as two theorems, progress and preservation: a well-typed program is a value or can take a step, and stepping preserves its type.

dimension_safety

DimSafety.lean

Named-dimension agreement proved by the type system is not left as a primitive runtime shape check. Well-typed terms avoid primitive shape mismatch.

effect_correctness

EffectCorrectness.lean

An empty effect row means the term does not get stuck trying to perform an effect operation. Effects are part of the typed interface.

linearity_soundness

LinearitySoundness.lean

Evaluation preserves store well-formedness, so the linear resource discipline is tied to the operational model instead of an ownership convention.

ad_correctness

ADCorrectness.lean

For the supported first-order fragment, automatic differentiation is mechanized against an abstract primitive AD specification. Higher-order and closure AD are outside this theorem claim.

Guarantees

Static edge

Python and JavaScript can enforce many numerical contracts with libraries, annotations, assertions, and tests. Chelis moves selected contracts into static semantics, so violations are refused before execution when they contradict the declared program.

In plain terms: structural mistakes are refused at compile time. No property has to catch them later.

Dimensions

Tensor dimensions live in Chelis types. A function that promises a named dimension cannot silently combine it with a different dimension and still type-check.

Precision

Precision is declared at the boundary, such as f32 or f64, so generated code has to match the stated numerical contract instead of relying on a runtime dtype convention.

Effects

Effect rows make ambient operations visible in the type. Pure property code cannot call an undeclared effect and still pass as pure code.

Ownership

Linearity puts resource use in the typing judgement. The checker rejects ownership paths that duplicate or drop a linear value against the rules.

AD

Differentiation behavior is tied to the core calculus for the covered fragment, with coverage stated in the proof claim instead of left to a library test suite or handwritten gradient convention.

User code

Proof path

The user-code path starts with a requirement and ends with evidence. It distinguishes an SMT proof from property-based validation, and it keeps provenance attached instead of flattening every result into a pass.

In plain terms: a requirement becomes an executable property. The artifact says what held and what did not.

Requirement

A structured rule names the function, input types, preconditions, and expected response.

Chelis property

The rule becomes a property witness with quantifiers, preconditions, source id, and role metadata.

Implementation

Chelis code supplies the function under check. The property states how the implementation must match the specification.

SMT proof

Solver-dischargeable obligations are sent to SMT. A proved result is recorded with the property, assumptions, and provenance.

Property validation

Properties outside the solver route stay explicit. Property-based validation records preconditions, sample count, validation status, and provenance.

Artifact

The output records the property name, proof tier, status, source requirement, and timing reviewers can inspect.

Boundary

Evidence scope

The point is auditable evidence, not a blanket correctness claim. C Proof reports what the type system rejected, what the solver proved, what validation checked, and what remains a human modeling decision.

Properties check implementation against specification, not whether the specification is right.

The engine's proofs are over real arithmetic. Floating-point roundoff is out of scope.

The audit chain runs from approved specification to compiled binary. Reviewers walk it end to end.

Review

Bring a property

Bring one property your review currently takes on trust. We will map the evidence it can get and what its C Note would record.

Talk to us