01Three readings of one claim
Every formalized claim is described three times, by three fallible sources:
Blueprint \leanok
What the author claims is
formalized. A manual flag (even LeanArchitect's auto-flag is only direct, not
transitive). checkdecls never checks the kernel.
Commit Status:
What the git history recorded, over time. Append-only, and it can overclaim.
#print axioms
Kernel reality:
clean / sorryAx / axiom, read by
axiom-report. Ground truth, but silent on intent and history.
CKC unifies a claim's blueprint \label, its Lean FQN(s), and its registry slug onto
one node, attaches the three readings, computes the transitive effective status,
and classifies the agreement.
02The discrepancy taxonomy
The two categories in red are gaps a green blueprint graph hides:
consistent all three agree; effectively machine-checked kernel-refutes-claim claimed/recorded proved, but the kernel says sorryAx / axiom effective-gap itself clean & claimed proved, but a DEPENDENCY is a hole undocumented kernel-clean & blueprint-proved, but no commit recorded it stale-blueprint commit + kernel proved, but not marked \leanok paper-only no Lean yet: a paper-level statement
The headline is effective-gap: a node green in the blueprint and clean
in its own #print axioms, but transitively resting on an unproved step. Blueprint
green does not propagate; CKC's effective status does.
03Reconciled, live
The paper-igl formalization, reconciled across all three sources. Node colour is effective status; a red double ring marks a discrepancy. Click a claim to see its blueprint / history / kernel / effective readings.