lin-0271

22.10 Mechanizing the declaration-to-certificate path

The long-term engineering goal is a compiler whose inputs are learning sketches, tangent sites, quotients, covers, and admission contracts, and whose outputs are executable audits and replayable certificates.

A prospective LINCS compiler. Formal verification connects the declaration to generated code; empirical manifests connect the code to the reported evidence.
Figure 22.1 A prospective LINCS compiler. Formal verification connects the declaration to generated code; empirical manifests connect the code to the reported evidence.

The compiler should generate:

  • base, tangent, and declared higher-order factorization tests;

  • localization probes and cover-completeness diagnostics;

  • quotient-invariance checks;

  • typed repair interfaces with effect annotations;

  • blockwise held-out admission tests; and

  • provenance-rich certificates for admission, rejection, or abstention.

Chain-of-Evidence demonstrates that provenance-by-construction can already be made operational for autonomous research artifacts [ Meng et al. , 2026 ] . A LINCS compiler would extend that base audit to tangent evidence chains: certificates that record whether a claim’s support survives registered perturbations of data, seeds, evaluators, ablations, and evidence sources, and localize the first structural failure when it does not.

Proof assistants and typed intermediate representations can verify that generated audits match a formal sketch. Experiment manifests serve a different role: they verify that data, probes, seeds, thresholds, and held-out blocks match the empirical claim. Neither layer replaces the other.

Admission contract

A mechanized repair is admitted only when the generated program is faithful to the declaration and the empirical evidence satisfies the registered contract. Successful compilation proves neither condition by itself.