Bagombeka JobSoftware Engineer

Uganda's education sector ran on data that could not be trusted. National identity records and learner records lived in separate systems with no verification at the point of entry, so the sector could not trust its own numbers or act confidently on them.

The reporting problem sat on top of the data problem. Staffing, enrolment and district performance were held in different places and reconciled by hand, which meant the figures behind budget and policy decisions were late, inconsistent and easy to question.

Build the learner and workforce backbone of the national platform: a learners module that registers every child in the country against a verified identity, an HR module covering the teaching workforce, and the foundational infrastructure for national education reporting.

Around that, deliver the access control that decides who may see and change what across a multi-agency platform, the validation that keeps the data correct under national load, the reporting layer that turns operational records into public and ministry-facing dashboards, and the integration framework for the agencies that share education data.

Built the national learners module in Laravel and Vue 3 on a PostgreSQL schema exceeding 1,000 tables, and integrated NIRA (the National Identification and Registration Authority) national identity and registration services directly into the platform.

Extended the same foundation across the sector. The HR module centralised nationwide staff records and integrated national workforce management, work permit and refugee data sources. The architecture also included national reporting and validation services used by the ministry and district teams.

Designed and documented the data model, the 1,000+ table schema, the SRS (Software Requirements Specification) and the system architecture that became the reference specification for the deployment and delivery model.

Built the cross-agency integrations as services in Laravel, Go and Python FastAPI, connecting NIRA for identity, UNEB for examinations, TMIS for transport and school management, and the operational data that made the platform usable in practice.

Implemented role and permission management so ministry headquarters, district officials and individual schools each see and edit only their own scope, secured with OAuth 2.0 and token-based access patterns.

Built the DEO (District Education Officer) data validation workflow that stands between a school's submission and the national figures. A school enters its own enrolment, staffing and facility data, and the validation layer rejects or flags mismatches before the national system trusts it.

Delivered the interfaces ministry staff and district officers use daily: data-heavy dashboards and validated bulk-entry forms built in Vue 3 with Pinia and TanStack Query, which keep server interactions predictable and the UI performant under national load.

Laid the documentation foundation the platform is still built on. Architecture decision records capture why each load-bearing choice was made and what was rejected, so a decision can be traced later and new engineers don't have to rediscover context in tribal knowledge.

Licensed private waste-collection companies ran their operations across disconnected tools — scheduling in one place, fleet somewhere else, billing and accounting in spreadsheets. No single source of truth existed for daily operations or financial state.

The regulatory shape made it harder. An operator works across several city authorities, each licensing and reporting on it separately, and money moves along two entirely different paths: operational income from service delivery and compliance-related charges from municipal authority relationships.

Build a multi-tenant, multi-territory platform where each licensed operator runs its entire business — customers, scheduling, fleet, billing, payments and accounting — on its own subdomain while the broader platform handles shared infrastructure and governance.

Sit that under a control plane that onboards tenants, bills them for the platform and runs the shared infrastructure, while keeping the two money relationships strictly separate so the platform can remain compliant and auditable.

Built a Go modular monolith on Chi spanning 44 domain modules — operations, scheduling, fleet, containers, customers, contracts, procurement, payroll, HR, billing, payments, reconciliation and accounting.

Isolated tenants with schema-per-tenant PostgreSQL backed by row-level security as a second line of defence, so a query bug cannot leak across tenants even if it escapes the schema boundary.

Implemented a native double-entry general ledger rather than bolting reporting onto invoice tables. It is multi-currency, tax-aware and billing-source-agnostic, so revenue recognised from operational charges and regulatory charges remains correct in every market.

Deployed on Cloud Run in africa-south1 for on-continent data residency, and drew the module boundaries so Payments, Telematics and the shared premise registry can be carved out into independent services later without rewriting the business logic.

Parliament of Uganda needed to reach very large contact bases reliably, on a platform where a failed dispatch is visible institutionally rather than quietly retried. Government communications are not an edge case; they are a public trust issue.

The volume breaks the naive approach twice over. Per-message synchronous delivery collapses long before the contact base is exhausted, and a bulk upload of tens of millions of rows cannot be processed as a single transaction or as a naive in-memory batch.

Build ingestion capable of absorbing tens of millions of contacts and delivery capable of dispatching against them without degrading the rest of the platform, under strict government security and operational requirements.

Make the pipeline observable enough to prove it is healthy — not merely to debug it after a failure, but to see saturation coming while there is still time to act.

Built structured bulk ingestion for large contact uploads and a contact-management module that segments recipients by administrative unit, so a message can target a district or constituency without every contact being treated alike.

Moved delivery onto Kafka, decoupling ingestion from dispatch. Producers write regardless of how fast consumers drain, so a slow gateway or a burst of traffic degrades throughput instead of taking the whole service down.

Implemented and supported the delivery path itself through Kannel and SMPP gateways, diagnosing delivery failures, throughput bottlenecks and binding faults directly against the real operational path.

Instrumented the pipeline with Prometheus metrics and built Grafana dashboards over ingestion rate, consumer lag and delivery outcomes. Consumer lag is the signal that matters: it rises before failure and tells the operator exactly where pressure has built up.

Integrating an AI model into a Go service means writing the same 400 lines every time: request mapping, SSE (Server-Sent Events) parsing, retry with jitter, rate-limit backoff, token accounting and the vendor-specific quirks that only show up under load.

Change vendor, or A/B two of them, and you write it again — this time with two subtly different implementations to keep in sync. Existing options either wrap a single provider or wrap a direct client interface, but neither makes switching a first-class operation.

Write that layer once, properly, so switching between Claude, GPT, Gemini and 400+ other models is a one-line change rather than a rewrite.

Do it without imposing a dependency graph on anyone who imports it, and without the abstraction ever becoming a ceiling — a caller must always be able to reach what the provider actually offers.

Designed one Request/Response shape across every vendor, with model IDs as pass-through strings. New models work the day they launch without waiting for a release, because the library never hard-codes a feature matrix.

Kept the core module at zero external dependencies and split the chi HTTP gateway, the OpenTelemetry integration and the Anthropic adapter into separate Go modules. Importing the library stays lightweight while advanced integrations remain optional.

Unified SSE streaming with proper context cancellation and no goroutine leaks, and typed errors that work with errors.Is and errors.As so callers can branch on rate limits, context length errors or provider-specific failures without brittle string matching.

Backed it with engineering the code implies: more than half the codebase is tests, 8 architecture decision records document the load-bearing choices, and a threat model, benchmark figures and CI gates back the project as a real package instead of a demo.

Most document automation is still a brittle prompt: send a PDF or image to a model, hope the JSON is valid, and accept that the result may be wrong in ways you cannot audit. That is acceptable for prototypes, not for business-critical documents.

The real problem is not just extraction. It is extraction with provenance, typed output, validation and evidence — because a field that is merely 'present' is not the same as a field that is correct and explainable.

Build a document extraction library that turns PDFs, scans and images into a typed Go struct, not a loose map. The output must include per-field confidence, provenance for every value and explicit validation constraints.

Keep the core dependency-free and provider-agnostic while making the system strong enough for real documents: text-layer first, OCR fallback when needed, schema-driven prompt construction and a contract that is auditable after the fact.

Designed the pipeline around a staged flow: detect the format, acquire text or pages, normalise layout without losing offsets, reflect the Go schema into a request contract, generate JSON, validate it against the target type and surface explainability data for every extracted value.

Kept the core clean by separating the library into a zero-dependency root with explicit seams for the model, OCR and renderer. Provider adapters live in their own modules, so importing ovrin stays small and predictable.

Built in explicit guardrails from day one: untrusted input is treated as untrusted, the system validates and rejects unsupported schema shapes early, per-field errors do not kill the whole document and provenance data remains attached to each value.

Backed the implementation with a broad verification gate: offline tests, race tests, docs checks, make targets across modules, coverage reporting and a CI setup that validates code quality before a release is marked as ready.

An AI coding agent runs with the full authority of the person who started it. An agent that can edit files can delete them, an agent that can run tests can run any command, and an agent that can publish a release can move code into production.

The deeper problem is that standing access is always broader than the task in hand. Asked to fix a login bug in src/auth/, an agent still holds permission to rewrite migrations/ — not because it is malicious, but because the access model is not task-scoped.

Build an authorization layer that sits between any agent and what it acts on, and answers one question per proposed action: allow, deny, or hold for a human.

Make the answer provable. A security reviewer should be able to read a specification and predict the decision, and a replay of the same inputs must reproduce it exactly — which rules out implicit state and fuzzy policy evaluation.

Designed the engine so that permission has exactly one source. Five stages run in a fixed order — identity, capability, policy, intent, risk — and four of them are gates: they may deny, but never silently mutate the outcome.

Made determinism structural rather than aspirational. The engine is pure and synchronous, performs no I/O, and its inputs are exactly five: the action request, an immutable policy snapshot, the identity context, the task context and the current risk signal.

Bound actions to the task the developer actually confirmed, through a closed set of machine-checkable constraints — path scope, forbidden action types, allowed hosts, budgets for writes and rollback expectations.

Took fail-closed seriously everywhere: any failure inside evaluation denies, a failed audit write denies the action it was recording, and when no approver can be reached a pending decision blocks the action.

Wrote the contract down so other hosts can implement it: versioned specifications with JSON schemas and conformance vectors for the action request, the decision, evaluation, intent binding and audit logs.

Every component library eventually tells the same lie. The props table says one thing, the component emits another, the TypeScript declarations were hand-written six releases ago, and the contract has drifted out of sync with the implementation.

The second lie is the package itself. A library is developed inside a repository full of build tooling and demo dependencies, but what a consumer installs is a tarball. The two are rarely the same thing, and even when they are, the contract is not enforced.

Build a usable set of Vue 3 components where the documented contract cannot disagree with the implementation — not by convention or review discipline, but because disagreement fails the build.

Make the published artefact provable: what a consumer installs has to be tested as a consumer receives it, not as it exists in the working tree.

Each component has one API record holding its description, props, events, notes and keyboard contract. Three things derive from that single record: the documentation table, the TypeScript declarations and the test fixtures.

The contract test closes the loop in the other direction. It parses the defineEmits call out of each single-file component and asserts the documented events match the implementation exactly.

The release gate builds the real tarball, installs it into a temporary directory with no network access, then compiles all 60 examples through both ESM and CommonJS, server-renders them, and ensures the lockstep contract does not quietly drift during packaging.

Controls are built on native elements rather than reimplemented: a real dialog element for modals, native disclosure and form controls, and color-scheme declared in the token layer so the component remains native and predictable under browser variation.

Publishing is a manual workflow dispatch — never on push or pull request. It refuses to run unless the requested version matches package.json and version-specific release notes exist, and that process keeps releases honest.