How The Wall counts, what it found, what it got wrong, where it bent the rules, and what it cannot do yet.
This page contains no user data, no device records, and no identity information. It describes the audit system. The live audit data is at Public Audit Window.
The Wall maintains a public audit system. It is read-only, contains no user data, no device records, and no identity information. Every visitor sees exactly the same information. The audit system is organized into five sections, each designed to answer a specific question about the system's behavior and integrity.
The audit system is not a marketing surface. It is designed to expose problems, mistakes, deviations, and limitations — not to reassure. An empty corrections log means no corrections have been issued to date. It does not mean no corrections will ever be needed.
The public audit window is divided into five sections. Each serves a distinct accountability function:
This section contains the methodology registry — the rules the system follows when recording and processing signatures. Every methodology has a name, version, status (active, planned, or deprecated), an identifier, a scope declaration (what it applies to), and a plain-language description of the process. When the counting rules change, the methodology version changes.
This section contains audit findings — problems or notable conditions the operator identified and published. Each finding has an identifier, a category, a jurisdiction, a severity level (info, low, medium, high, critical), a status (open, resolved, monitoring), a summary, and a detail record. Findings can include evidence — source documents, excerpts, publisher information, confidence levels, and relevance notes. Each finding has a review history showing when it was logged, reviewed, and updated.
This section contains corrections — mistakes that were made and subsequently fixed. Each correction has an identifier, description, status, and date. An empty corrections section means no corrections have been issued to date.
This section contains exceptions — cases where a published rule was deliberately deviated from. Each exception has an identifier, description, reason, status, and date. Exceptions must be specific, scoped, reasoned, time-bounded, and automatically expiring under the charter. An empty exceptions section means no exceptions have been granted to date.
This section lists the system's current known gaps — limitations declared by the operator. These include items such as the reliance on Cloudflare Turnstile for sign verification (a third-party challenge whose internal evaluation is not fully inspectable), the current state of the correction and exception logs, and other operational limitations.
The methodology registry is also available as a standalone page listing every counting and processing methodology used by The Wall. Each entry describes the rules, constraints, and scope of a specific subsystem.
The registry is not a static document. Methodology entries carry version numbers and status indicators. When the rules change, the version changes. Deprecated methodologies remain visible so that historical counts can be traced to the rules that were in effect when they were recorded.
The methodology registry is available at Methodology Registry.
An audit finding is a published record of a problem or notable condition. Findings are categorized by type and jurisdiction, assigned a severity level, and tracked through a lifecycle of statuses.
Each finding can be expanded to view its full detail record, including evidence. Evidence items include source titles, publishers, excerpts, confidence levels (high, medium, low), relevance notes, and source links where available. Each finding also has a history log showing when it was first logged, reviewed, escalated, or resolved.
Findings are reviewed and published by the operator. They are not user-generated. The audit log contains no user data and no information about individual signers.
The audit system proves integrity through transparency. It does not enforce rules — that is the role of the charter's enforcement mechanisms. It does not conduct investigations — it publishes the results of operator reviews. It does not capture or expose any information about individual participants.
The audit is a disclosure mechanism. Its purpose is to make the system's behavior, limitations, and mistakes visible so that anyone can inspect them. It is not a threshold mechanism, an enforcement envelope, or a gatekeeping layer. It shows what is true. It does not decide what should happen as a result.
The full public audit window with all five sections is at Public Audit Window.
The standalone methodology registry is at Methodology Registry.
To understand the charter that governs the audit system, see Charter Overview.
To understand what The Wall is, see What Is The Wall?.