Three-party verification
From the documentation of the field
Lean verifies Ismail. Ismail verifies the application. The client verifies that those two say the same thing.
The three links answer three different questions, and each link is carried out by a different party.
| Link | What it verifies | What it leaves to the next link |
|---|---|---|
| Lean verifies Ismail | That each theorem follows from its definitions and from Mathlib's axioms | Whether and how the work applies to a particular structure, which the application addresses |
| Ismail verifies the application | That an application of the work uses the definitions, the theorems and the standard the way the mathematics requires | Whether the application, once carried out, agrees with what the mathematics requires in the client's own situation |
| The client verifies that those two say the same thing | That what was done in the client's situation matches what the mathematics and the standard require: where the primitives of Ismail's Primitives were applied, in what capacity, and what the output was | Nothing further. The mathematics is checked, and the application has been approved |
No link carries the whole chain. Each covers what the others do not.
The final check
The third link is a post-engagement deconstruction. It uses the work as a measurement. After an engagement ends, a qualified evaluator takes it apart and establishes three things. The first is where each primitive of Ismail's Primitives was applied. The second is in what capacity, meaning which mechanism operated, over what scope and for how long. The third is what the output was. The evaluator then measures the effect in the client's situation, against the published criteria.
This is an empirical measure. It is made by examining what actually happened in a particular situation, and it is separate from the mathematics, which is already checked. It does not ask the client to read Lean or to judge a proof. It does not turn the necessity theorems into predictions or claim sufficiency, and its result is empirical evidence about what the application did. It sits outside the machine-verified mathematics.
The client's situation is the ground for this check because it is where the application took place and where its output and effect can be observed. In that sense the client verifies. The client does so by having the engagement evaluated, and by being the source of the evidence the evaluation rests on, and does not do so by checking the mathematics.
Who performs each link
No link depends on one person. The first is performed by the Lean kernel, which anyone can run. The second is performed by an approver, and the third by an evaluator. Each holds the role on proof, as the competence page sets out: trackable artefacts at the type and depth listed there, and not a credential, an institutional affiliation or a referral.
In the fixed wording above, the approver is Ismail, who founded the field and holds the role on the strength of the artefacts listed on the author page. Any person who shows the capability, in artefacts of the same type and at the same depth, can hold the approving role or the evaluating role. The evaluator is not the person who approved the application being evaluated. The evaluator need not be the client, and the client can commission one.
The field is built to continue without any one person, including its founder. Without proof at the stated depth, an approval or an evaluation would mean nothing, because the results it applies are impossibility theorems and the roles are what stand between a missing capability and a pass.
What the evaluation can find
The four errors in error theory are each findable by deconstructing an engagement. A misclassification or a misidentified mechanism shows up when the evaluator compares what was said to be present with what operated. A sample that left out inconvenient cases shows up when the evaluator reconstructs which cases existed. A verdict that says more than necessity shows up when the evaluator sets its wording against the verdict type.
| The field | |
|---|---|
| Pages | The QuestionField definitionClass CWhy a POMDPNecessity and sufficiencyVerification tiersAudit it yourselfMethodologiesCompetenceError theoryThree-party verificationAdjacent fields |