Skip to content

The vacuous ratchet counts 44 of 114 - #2890

Merged
gHashTag merged 2 commits into
masterfrom
w736
Aug 29, 2026
Merged

The vacuous ratchet counts 44 of 114#2890
gHashTag merged 2 commits into
masterfrom
w736

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Completeness.lean holds 250 hand-transcribed models, one per spec, each with a theorem asserting the module is Icarus-lowerable.

models in the file 250
with functions := [] 114
…and an empty Env too 104
counted by max_vacuous 44
vacuous and invisible to it 70

A theorem about an empty module says nothing about its spec: native_decide on an empty structure proves something true and useless.

max_vacuous — the ratchet that exists to stop that number growing — reads the mismatch ledger, and an entry only reaches that ledger if the model also disagrees with the Rust classifier. Whether a theorem is vacuous has nothing to do with whether the classifier happens to disagree.

A ratchet measuring a subset of its own subject is worse than no ratchet, because the number it reports looks like the number you care about. Its 44 marks are all correct — zero entries marked model_empty that are not — so this is a coverage gap, not a wrong reading.

Measured twice, by a throwaway Python scan and by the shipped Rust, agreeing on every one of the five numbers.

The command refuses rather than printing zero when it matches no modules: a zero from a scanner that found nothing is indistinguishable from a clean file, and the file's shape is exactly what would change under it. 4 tests.

What this is not

Last pass I named "write real Lean models for those four" as the only honest way to lower max_vacuous. I am not doing it, and the reason is not effort.

lean, lake and elan are not installed here. .github/workflows/lean-proofs.yml has a lake build, so the instrument exists — just not where I am. And a faithful model may make its theorem false: the classifier says Rust=false for those four specs, so an honest transcription might be unprovable. That would be the correct outcome rather than a bug — but I cannot tell the correct outcome from my own transcription error without building it.

Writing a proof I cannot check and pushing it to see what CI says is the thing this repository exists to prevent. The count is reported instead.

Refs #2747

`Completeness.lean` holds 250 hand-transcribed models, one per spec,
each with a theorem asserting the module is Icarus-lowerable. 114 of
them have `functions := []`, and 104 of those have an empty `Env` too. A
theorem about an empty module says nothing about its spec:
`native_decide` on an empty structure proves something true and useless.

`max_vacuous`, the ratchet that exists to stop that number growing,
counts 44 -- because it reads the mismatch ledger, and an entry only
reaches that ledger if the model ALSO disagrees with the Rust
classifier. Whether a theorem is vacuous has nothing to do with whether
the classifier happens to disagree.

    models in the file            250
    with `functions := []`        114
    ...and an empty Env too       104
    counted by max_vacuous         44
    vacuous and INVISIBLE to it    70

A ratchet measuring a subset of its own subject is worse than no
ratchet, because the number it reports looks like the number you care
about. Its 44 marks are all correct -- zero entries marked
`model_empty` that are not -- so this is a coverage gap, not a wrong
reading.

Measured twice, by a throwaway Python scan and by the shipped Rust, and
the two agree on every one of the five numbers.

The command refuses rather than printing zero when it matches no
modules: a zero from a scanner that found nothing is indistinguishable
from a clean file, and the file's shape is exactly what would change
under it.

4 tests.

WHAT THIS IS NOT. Last pass I named "write real Lean models for those
four" as the only honest way to lower `max_vacuous`, and I am not doing
it. `lean`, `lake` and `elan` are not installed here. A faithful model
may make its theorem FALSE -- the classifier says `Rust=false` for those
specs -- which is the correct outcome and not a bug, but I cannot tell
the correct outcome from a transcription error without building it.
Writing a proof I cannot check and pushing it to see what CI says is the
thing this repository exists to prevent.

Refs #2747
@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-29 21:34:06 UTC

Summary

Status Count
Total Open PRs 8
PRs with Failing Checks 7
PRs with All Checks Green 1
READY 0
FAILING 7
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=f569da0c6c14 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-29 21:35:06 UTC

Summary

Status Count
Total Open PRs 8
PRs with Failing Checks 7
PRs with All Checks Green 1
READY 0
FAILING 7
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=f569da0c6c14 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@gHashTag
gHashTag merged commit 129221e into master Aug 29, 2026
31 of 32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant