Review Kit
Bounded-question kit: which expert reviews which claim layer, and the first question to ask them.
How to use this page
The Review Kit is for editors, journalists, podcast hosts, and institutional readers who need to route a claim to an expert reviewer. The pattern is: pick the layer of claim that matters (formalization? physics derivation? life-domain bridge?), find the suggested expert type, and ask them the bounded first question below. That question is one they can answer with their own discipline’s tools — without first learning the entire τ-framework.
This is preparation for review, not a substitute for review. The expert’s answer is what counts. The Review Kit just helps you put the question in front of the right reader.
Expert handoff
All 16 entries from the canonical Expert Handoff layer of the FAQ. Each entry surfaces a candidate expert type and a bounded first question to ask them.<section class="faq-list" data-faq-style="accordion" data-faq-count="16"><div class="faq-accordion-stack">
It depends on the claim. For TauLib, call a formal-methods expert; for kernel hinges, a mathematician; for numerical predictions, a physicist; for scope, a philosopher of science.
No single expert should be asked to judge the whole program at once. Match the expert to the claim layer: formal build, mathematical hinge, physics bridge, prior art, interpretive scope, life-sector adequacy, or impact translation.
Suggested expert types
- Lean/formal-methods reviewer
- Mathematician
- Physicist
- Philosopher of science
- Prior-art specialist
Bounded question to ask first: Which bounded claim layer are you competent to judge?
</details>
Start with the Foundational Hinges route and the three load-bearing clusters: kernel categoricity/rigidity, the Central Theorem, and the τ-internal spectral/RH route.
The mathematical first pass should inspect Books I–III through the hinge routes, not read the entire series. The review asks whether the mathematical spine is nontrivial, correctly scoped, and dependent only on disclosed assumptions.
Suggested expert types
- Category theorist
- Model theorist/logician
- Analytic number theorist
- Operator theorist
- Algebraic geometer
Bounded question to ask first: Are the hinge claims meaningful and strong enough under disclosed assumptions?
</details>
Start with whether ι_τ is forced or fitted, then inspect prediction timing, the calibration cascade, and the falsification pack.
Physics review should focus first on the empirical track: master constant, prediction catalogue, calibration cascade, timing categories, and falsification tests. Do not start with metaphysics.
Suggested expert types
- Particle physicist
- Cosmologist
- Precision-measurement physicist
- GR specialist
Bounded question to ask first: Is ι_τ forced before calibration, and are prediction categories honest?
</details>
Reproduce the pinned TauLib build, scan for `sorry` and `axiom`, inspect the custom axiom inventory, and run `#print axioms` on selected hinge theorems.
Formal-methods review begins with source, manifest, trust budget, and audit commands. The goal is to determine whether the formalization claims reproduce and whether public prose accurately describes the Lean code.
Suggested expert types
- Lean 4 expert
- Mathlib expert
- Proof assistant auditor
- Research software engineer
Bounded question to ask first: Does the pinned build reproduce with the stated axiom/sorry/TCB state?
</details>
Test whether claimed differences survive translation into neighboring vocabularies, especially τ-holomorphy, spectral ζ, generation physics, life theories, and no-dark-sector programs.
Prior-art review asks whether novelty survives direct comparison. Compare τ claims against established neighboring programs and test for relabeling, rediscovery, or genuine structural difference.
Suggested expert types
- Quaternionic/Clifford analysis specialist
- Hilbert-Pólya/Connes/Berry-Keating specialist
- Particle-theory prior-art specialist
- Formal biology/consciousness specialist
- Modified gravity specialist
Bounded question to ask first: After translation into closest prior vocabulary, is there substantive novelty or relabeling?
</details>
Inspect whether the framework earns its language, keeps status levels separate, and avoids turning definitions into disguised conclusions.
Philosophical review asks conceptual discipline: are formal, empirical, bridge, interpretive, and ontic claims separated? Are terms such as reality, observer, life, mind, and value earned rather than smuggled in?
Suggested expert types
- Philosopher of science
- Metaphysician
- Philosopher of mind
- Philosopher of mathematics
- Ethics specialist
Bounded question to ask first: Are interpretive claims explanatory rather than merely definitional?
</details>
Inspect whether life-sector claims connect to observable biological constraints rather than becoming true only inside τ vocabulary.
Life-science review should ask whether the framework explains biological structure or merely redescribes it. The reviewer should test bridgeability to theoretical biology, origin-of-life, astrobiology, and systems biology criteria.
Suggested expert types
- Theoretical biologist
- Systems biologist
- Origin-of-life researcher
- Astrobiologist
- Philosopher of biology
Bounded question to ask first: Does the τ-life criterion explain biological constraints or redefine life too broadly?
</details>
Inspect the dependency chain: upstream Results, translation assumptions, domain validation, benchmark metrics, governance risks, and what is not yet deployment-ready.
Impact claims are conditional downstream scenarios, not product claims. Reviewers should trace the chain from upstream τ result to domain translation to pilot benchmark to governance condition.
Suggested expert types
- Policy expert
- Public-good program evaluator
- Domain scientist
- Research impact evaluator
- Governance specialist
Bounded question to ask first: Does the dossier identify upstream τ dependencies and missing translation work clearly?
</details>
Inspect whether the Release Manifest, TauLib source, Registry counts, website counts, release notes, and archived artifacts agree under documented filter rules.
Reproducibility is not only `lake build`. It includes source provenance, counts, manifest-driven metrics, release notes, archived artifacts, and correction behavior.
Suggested expert types
- Open-science reviewer
- Research software engineer
- Release engineer
- Data provenance specialist
Bounded question to ask first: Can a third party reproduce the build and reconcile all metrics from one manifest?
</details>
Ask a bounded question: “Does this specific claim layer hold up, and what would count as a failure?”
Editors should avoid broad reaction quotes. A good question names the artifact, layer, and failure condition: formal build, hinge theorem, prediction independence, prior-art novelty, interpretive coherence, or impact translation.
Suggested expert types
- Any domain expert matched to the claim layer
Bounded question to ask first: Which specific artifact did you inspect, and what is your confidence about that layer only?
</details>
A useful answer names the layer inspected, the artifact checked, the specific objection or support, and the remaining uncertainty.
A useful answer is bounded and traceable. It identifies exactly what was inspected and what the comment supports or challenges. Praise or dismissal without artifact and layer is weak evidence.
Suggested expert types
- Any external expert
Bounded question to ask first: Which public artifact did you inspect, and what exactly does your comment support or challenge?
</details>
Send the Foundational Hinges page, the relevant hinge paper, the Mathematician Route, the Release Manifest, and linked Registry/TauLib anchors.
Do not send only the homepage or the full monograph series. Send a bounded packet around the specific hinge under review, with formalization status and dependency anchors.
Suggested expert types
- Mathematician matched to hinge
Bounded question to ask first: Does this hinge theorem provide real mathematical content under disclosed assumptions?
</details>
Send the Master Constant H3 page and paper, the Physicist Route, Prediction Timing, Calibration Cascade, and Falsification Pack.
A physics packet should focus on empirical and numerical claims, not the whole metaphysical program. The bounded question is whether the ledger is structurally forced, independently generated, honestly timed, and testable.
Suggested expert types
- Particle physicist
- Cosmologist
- Precision-measurement physicist
Bounded question to ask first: Is the master constant forced before calibration, and are prediction categories honest?
</details>
Send the Release Manifest, TauLib source, Formal Methods Route, TCB Disclosure, Custom Axiom Inventory, and Formal Verification Stack.
A formal-methods packet needs source, manifest, trust budget, and audit instructions. It should include the specific theorem or module if reviewing a particular claim.
Suggested expert types
- Lean 4 / Mathlib reviewer
- Proof assistant expert
- Research software engineer
Bounded question to ask first: Can you reproduce the pinned build and verify the axiom/sorry/trust-budget state?
</details>
Report the disputed layer: research form, formalization, mathematics, prior art, physics bridge, empirical prediction, interpretation, or impact translation.
A good article names the expert’s domain, artifact inspected, layer being judged, support or objection, and remaining uncertainty. Do not flatten layered disagreement into a single verdict.
Suggested expert types
- Any domain expert
Bounded question to ask first: Which layer are you disagreeing with, and what artifact did you inspect?
</details>
A review changes status only if it is specific, documented, artifact-linked, and bounded to a claim layer or dependency chain.
Informal praise or dismissal is not enough. A status-changing review identifies the artifact, specialist competence, exact claim layer, method of inspection, and resulting judgment; it should be citable and incorporable into status labels, errata, or Release Manifest notes.
Suggested expert types
- Formal-methods reviewer
- Domain specialist
- Prior-art specialist
- Reproducibility reviewer
Bounded question to ask first: Is this review specific enough to update a status label, erratum, or manifest note?
</details></div></section>
Technical credibility (selected)
Subset of Technical Credibility FAQ entries that pair with expert handoff: what TauLib actually proves, the role of sorry and custom axioms, the trust budget, and what’s currently bridge-pending.
What does “machine-checked in Lean” mean here?
It means encoded formal statements compile under the pinned Lean environment, relative to Lean’s trusted kernel, disclosed assumptions, and current TauLib snapshot.
Machine-checked does not mean every prose claim is verified. It means the Lean-encoded theorem or obligation is accepted by the proof checker under the disclosed environment and trust budget.
Does TauLib prove the physical claims?
No. TauLib verifies formal obligations where encoded; it does not by itself prove empirical truth, bridge adequacy, semantic correspondence, or external scientific acceptance.
Lean can check encoded derivations. It cannot by compilation alone prove that a τ-internal object corresponds to a physical observable, that a measurement bridge is adequate, or that a numerical match validates the framework.
Does 0 `sorry` mean the theory is true?
No. It means the formalized Lean proofs have no explicit unfinished-proof placeholders; it does not settle bridge, semantic, empirical, or external-review questions.
A 0-sorry Lean development is stronger than one with placeholder proofs, but it is not a truth certificate for the whole research program. The encoded statements, correspondence to prose, bridge claims, and domain claims remain separate burdens.
What does “compute-then-axiomatize” mean?
It means a universal claim is finite-checked over an explicit computable envelope, but the unbounded universal step is still declared as an axiom rather than proved.
This pattern is explicit debt, not proof. It is acceptable only if named, bounded, reproducible, load-bearing, and reflected in downstream scope labels.
What is the trusted computing base?
The trusted computing base is the underlying machinery a Lean proof depends on: Lean’s kernel, standard axioms, and any disclosed extensions such as `native_decide`.
No proof assistant verifies itself from nothing. The question is whether the trust base is disclosed, bounded, and auditable. TauLib’s TCB page names the Lean baseline and native computation costs.
What is the difference between the Registry and TauLib?
The Registry is the object/dependency map of the Corpus; TauLib is the Lean formalization projection of selected formal content.
A registry object is a stable public ID for a Corpus item. A TauLib module is a Lean source file. The meaningful audit question is whether claimed mappings between Registry, Corpus, and TauLib are explicit and inspectable.
Does every Result page have a Lean proof?
No. Results are consequence surfaces with status labels; some have formal support, some are bridge claims, some are empirical, and some remain interpretive or domain-level.
A Result page is not automatically a Lean theorem. The right question is status, Corpus support, formalized component, bridge burden, and external validation route.
What remains bridge-pending?
Any claim that transfers from τ-internal formal structure to standard mathematics, physics, biology, metaphysics, measurement, or public impact needs a separate bridge check.
Bridge adequacy asks whether a τ-internal construction legitimately transfers to the external target. The site should keep internal proof, bridge claim, and domain validation visibly separate.
Open all reviewer FAQs in the canonical directory →
All 20 Technical Credibility entries →
Adjacent surfaces
- How to Verify by Reviewer Role — per-role inspection routes (mathematician, physicist, life-sciences reviewer, philosopher, formal-methods reviewer)
- Assessment Protocols — manual + LLM-assisted protocols for structured critique
- Custom Axioms and TCB Disclosure — the trust budget that scopes any formal-methods review
- TauLib — the Lean 4 formalization surface
Source-of-truth discipline
The Corpus owns the FAQ entities. The website renders FAQ projections.
Every entry above is mirrored from corpus/faqs/expert_handoff.yml and corpus/faqs/technical_credibility.yml. Edits land in the corpus repo first, then sync into this site. Each entry has a stable ID (FAQ-EH-###, FAQ-TC-###) that you can cite directly when corresponding with an expert.
Contact
- Press / interview routing: [email protected]
- Structured review / technical inspection: [email protected]
- Errata & corrections: [email protected]
Save or share this page for inspection
Download a portable dossier, copy a reviewer note, or send this page to someone who can inspect it.