The situation
Real-time election data at institutional scale
Stears Election Centre was the company's highest-profile product, functioning as a high-fidelity data engine. The business was building its data infrastructure toward the 2023 presidential election while actively covering state elections live across 2021 and 2022: Anambra in November 2021, and both Ekiti and Osun in 2022. Luminate/Omidyar Group, the programme funder of the African Elections Monitor through their Data for Storytelling Programme, served as our primary institutional partner throughout this period.
I led the Stears Data Production (SDP) team as the data production lead across these high-visibility operations. Across the three governorship elections, our data pipeline ingested, verified, and structured data for 11,928 polling units organised across 67 LGAs and 835 wards:
- Anambra 2021: 5,720 polling units, 21 LGAs, 326 wards, and 18 competing political parties.
- Ekiti 2022: 2,445 polling units, 16 LGAs, 177 wards, and 16 active candidates.
- Osun 2022: 3,763 polling units, 30 LGAs, 332 wards, and 15 competing parties.
Every live deployment operated under a hard deadline: whatever infrastructure and data-validation pathways were functional on voting day determined the quality of the public deployment. Building and scaling this data architecture while operating it in production meant there was no staging environment or post-event iteration cycle. Every structural decision had to execute flawlessly from the first poll closure.
The constraint
Two conflicting live data streams. No margin for error.
Electoral data streams in Nigeria do not arrive as a single, clean, or centralised signal. Instead, raw fragments flow asynchronously upward through a strict geopolitical hierarchy: from individual polling units to localised wards, up to local government collection centres, and finally to state headquarters before the Independent National Electoral Commission (INEC) officially declares them.
My production team was forced to monitor two live data streams simultaneously:
- The INEC IReV Portal: A digital stream publishing raw, polling unit-level image sheets in real time.
- Live Television Coverage: Real-time broadcasts of official INEC press conferences announcing state-level declared results.
These twin streams operated at fundamentally different latencies, velocities, and verification states. During the critical hours of the vote count, they frequently produced conflicting numbers for the exact same regional result.
For a premium data intelligence firm serving institutional clients, publishing data directly from either stream without systematic reconciliation introduced an acute operational hazard: the risk of accidentally asserting an unverified projection before it was officially certified. In a hyper-volatile political ecosystem, the cost of being perceived as inaccurate is catastrophic, instantly destroying the institutional credibility of every downstream analysis the company produces.
"The software stack changes; the core operational architecture does not."
[IReV Portal] ──►┌
├──► [Reconciliation] ──► [Source Tag] ──► [Publish]
[Live TV] ──►┘ │
└──► (Provisional | Confirmed)
// election data flow — source reconciliation protocol
What was built
Four structural decisions that held under live pressure.
I designed and deployed the operational pipeline for the data production process, establishing a strict, linear blueprint for data routing: defining which data nodes entered which quality gates, the precise sequence of verifications, which analyst owned the review, and the automated trigger for publication. The architecture decentralised operational accountability across functional roles rather than concentrating risk within a single manager — making individual human continuity irrelevant to system reliability.
Mid-operation, I engineered a structured data-attribution protocol to mitigate data variance risks arising from our twin ingestion streams. I mandated that all incoming data points be explicitly partitioned by source and verification tier: splitting rapid, provisional polling unit data (IReV) from slow, authoritative, officially declared INEC results. Both our institutional data feeds and client-facing editorial dashboards reflected this status layout. Under source status labelling as our primary data quality standard, none of our defined error modes (label corruption, status escalation, data reversals) occurred across all three election cycles.
I established rigid validation steps at every critical handoff point throughout the data journey, ensuring human entry errors were captured and isolated before they reached publication. Data nodes were programmatically blocked from advancing through the production chain until the specific review criteria for that stage cleared. By embedding quality gates at every distinct handoff rather than a single macro-review, we evenly distributed the review burden across the team and isolated failure modes at the exact workflow stage where they originated.
To transition technical gates into repeatable human routines under real-time pressure, I codified the entire cross-functional coordination process into an exhaustive operational runbook. This playbook explicitly mapped data sourcing sequences, multi-tier verification steps, publication checklist gates, and formal client communication procedures for every election type. The runbook specifically detailed multi-day operational continuity protocols — defining the exact validation steps an incoming analyst had to execute before taking ownership of an active data stream. What existed in the runbook on voting day was exactly what executed on the production floor.
Why I built it this way
The decisions that shaped the architecture.
Why source labelling rather than maximum publication speed?
The path of least resistance would have been to stream any available numbers with minimal metadata. However, institutional clients making high-stakes decisions do not need raw data speed; they require context to weigh reliability. Polling unit tallies and state-declared totals are fundamentally different assets with different risk profiles. Transforming the source label into a mandatory gate protected our brand equity — and by extension, the trust of every institutional client depending on our data.
Why a workflow architecture rather than individual accountability?
In a live election environment, escalating complex judgment calls to a single executive under real-time pressure introduces an unacceptable single point of failure. The production workflow had to be engineered so that clean data processing was the un-bypassable default, ensuring data integrity held regardless of an individual manager's presence or attention. Distributed quality control into the process layout rather than relying on individual vigilance.
Why quality gates at specific handoffs rather than end-to-end review?
Macro-reviews at the end of a pipeline create immense administrative friction and delay publication. By embedding quality gates at every distinct handoff, we evenly distributed the review burden across the team. This localised our failure modes: if an anomaly occurred, the system caught and resolved it at the exact workflow stage where it originated, preventing data pollution from propagating downstream.
Why enforce a single reconciled source rather than multi-source publication?
Because the real-time IReV digital stream and live television broadcasts moved at different latencies, streaming both simultaneously would have introduced blatant internal contradictions into Stears' public data. Metrics would fluctuate not because votes were moving, but because the underlying source data was out of sync. Establishing a single source-of-truth gate ensured absolute internal data consistency across all client touchpoints.
The result
Zero errors across three elections. Full operational continuity.
Our operational architecture achieved zero data production errors across the continuous multi-day coverage of the 2021–2022 state elections. The deployment yielded no mispublished results, no corrupted source labels, and zero post-publication data reversals.
Over 11,928 distinct polling units were monitored and ingested across multi-day counts and overnight shift transitions, fully validating the resilience of our production runbook. Our systematic delivery successfully met the data requirements of Luminate/Omidyar Group, our core institutional partner.
The structural frameworks engineered during this project transfer directly to any enterprise data environment: managing multi-source data calculations, implementing rigorous gate logic at every critical handoff, and authoring durable playbooks that survive the individual operators running them. The software stack changes; the core operational architecture does not.
What I'd do differently
The version I'd build with what I know now.
I would establish the source attribution protocol as a pre-production governance document. The framework dividing data into provisional and confirmed tiers was architected mid-operation, once live data variance risks manifested on-screen. This logic should have been codified into a formal, cross-functional governance brief signed off by all stakeholders prior to the first poll opening, rather than implemented as an agile midstream adjustment.
I would formally document the workflow architecture as a handover document before the peak period. While the production pipeline functioned perfectly, the underlying workflow logic was initially maintained by close supervision. Formally documenting and mapping the entire system layout prior to the live election window would have significantly minimised key-person dependency during early phases of the project.
I would build a near-miss audit trail alongside the gating structure. Our validation gates successfully intercepted errors at every handoff, but the system failed to record those interceptions. Constructing a structured "near-miss" ledger to log data anomalies that almost bypassed a gate would have generated objective data to optimise our next infrastructure build and provide measurable proof of the system's internal ROI.