Verify Verification Surface Canonical Structured pathways for holding the program accountable to its stated standards.
Verification SurfaceCanonical

Assessment Protocols

Structured pathways for holding the program accountable to its stated standards.

Public
Manual protocols
Human-readable review procedures for inspecting the program.
LLM-assisted protocols
Structured prompts for generating first-pass audit dossiers from public materials.
Protocol boundary
Assessment protocols are triage and review tools, not substitutes for proof or peer review.

What These Protocols Do

These protocols are designed for reviewers, readers, and external evaluators. They provide explicit checklists and prompts for structured scrutiny.

For human bounded review offers, critique, correction, or contribution, use Engage → Review the Work. For lighter first-contact prompts, use Discover → AI-Assisted Discovery. For assessment workflows, stay here.

Assessment inside the verification matrix

Scientific plate titled The Verification Matrix, showing obligations, construction steps, and results flowing into Verify, with six verification layers, operational surfaces such as TauLib and Release Manifest, a verification status legend, and the caveat that formal checking is not empirical truth.
Assessment Protocols are external-review routes inside the broader verification matrix. They help structure scrutiny, but they do not replace proof, empirical testing, or peer review.

↓ Download print master · 1536 × 864 JPG · CC BY 4.0

Assessment begins after the relevant obligation, construction step, result, and verification mode have been identified.

Protocols help reviewers decide where to inspect next: Agenda obligations, Corpus construction, Results status, TauLib formalization, bridge assumptions, or falsification surfaces.

Existing Detailed Library

The detailed assessment library remains available at AI-Assisted First-Pass Assessment, including methodology, rubric, scorecard, dossier schema, structured inspection workflow, and prompt templates.

Package inspection checklists

Assessment protocols are triage and review tools, not substitutes for proof, empirical testing, peer review, or external acceptance. Use these package checklists as bounded entry points, then follow the relevant Corpus, Results, Verify, and Engage routes.

Package 1 — Inspection Architecture

Use this checklist to inspect the public burden of a high-scope open research program. For the citable artifact, see Inspection Architecture for High-Scope Open Research.

  1. Is the scope and burden of proof explicit?
  2. Are source policies visible?
  3. Are accepted obligations visible before results?
  4. Is there a Corpus / construction route?
  5. Are Results status-marked?
  6. Are verification routes visible?
  7. Are correction and errata routes public?
  8. Are externalities and unresolved boundaries disclosed?

Package 2 — Theory of Reality

Use this checklist to inspect the conceptual category. For the citable artifact, see The Shape of a Theory of Reality.

  1. Does the program distinguish coherent theory of reality from “theory of everything” rhetoric?
  2. Is the canonical claim stated as a building burden rather than a completion claim?
  3. Are Program doctrine, Agenda obligations, Corpus construction, Results consequences, Verify inspection, Impact conditionality, and Engage scrutiny kept distinct?
  4. Are core terms such as reality, proof, observer, life, mind, value, and public good earned rather than borrowed?
  5. Are accepted questions visible before answers are evaluated?
  6. Can a result be traced from Agenda obligation to Corpus construction to Verify route?
  7. Are internal status, formal verification, empirical support, external review, and external acceptance separated?
  8. Are bridge claims and translation assumptions visible?
  9. Are no-externalities and unresolved-frontier boundaries disclosed?
  10. Does Impact use conditional relevance rather than adoption, deployment, or delivery language?
  11. Does Related Approaches function as a positioning map rather than a dismissal?
  12. Does Engage make scrutiny possible without implying endorsement?

Package 3 — Public Research Observatory

Use this checklist to inspect the technical public interface. For the citable artifact, see Building a Public Research Observatory for High-Scope Open Research.

  1. Does the homepage state the research category without overclaiming completion?
  2. Can a first-time reader move from Discover into Program, Agenda, Corpus, Results, Verify, Impact, and Engage?
  3. Does Program own identity, doctrine, scope, status, and scrutiny posture?
  4. Does Agenda state obligations before answer claims?
  5. Does Corpus expose construction, monographs, registry objects, TauLib projection, and dependency routes?
  6. Do Results separate consequence/status from verification and external acceptance?
  7. Does Verify expose formal checks, bridge checks, predictions, falsification, release manifest, and assessment protocols?
  8. Does Publications keep stable artifacts separate from live Corpus exposition?
  9. Does Impact remain conditional rather than claiming adoption or delivery?
  10. Does Engage provide critique, correction, contribution, and discussion routes without implying endorsement?
  11. Are dynamic public metrics pinned to the Release Manifest rather than hand-owned prose?
  12. Are publication PDFs accompanied by manifest hashes and DOI posture?
  13. Does search help readers find source, status, verification, and artifact routes?
  14. Are compatibility routes, redirects, and legacy labels handled intentionally?
  15. Is the architecture honest about what it cannot prove?

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.

Email to expert