Research That Turns Into Working Tools.

Machines can start wearing out long before an alarm sounds or a scheduled check finds anything. Maintenance teams need earlier, clearer warning.

The MAD system is a working research prototype. It reads sensor data over time, learns what normal looks like, and flags unusual behaviour. The prototype is complete; testing on a real site is in progress.

It has not been tested on a real site, so we make no claims about how early it detects problems or how often it is wrong. Warning-time targets are targets, not results.

Run it at the target site: freeze the version, set pass/fail criteria, publish the test method, compare it against standard approaches, and count both missed events and false alarms.

Sensor readings, equipment condition, production data, and maintenance decisions usually sit in separate systems. A digital twin must join them without mixing up what was measured with what the model guessed.

A working digital twin of a flow station exists and runs today, including a clickable 3D plant. On screen, everything is separated into what was measured, what was worked out from it, what is predicted, and what is recommended. The twin produces its own operational datasets, and the first one is now public.

The twin runs on simulated data and has not been connected to or tested against a live physical facility.

Document the prototype's assumptions and how wrong its estimates can be, then test it against observed operations at a real site.

Industrial tools must cope with patchy connectivity, strict security, and limited on-site computing power.

The work covers reading sensors, processing data locally, connecting to plant control systems, and keeping things running when the network drops.

This is an architecture on paper, not a deployed system with proven performance.

Show a working pipeline that handles disconnection, keeps data intact, recovers cleanly, and controls who can access it.

Grid operators need to spot changing conditions early, see disruptions coming, and weigh their options.

A four-layer monitoring system has been built and backtested on real grid data: frequency excursion prediction, a grid stress index, thermal monitoring, and gas supply monitoring. The stress index scored r=0.803 against critical days on 731 days of Nigerian grid data.

The backtest results are early and lean, not yet industrially acceptable. Nothing has run against a live plant, and plant-specific calibration is still needed.

A pilot against live SCADA data at a power plant. The program needs contributors to strengthen the work.

Buyers struggle to find affordable equipment that actually fits a verified need. A low price alone proves nothing about suitability or availability.

A fully built pipeline exists: connectors across 13 marketplaces, scoring, buyer matching, and a human review desk. As of September 2026 it had ingested about 555 assets, matched 11 buyer-asset pairs, and passed 68 backend tests.

No transaction has closed yet, and full validation needs more compute infrastructure than the current free-tier setup allows.

Secure the compute budget to run all 13 connectors continuously, then complete a first closed transaction.

Insurance decisions need reliable claims-risk estimates, fair pricing, and ways to investigate suspected fraud.

The public page describes three proposed modules: ReserveAI, FraudShield, and PriceLens.

The description does not establish training data, testing, fraud-detection accuracy, or fitness for real use.

Document each module separately, set baselines, measure errors, and test data quality and fairness before any performance claim.

Property transactions carry title uncertainty, valuation error, fraud, and compliance risk.

The public page describes an automated workflow for land-title checks, valuation, fraud detection, and compliance in the Nigerian market.

Official-record access, title coverage, valuation accuracy, and legal acceptance are not established.

Show traceable data sources, exception handling, a documented valuation method, and human review of decisions that carry legal or financial consequences.

Commission-based ride models and smartphone-only workflows do not fit every driver's economics or every user's connectivity.

The public page describes a subscription model, WhatsApp and USSD access, CNG integration, and embedded financial services.

The description shows positioning, not live operations, driver adoption, unit economics, or working integrations.

Test driver economics, operating costs, low-connectivity workflows, demand, safety, and whether the subscription model holds up.

Prepared slides fall short when a meeting needs current data or answers beyond the deck.

The public page describes an AI assistant that can reach logs, dashboards, and data to find evidence when questions come up.

Tested integrations, speed, retrieval accuracy, and permission controls are not yet shown.

Show a bounded workflow: answers linked to sources, access controls, audit logs, and clear handling of missing or conflicting evidence.

Trading decisions depend on more than one signal. Market context, risk limits, and evidence quality must be weighed together.

The public page describes an AI-assisted trading tool with multi-stage testing and mobile workflows. The wider portfolio includes VLTHR Terminal, an algorithmic trading and analysis platform.

This describes direction, not live trading results. No profit, returns, or production use is claimed.

Document strategy assumptions, transaction costs, tests on unseen data, worst-case losses, and paper-trading results before any performance claim. A working prototype with test evidence is needed for grade B.

Getting from access to an open model to actually using it takes governed tooling, not just an API key.

Five components exist: a code library for compatible endpoints, a governance toolkit (policy check before requests, output validation, source tracking, append-only audit log), a test harness, a local speech-recognition service, and an MCP server for AI tools. In an October 2026 live run, all 10 test fixtures passed with a mean score of 93 out of 100.

Benchmark results come from the lab's own test fixtures, not independent evaluation. Production deployment and broad model compatibility are not yet established.

Publish a safe functional summary and a checkable milestone record once results have been verified.

Vehicle diagnostics, valuation, and upkeep are usually handled as separate jobs with separate tools.

Active development, including diagnostic-hardware work. The scope has grown from vehicle transactions toward AI-assisted vehicle management.

The updated scope and implementation status are not yet publicly documented.

Publish the updated scope, then show a complete workflow and document what is actually built.

Live-sound and choir administration combine equipment tracking, scheduling, and audio analysis.

The scope covers live-sound management, choir administration, equipment tracking, and audio analysis.

What is built has not yet been separated from what is planned.

Identify which modules exist, demonstrate the workflow, and document real audio-analysis capability separately from planned features.

Subsurface data needs checkable validation: clear structure, a record of where it came from, quality control, and stated uncertainty.

The architecture separates data organisation, system representation, uncertainty reduction, and decision validation.

Validation rules, representative data, and real-data integration are not yet demonstrated.

Document the validation rules, test data, exception handling, reproducibility, and real-data integration.

Research needs repeatable workflows, data analysis, software development, and documented checking at each stage.

The environment combines structured research, data analysis, software development, and AI-assisted workflows. More than 35 documented tool protocols are used day to day, with human review throughout.

These are components of workflows, not separate self-running products.

Publish workflow examples, quality controls, human-review boundaries, and completed outputs.

Server operations is reactive: problems are found late, diagnosed slowly, and fixed by hand under pressure.

A fully built agent that monitors Linux servers, detects anomalies, investigates root causes, and proposes repairs. Every high-risk action waits for human approval. Built for a hackathon with a working live deployment, including remote SSH management, a Telegram control interface, and an automated deployment pipeline.

It was built and demonstrated under hackathon conditions. Long-term reliability, security review at production scale, and independent evaluation are not yet established.

Run it against real production workloads over time: measure detection quality, approval accuracy, and how safe its actions are in practice.