How the data is built.

The datasets

The dashboard is built from three datasets, all compiled by the research team from primary court records.

The Election Petitions Tribunal database. More than 3,300 election petitions, drawn from six general-election cycles between 2003 and 2023. It covers all 36 states and the Federal Capital Territory, and every elective office from the governorship to the State House of Assembly. Each petition is one row. Paper records were obtained by request from the courts and electoral authorities, then catalogued and scanned for analysis. Nigeria has no central digital archive of these judgments, so assembling and linking the records is itself a substantial part of the work.

The Judicial Register. A register of more than 550 judges who have sat on election tribunals across these cycles, recording for each the court served, the cases over which they presided, their state of service, and, where it could be confirmed, their gender.

The Electoral Act. Key provisions from five gazetted versions of the Electoral Act, over a 24-year span.

The datasets are actively expanded and updated periodically.

How a case is coded

Each case is read and coded against a detailed codebook by a team of trained Nigerian lawyers. The codebook records more than one hundred fields per case; the dashboard publishes a descriptive subset of these, including the office contested, the election cycle, the grounds pleaded, the panel that sat, the length of the judgment, and the outcome. For a small number of high-impact cases, the full judgment is provided alongside a short summary.

1. Code independently. Two trained coders are assigned the same case and code every field separately, in blind, rotating pairs, so that no two coders are always matched and neither knows who else is reading the same decision.
2. Compare. The two codings are placed side by side and every divergence is identified.
3. Adjudicate. Differences are resolved before the case enters the dataset — a partial review for minor gaps, a full re-reading by the project director and coding coordinator where they are larger.

The team meets weekly to work through difficult cases, and the project director writes adjudication memos that formalise recurring judgment calls so that coding stays uniform across the team.

The data schema

Every chart on the dashboard is a view onto the same underlying record. These are its core public fields.

The full research codebook records far more than these fields. The dashboard surfaces this descriptive set; the analytical variables remain in the research dataset. Cycle, office, and state are known for every catalogued petition, while grounds, outcome, length, and panel are shown for cases that have completed coding and adjudication — currently around 250, with more added each cycle.

Verification

No figure rests on a single reading, and each dataset is checked in the way its sources require.

The petitions are coded twice, independently, and every difference is adjudicated before a case enters the dataset. The counts on the dashboard are the totals of those cases.

The judicial register is checked from both ends. It begins with records from the Court of Appeal, the office that assigns tribunal judges, and each judge is then matched back against the judgments in our own record to confirm that they sat. Details such as the court served and gender are drawn from court records, newspaper reporting, and direct enquiries to the state high courts. Where a detail could not be confirmed, the register marks it "Not Stated" rather than guess.

The Electoral Act tracker is built from the gazetted text of each Act, with provisions compared across versions by the full team.