Riemann Console dot org

An open research record on the Riemann Hypothesis.

NAV READY · TYPE SHORTCUT · ENTER EXECUTES

Verification

A verifiable chain of provenance

Riemann Console is built as a controlled public research record.

Material released here is not simply placed on a website. Governed public objects pass through a publication system designed to preserve where they came from, which exact version was released, when it entered the public record, how it relates to earlier and later versions, and what verification evidence exists for it.

The intended chain is:

CONTROLLED SOURCE → PUBLICATION AUTHORITY → STABLE PUBLIC ID → EXACT CONTENT HASH → RELEASE RECORD → CRYPTOGRAPHIC SIGNATURE → TRUSTED TIME

Not every public object requires every stage of that chain. Educational and explanatory material may rely principally on its controlled source, stable identity, publication record and content-state evidence. High-value scholarly releases can additionally be frozen into release packets, cryptographically signed using the project’s published OpenPGP identity and independently timestamped.

Where an item has not yet been signed or timestamped, Riemann Console records that status explicitly rather than implying evidence that does not exist.

What this protects

Origin. A public object can be traced back to the controlled publication record from which it was released.

Integrity. Exact hashes and frozen release records can identify whether the material being checked is byte-for-byte the same object that was recorded.

Identity. A valid OpenPGP signature can bind an exact frozen release to the project signing identity published by Riemann Console.

Chronology. Independent trusted timestamps can provide evidence that a particular signed or hashed object existed by a recorded time.

Together these mechanisms create a durable evidence trail around the public research record as the programme develops.

They do not establish mathematical truth, novelty, peer review or independent mathematical verification. Those questions remain separate and are stated separately throughout Riemann Console.

What does “verification” mean here?

Verification on Riemann Console is the process of checking that a public item is the particular version the project intended to publish, that the public record has not been silently altered, and—where the relevant evidence exists—that its release records, files, signature or timestamp correspond to that published version.

Verification is about the identity, integrity and provenance of the public record. It is not, by itself, proof that the mathematics is correct, novel or independently reviewed.

What can be checked?

Published content

For an article, milestone or other public item, verification can identify the version that Riemann Console intended to release. The current content-state record identifies the validated public content snapshot being served. For a frozen release, a content release packet can preserve the exact published material and the records needed to identify that version rather than a continually changing draft.

Website code

The website software is a separate object from the research content it displays. Code/build verification identifies the particular deployed website build and its files, including its build manifest. A Drive-authored article can change the validated public-content snapshot without requiring the website software itself to change.

Cryptographic signatures

Where a release has been signed, its cryptographic signature can be checked against the project’s public key. This provides cryptographic evidence that the holder of the corresponding private key signed that exact frozen release. It does not by itself establish mathematical correctness, novelty, independent review, or who made each underlying research contribution.

Trusted timestamps

Where trusted timestamp evidence is present, it provides separate evidence that a particular signed or hashed object existed by the recorded time. Timestamping is therefore a claim about an object and time; it is not a mathematical endorsement and is distinct from signing.

Why are these checks separate?

Each form of evidence answers a different question. A SHA-256 content hash can show that two copies are byte-for-byte identical. A content-state record can identify the validated public snapshot. A build hash can identify deployed website files. A signature can associate an exact release with a signing key. A trusted timestamp can provide evidence about when a signed or hashed object existed.

Keeping these claims separate prevents one kind of evidence from being mistaken for another.

What verification does not establish

Verification on this page does not, by itself, prove the Riemann Hypothesis, establish that a mathematical argument is correct, establish novelty or priority, demonstrate peer review or independent mathematical verification, or determine authorship beyond what the project’s provenance records actually state. Those questions are recorded separately.

Technical terminology

Content snapshot

The validated set of Drive-authored material currently eligible for public display.

SHA-256

The hashing method used by Riemann Console to give a file or collection of files a deterministic digital fingerprint. Matching SHA-256 values are strong evidence that the compared bytes are identical.

Build manifest

A machine-readable list of the files and hashes that identify a particular website build.

Content release packet

A frozen publication package that identifies an exact released article or other content object together with the records needed to preserve its release identity.

Code/build release packet

A separate package used to identify a particular website software build, including its Git commit and build hashes.

Cryptographic signature

Evidence produced with a private signing key and checkable with the corresponding public key. It can show that the holder of that key signed the exact object being verified.

Trusted timestamp

Independent time evidence associated with a particular signed or hashed object, where such evidence has been obtained.

How to use this page

Most visitors do not need to inspect hashes or machine-readable JSON. The human-readable pages state the public status of released material. The technical resources below are provided for readers who want to inspect, compare or independently process the underlying verification records.

Technical verification resources

The links below expose the machine-readable records behind the checks described above. They are provided for readers who want to inspect, compare or independently process the underlying verification data.

Verification resources

  1. [..]Current public content stateValidated public-content snapshot · /content-state.json
  2. [..]Code/build verification metadataDeployed website build · /verification.json
  3. [..]Public build manifestFiles and SHA-256 hashes for the website build · /public-build-manifest.json
  4. [..]Structured public recordsPublic release and provenance records · /public-records.json

Content-state identity is separate from website-build identity: Drive publication may change the validated public-content snapshot without changing the deployed code. For website builds, SHA-256 hashes identify the deployed files and the code/build release packet binds the build-root hash to the relevant Git commit. Cryptographic signing and trusted timestamping are recorded as separate statuses. None of these records, by itself, establishes mathematical correctness, novelty, authorship, signing or trusted time beyond the specific evidence it records.