Methodology

How a record earns its place.

How to propose a result, how Claims get accepted, what verification tiers mean, and how a Claim earns a signed certificate.

What belongs in the Registry

A Limit is a permanent Registry ID attached to a versioned specification — the exact formal question, its constraints, and whether the goal is a maximum or a minimum. A Claim asserts something against that specification: an upper bound, a lower bound, an exact value, a construction, a counterexample, or an asymptotic or computational bound. Nothing is published as a Claim until it names a specific relation (<, ≤, =, ≥, >) and a value.

Status meanings

Statuses describe the Registry’s editorial state, not the importance of a result or the strength of a paper’s reputation.

Limit status

DRAFT: Internal working record. It is not part of the public registry frontier.
OPEN: Public and source-backed, but the frontier is not fully closed. It may have bounds, approximations, or measurements without a settled exact optimum.
PROVEN: The precise recorded statement is formally established for its specification, typically by matching bounds, an exact theorem, or an impossibility result.
DISPUTED: A published record or Claim has a substantive unresolved challenge. It remains visible, but readers should not treat it as settled.
RETIRED: No longer an active frontier in the Registry, usually because it was superseded, scoped out, or replaced. Its history remains available.

Claim review status

DRAFT: Prepared but not yet submitted for editorial review.
UNDER REVIEW: Submitted and currently being checked against its specification and evidence.
ACCEPTED: Approved Claim that may contribute to a published frontier.
REJECTED: Reviewed and not accepted in its current form.
DISPUTED: A published Claim has an unresolved substantive challenge.
INVALIDATED: Later evidence or review found that the Claim does not hold under its recorded scope.

A record can be OPEN even when individual Claims are proven: a one-sided bound or a measurement does not by itself close the full frontier.

Evidence and verification tiers

Every Claim needs Evidence — a paper, a formal proof, source code, an exhaustive computation, an experiment, a reproduction, a dataset, or a direct observation. Evidence carries one of four verification levels, and a Claim is only as strong as its weakest linked Evidence:

Reported — the source’s own stated result, not yet independently checked.
Source-confirmed — checked directly against the original paper, proof, or dataset.
Independently reproduced — a separate party reran the construction or experiment and got the same result.
Machine-checked — a formal proof artifact in Lean 4, Coq, Isabelle, or a SAT solver, tied to a real 40-character commit hash and verified to build.

How to apply

Anyone with an account can propose a change to a published Limit from /submit:

Sign in — create an account if you don’t have one.
Pick the Limit and what you’re proposing: a better achievable result, a stronger proven bound, a proof, an independent reproduction, or a correction.
Describe the proposal, and where relevant, the proposed relation and value.
Attach an evidence URL — a paper, proof, or repository — wherever possible.
Submit. It enters the queue as submitted; nothing publishes automatically.

Your own submissions stay visible on the same page as their status moves to under review, then accepted, rejected, or needs revision with a reviewer note.

How we decide

A Claim only becomes accepted once its scope is explicit against the current specification, at least one piece of Evidence is attached, and independent editorial review is recorded. Claims that are later disputed or invalidated stay visible as history rather than disappearing — the Registry doesn’t silently overwrite a published record.

Certification

An accepted Claim can be issued an integrity certificate once it has Evidence and has cleared independent review.

Exact rule: a certificate requires at least one linked piece of Evidence and two accepted independent reviews. Fewer than that, and no certificate can be issued.

Issuing a certificate takes an immutable snapshot of the Claim, its specification version, and its evidence, hashes it with SHA-256, and — where the issuer key is available — signs it with Ed25519. The result is a public, permanent record at /certificates/CERT-<claim number>, downloadable as a PDF, that anyone can use to verify the Claim hasn’t changed since it was certified.

Status badges

Every published record exposes an embeddable status badge at /api/badge/{registryNumber}, colored by whether it’s proven, disputed, or open — for citing a Limit’s current state from outside the Registry.

What stays fixed

Three things the Registry won’t do, by design: render a draft or nonexistent record as if it were published; silently overwrite a disputed or invalidated Claim instead of keeping it in the visible history; or issue a machine-checked verification without a real, resolvable commit hash behind it.

Corrections

Submit a correction through /submit with the relevant Registry ID, source, and precise proposed change — it goes through the same review queue as any other proposal. For anything you’d rather not post publicly first, email support@limitsregistry.com.