-
-
login
-
mobile
-
Landing Page
-
Main Dashboard
ChiedzaAI — Project Story
Inspiration
Every time AI enters a boardroom, a classroom, a bank, or a government office, one question follows it: "Will there still be a job for me?"
That question isn't abstract for our team. In Zimbabwe, and across much of Africa, institutions are being asked to make workforce decisions in the dark — with no reliable datasets, no forecasting tools, and no explainable evidence about how AI and digital transformation will reshape jobs, skills, and productivity. Meanwhile, there's a real risk that African economies become consumers of foreign AI platforms while exporting their data, their digital value, and ultimately their jobs.
We also kept coming back to a harder truth: jobs aren't just economic units. They're identity, dignity, family security, and belonging. So whatever we built couldn't be a black box that quietly scores people out of relevance. It had to explain itself — to a bank executive, a regulator, or an employee — in a way that could be understood, challenged, and acted on.
That's the gap ChiedzaAI is built to close: an explainable, causal-consistent, multi-task AI platform that jointly forecasts employment, skills, and productivity impacts — starting with ZivaBasa, its first module, focused on the banking sector.
What it does
ZivaBasa takes workforce, HR, AI-adoption, and digital-transformation data and forecasts, in one architecture:
- Employment impact — displacement and creation signals
- Workforce skills gaps — which skills are becoming obsolete, which are emerging
- Productivity and efficiency shifts
Every prediction comes with a SHAP-based explainability layer, so the why behind a forecast is as visible as the forecast itself — for example, showing that a predicted displacement risk was driven by high automation intensity, declining transaction volumes, and low reskilling investment, not just an opaque score.
How we built it
We treated this less like a hackathon sprint and more like a compressed research programme, structured as a 14-day build plan across two weeks:
Week 1 — Foundations. Literature review across AI adoption in banking, automation-risk prediction, skills intelligence, and explainable AI. From there we defined the system architecture: a shared representation trunk feeding three task heads (employment, productivity, skills), designed around TensorFlow/Keras, with SHAP for explainability, FastAPI for serving, and a dashboard for the human-facing layer.
Data. Because real Zimbabwean banking-sector data isn't available yet, we deliberately built this MVP phase on public Kaggle datasets used as structurally realistic proxies — not as a claim about real Zimbabwean workforce dynamics. We were explicit with ourselves throughout: this phase validates the pipeline mechanics, not the findings.
Modeling. The core model is a multi-task deep learning network with a shared trunk and three output heads, trained jointly. Conceptually, the loss we optimize is a weighted sum across tasks:
$$ \mathcal{L}{\text{total}} = \lambda{e}\,\mathcal{L}{\text{employment}} + \lambda{p}\,\mathcal{L}{\text{productivity}} + \lambda{s}\,\mathcal{L}_{\text{skills}} $$
where each $\mathcal{L}_i$ is task-appropriate (classification loss for employment risk, regression loss for productivity and skills-gap scores), and $\lambda_e, \lambda_p, \lambda_s$ balance task contributions during joint training. We benchmarked this against classical baselines (logistic regression, decision trees, XGBoost/Random Forest) to make sure the multi-task deep model was earning its complexity, not just wearing an "AI" label.
Explainability. SHAP values sit over the trained models, and the feature set itself went through a deliberate reduction journey — from 150–300 raw candidate variables, down through engineered features, down to a final explainable set of roughly 15–40 features per outcome model, chosen for interpretability as much as predictive power.
Serving & product. A FastAPI service exposes predict / explain / batch / chat endpoints, backed by a prototype dashboard supporting batch upload, corporate KPIs, single-role lookups, and a conversational interface — with executive report export as a near-term target.
Challenges we ran into
We want to be honest about this section, because we think it's more useful than pretending the build was clean.
A silent schema mismatch. Our first pass at the employment dataset assumed placeholder column names (automation_risk, salary, digital_skill_level). The real Kaggle dataset we used was job-role-level, not employee-level, with entirely different column names. The pipeline ran without error — it just silently produced a feature set with no target column, and the employment model trained on nothing meaningful. We only caught it by running the full pipeline end-to-end against the real schema, not by code review.
A subtler data-leakage bug. After fixing the schema issue, one of our engineered interaction features — combining automation exposure and skill complexity — turned out to correlate ~0.49 with the target even on fully synthetic random data. It was a multiplicative derivative of a feature that was itself a monotonic transform of the target's source column. Removing the obvious raw column wasn't enough; we had to trace the leakage through the derived feature too. We confirmed the fix by checking that ROC-AUC on random synthetic targets dropped back to ~0.5 — chance level, as it should be.
Staying honest about scope. The hardest discipline wasn't technical — it was resisting the pull to overstate where we are. Our documentation explicitly separates what's done (data pipeline, baseline models, the multi-task model, a SHAP layer, a serving API, a prototype dashboard) from what's in progress or not yet built (skills-gap recommendation engine, multi-year LSTM forecasting, PDF/Excel executive reports, containerized deployment, and the full causal-consistent XAI and federated learning architecture, which remain research milestones rather than shipped features).
What we learned
- Explainability is a design constraint, not a feature you bolt on. Deciding early that every prediction needed a SHAP-backed explanation shaped our feature engineering, our model architecture, and even which baselines we bothered comparing against.
- Bugs that don't crash are the dangerous ones. Both real bugs we found were silent — a missing target column and a leaking feature — and both would have produced a model that looked like it worked. End-to-end validation against realistic schemas caught what code review didn't.
- Multi-task learning forces you to be precise about what "impact" means. Employment, productivity, and skills don't move together in obvious ways; forcing them through a shared trunk exposed how much of our early feature set was really just one signal wearing three names.
- Proxy data has a ceiling, and naming it is more valuable than hiding it. Kaggle data let us prove the architecture works mechanically. It cannot, and should not, be read as evidence about Zimbabwean banking-sector workforce dynamics — that's the whole reason the next phase is about real bank partnerships and privacy-preserving federated learning.
What's next
The roadmap ahead is concrete rather than aspirational: multi-year workforce forecasting with LSTM-based temporal modeling, an executive-ready report generator, containerized deployment, a formal test suite with CI, and — the piece we're most excited about — moving from associational SHAP explanations to causal-consistent explainability, alongside a privacy-preserving federated learning architecture that lets multiple banks contribute to the model without ever exposing raw data. Longer term, ZivaBasa is the first module of ChiedzaAI, with Cognify (training and reskilling) and NeuroWorks (orchestration) extending it into a full transformation-support ecosystem, aligned with Zimbabwe's National AI Strategy and Project Pangolin.
Log in or sign up for Devpost to join the conversation.