BandCheck

Agents run the whole lifecycle. One person approves the outcome, on one evidence card.

Comment

Demo video

https://vimeo.com/1239817750 · Live app: https://bandcheck-ttjc6ovgnq-ew.a.run.app · Repo: https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/13655157/bandcheck

The problem, for one person

Picture a household in Lagos on a Band A feeder. Under Nigeria's service-based tariff, Band A is the premium tier: customers pay the highest rate in return for a promised minimum of 20 hours of supply a day. One week, the lights are on for about 14 hours a day. The bill still says Band A. The customer has no record of the hours they actually got, no way to prove the shortfall to anyone, and no idea what the regulator's rules entitle them to. Their only evidence is memory, and a neighbour's memory. The same is true of a small business owner who runs a generator for the missing six hours a day, and pays for diesel on top of a premium tariff.

The problem, for organisations

  • Distribution companies (DisCos) say they meet bands; customers say they do not; neither side has a shared, neutral record at the level that matters, the individual feeder.
  • The regulator (NERC, and in Lagos since December 2024 the state regulator LASERC) sets precise rules: feeders that fall below the promised hours are downgraded, and customers are entitled to compensation. For example, NERC Directive No. NERC/2026/002 orders special compensation for Band A customers on feeders averaging below 18 hours (20% of the feeder's approved February 2026 energy cap for non-MD customers) and keeps their Band A classification during the covered period (Nairametrics, 4 June 2026). Rules like that only help people who can show which feeder fell short, and by how much.
  • Consumer groups and journalists can describe the problem, but cannot quantify it feeder by feeder.

The problem, for everyone

Any service sold on a measurable promise (hours of power, uptime, delivery times) has the same gap: the provider measures, the customer guesses. And on the software side the matching gap is "what happens after the code is written": someone still has to review, scan, release, watch production and be accountable for saying yes. Code generation is largely solved; accountable delivery is not.

The economic impact

The cost of a missed promise is concrete and easy to compute:

  • A Band A customer who receives 14 hours instead of 20 pays for 20 and gets 70% of it: the price per hour actually supplied is about 43% higher than the band promises (20 / 14 = 1.43).
  • Reported Band A rates have been in the N206.80 to N225 per kWh range since the April 2024 tariff change (Gazette; Marketforces). Illustration: if a feeder's approved monthly energy cap were 400 kWh, the NERC/2026/002 compensation of 20% would be 80 kWh, about N16,500 to N18,000 per customer per month at those rates. Multiply by every customer on a feeder and the size of the claim, and of the dispute, is obvious.
  • Customers on a shortfall also buy substitute power. A generator hour costs far more than a grid hour, so every unreported missed hour is a hidden cost borne by households and small businesses.
  • Evidence reduces that cost for everyone: customers can claim what they are owed, DisCos can see which feeders actually underperform, and the regulator can enforce on data instead of anecdotes.

Our solution

BandCheck tells Nigerian electricity customers, feeder by feeder, whether they got the hours their tariff band promises. Neighbours tap "Light came" or "Light went"; BandCheck turns the reports into hours of supply per area and applies the regulator's own rules: an explanation after 2 failed Band A days, a downgrade after 7, compensation below 90% of the band, with each rule citing its order and page. It shows which band the supply really matches, how many hours the customer was short, and turns a proven breach into a complaint they can send. Unreported time is never counted against the DisCo, so every number is conservative: it can only understate a shortfall. Lagos feeders say they now fall under LASERC. A labelled synthetic demo feeder lets anyone see a verdict immediately. The app is also an MCP server (/mcp) so AI agents can ask it about supply and compliance.

How the app is delivered: the lifecycle after code

An app like this must keep changing as regulators change the rules, so BandCheck is built and shipped by agents on the GitLab Duo Agent Platform, under human supervision of the outcome:

  1. Plan and Create: a Duo flow (bandcheck-ship) plans an issue into acceptance criteria and a risk rating, builds the change with a regression test, and a reviewer component reads the diff against the plan.
  2. Verify and Secure: lint, tests, GitLab SAST and secret detection, a security gate with an automatic fix path.
  3. Govern: a policy gate (every change closes an issue, code changes carry tests, agents cannot touch CI or infrastructure), a steward that merges only when every gate is green, an audit trail on each shipped issue.
  4. Package and Configure: Cloud Build, Artifact Registry, Terraform with GitLab-managed state, keyless Workload Identity Federation.
  5. Release: a no-traffic Cloud Run revision, a smoke test, then a 5% canary beside the stable revision.
  6. Monitor: the canary is judged by SLO burn rates (SRE Workbook multi-window rules) against the stable revision, plus a check that the served band table still matches the regulator's orders.
  7. The one human decision (Supervised): an approval card on the merge request shows the gate results, burn rates, request counts, regulator check, the rollback condition it promises, an expiry and an evidence digest. A person presses play on the manual promote job; it refuses without a person, a matching digest and an unexpired card. An unapproved canary is taken down after 24 hours: the default is no. After promotion, the system checks production against the card's promise and rolls back on its own if it broke.

No model decides any gate. Code measures, a person signs, and a test fails if any agent code can call the job-play API.

Built with

GitLab Duo Agent Platform (custom flows, MCP), GitLab CI/CD, Google Cloud Run, Cloud Build, Artifact Registry, Firestore, Cloud Logging, Terraform, Python, FastAPI, Claude.

Links and resources

What's next

Per-feeder evidence reports customers can attach to a regulator complaint, LASERC's own orders for Lagos feeders, and an open template of this supervised delivery lifecycle that other GitLab projects can adopt.

Solo entry, built with AI assistance (Claude), owned and approved by Daniel Asaboro; started after October 5, 2026.

Built With

  • artifact-registry
  • claude
  • cloud-build
  • fastapi
  • firestore
  • gitlab
  • gitlab-ci
  • gitlab-duo-agent-platform
  • google-cloud
  • google-cloud-run
  • python
  • terraform
Share this project:

Updates

Submission history