SMT proved
intrinsic_value
A non-negative intrinsic-value property is polynomial and discharges cleanly.
Proofs
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
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_valueA non-negative intrinsic-value property is polynomial and discharges cleanly.
SMT proved, algebraic kernel
put_call_parity_residualThe 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_callA normal-CDF path is kept as property-based validation with explicit preconditions and sample count.
disproved
lower_bound_discS 150.00 · K 50.00 · r 0.02 · sigma 0.15 · T 0.25
Foundation
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
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.
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 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.
Effect rows make ambient operations visible in the type. Pure property code cannot call an undeclared effect and still pass as pure code.
Linearity puts resource use in the typing judgement. The checker rejects ownership paths that duplicate or drop a linear value against the rules.
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
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.
A structured rule names the function, input types, preconditions, and expected response.
The rule becomes a property witness with quantifiers, preconditions, source id, and role metadata.
Chelis code supplies the function under check. The property states how the implementation must match the specification.
Solver-dischargeable obligations are sent to SMT. A proved result is recorded with the property, assumptions, and provenance.
Properties outside the solver route stay explicit. Property-based validation records preconditions, sample count, validation status, and provenance.
The output records the property name, proof tier, status, source requirement, and timing reviewers can inspect.
Boundary
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 one property your review currently takes on trust. We will map the evidence it can get and what its C Note would record.