Kenton Labs / Programs & systems

Program verification

Connect preconditions, invariants, variants, and postconditions in a completely specified bounded program family.

The vocabulary.

These definitions state the objects and properties used by the dataset. The complete instance specification remains the authority for each result.

Loop invariant
A property maintained at every loop boundary.
Variant
A value in a well-founded domain that strictly decreases while the loop runs.
Postcondition
The property required when execution exits.

How the dataset works.

Three deterministic instances define this family. Each includes its input model, a checked result, evidence, and an acceptance procedure. Download the complete dataset JSON ↘ or the area’s readable source ↘.

Acceptance procedure

  1. Enumerate every admitted bound n.
  2. Start with i=0 and total=0.
  3. Check 2·total=i(i+1) and the decreasing variant n−i.
  4. Replay the sample trace and require total=n(n+1)/2 at exit.

Cost and scope

The family runs Σ n loop iterations for n=0…N, so total replay is O(N²).

A common failure

A postcondition on one execution is weaker than an invariant and a declared input domain.

Worked records.

Three instances expose concrete claims and the artifacts that establish or refute them. Expand a record for the problem, checker reasoning, formal payload, and verification metadata.

Sum-loop obligations for n ≤ 5Complete bounded program family · 6 inputs

The problem

Verify a loop that increments i and then adds i to total, starting from zero.

The checked result

Postcondition holds: yes; Variant decreases: yes.

The invariant explains the partial sum at each boundary. The remaining iteration count strictly decreases, and the exit condition turns the invariant into the postcondition.

Why the checker accepts it

  1. Enumerate every admitted bound n.
  2. Start with i=0 and total=0.
  3. Check 2·total=i(i+1) and the decreasing variant n−i.
  4. Replay the sample trace and require total=n(n+1)/2 at exit.

Formal specification

{
  "program": "sum-first-n",
  "max_n": 5,
  "sample_n": 3,
  "precondition": "n ≥ 0; i=0; total=0",
  "invariant": "2*total = i*(i+1) and 0 ≤ i ≤ n",
  "variant": "n-i"
}

Claim and evidence

{
  "claim": {
    "postcondition_holds": true,
    "variant_decreases": true
  },
  "witness": {
    "trace": [
      [
        0,
        0
      ],
      [
        1,
        1
      ],
      [
        2,
        3
      ],
      [
        3,
        6
      ]
    ]
  }
}

Dataset construction

Deterministic finite fixture; full enumeration or witness replay as stated. Structured JSON; field meanings are stated in the specification. Acceptance covers 6 checker units for this record; the unit type is stated in its verification scope.

Complexity and limits

The family runs Σ n loop iterations for n=0…N, so total replay is O(N²).

This replay checks n through the stated bound; it does not constitute an unrestricted deductive proof.

A boundary to investigate

A postcondition on one execution is weaker than an invariant and a declared input domain. Add inductive proof obligations and externally checked Hoare derivations.

Readable source ↘Record JSON ↘Full area ↗Related KL-FCS-041 ↘Related KL-FCS-042 ↘
Sum-loop obligations for n ≤ 10Complete bounded program family · 11 inputs

The problem

Verify a loop that increments i and then adds i to total, starting from zero.

The checked result

Postcondition holds: yes; Variant decreases: yes.

The invariant explains the partial sum at each boundary. The remaining iteration count strictly decreases, and the exit condition turns the invariant into the postcondition.

Why the checker accepts it

  1. Enumerate every admitted bound n.
  2. Start with i=0 and total=0.
  3. Check 2·total=i(i+1) and the decreasing variant n−i.
  4. Replay the sample trace and require total=n(n+1)/2 at exit.

Formal specification

{
  "program": "sum-first-n",
  "max_n": 10,
  "sample_n": 5,
  "precondition": "n ≥ 0; i=0; total=0",
  "invariant": "2*total = i*(i+1) and 0 ≤ i ≤ n",
  "variant": "n-i"
}

Claim and evidence

{
  "claim": {
    "postcondition_holds": true,
    "variant_decreases": true
  },
  "witness": {
    "trace": [
      [
        0,
        0
      ],
      [
        1,
        1
      ],
      [
        2,
        3
      ],
      [
        3,
        6
      ],
      [
        4,
        10
      ],
      [
        5,
        15
      ]
    ]
  }
}

Dataset construction

Deterministic finite fixture; full enumeration or witness replay as stated. Structured JSON; field meanings are stated in the specification. Acceptance covers 11 checker units for this record; the unit type is stated in its verification scope.

Complexity and limits

The family runs Σ n loop iterations for n=0…N, so total replay is O(N²).

This replay checks n through the stated bound; it does not constitute an unrestricted deductive proof.

A boundary to investigate

A postcondition on one execution is weaker than an invariant and a declared input domain. Add inductive proof obligations and externally checked Hoare derivations.

Readable source ↘Record JSON ↘Full area ↗Related KL-FCS-040 ↘Related KL-FCS-042 ↘
Sum-loop obligations for n ≤ 20Complete bounded program family · 21 inputs

The problem

Verify a loop that increments i and then adds i to total, starting from zero.

The checked result

Postcondition holds: yes; Variant decreases: yes.

The invariant explains the partial sum at each boundary. The remaining iteration count strictly decreases, and the exit condition turns the invariant into the postcondition.

Why the checker accepts it

  1. Enumerate every admitted bound n.
  2. Start with i=0 and total=0.
  3. Check 2·total=i(i+1) and the decreasing variant n−i.
  4. Replay the sample trace and require total=n(n+1)/2 at exit.

Formal specification

{
  "program": "sum-first-n",
  "max_n": 20,
  "sample_n": 8,
  "precondition": "n ≥ 0; i=0; total=0",
  "invariant": "2*total = i*(i+1) and 0 ≤ i ≤ n",
  "variant": "n-i"
}

Claim and evidence

{
  "claim": {
    "postcondition_holds": true,
    "variant_decreases": true
  },
  "witness": {
    "trace": [
      [
        0,
        0
      ],
      [
        1,
        1
      ],
      [
        2,
        3
      ],
      [
        3,
        6
      ],
      [
        4,
        10
      ],
      [
        5,
        15
      ],
      [
        6,
        21
      ],
      [
        7,
        28
      ],
      [
        8,
        36
      ]
    ]
  }
}

Dataset construction

Deterministic finite fixture; full enumeration or witness replay as stated. Structured JSON; field meanings are stated in the specification. Acceptance covers 21 checker units for this record; the unit type is stated in its verification scope.

Complexity and limits

The family runs Σ n loop iterations for n=0…N, so total replay is O(N²).

This replay checks n through the stated bound; it does not constitute an unrestricted deductive proof.

A boundary to investigate

A postcondition on one execution is weaker than an invariant and a declared input domain. Add inductive proof obligations and externally checked Hoare derivations.

Readable source ↘Record JSON ↘Full area ↗Related KL-FCS-040 ↘Related KL-FCS-041 ↘

Go further.

Add inductive proof obligations and externally checked Hoare derivations.

Questions to investigate

  1. A postcondition on one execution is weaker than an invariant and a declared input domain.
  2. Which assumption in the specification can be changed to make the current evidence insufficient?
  3. Add inductive proof obligations and externally checked Hoare derivations.

Conceptual references

These sources explain the surrounding theory. The linked material was not imported as a dataset, and these records do not claim checking by the source’s software.

Related areas