DEV Community: Bernard Abuto

Why I Started Sauti Labs

Bernard Abuto — Tue, 27 Oct 2026 21:10:47 +0000

It began with a speech model that didn’t understand the people I was building for. What I found when I went looking for alternatives, and why I think the distance between African-language research and usable products is worth building a company around.

Sauti Labs started with a practical problem, not a plan to start a company.

In July 2026, I was building Scribe AI, an offline system that listens to a church service and puts the scripture being referenced on screen. Everything in it depends on speech recognition, and for that I used OpenAI’s Whisper.

On the African languages and accents the system needed to handle, it disappointed me.

I went looking for alternatives. As I explain in Coverage Is Not Capability: What Whisper Taught Me About African Speech, Whisper’s training data is heavily concentrated in English. Swahili appears with roughly five hours of transcribed speech, while Dholuo—the language that first drew me into this work—is absent from its supported-language list.

I wanted a model I could access, integrate, and rely on. That search took longer than I expected, and it changed what I was looking for.

Arriving in a Field That Already Existed

The first thing I learned was that I was arriving late to serious, sustained work.

Masakhane, a grassroots community focused on strengthening natural language processing research in African languages, has spent years building open datasets, models, and benchmarks. Its MasakhaNER project, for example, released a large, publicly available named-entity recognition dataset covering ten African languages, alongside code and models.

Closer to home, the Maseno Centre for Applied AI is collecting voice data in five Kenyan languages, including Dholuo, as part of African Next Voices—a multi-country effort to build speech datasets for African languages, funded mainly by the Gates Foundation.

In South Africa, Lelapa AI builds products directly. Its Vulavula platform transcribes and translates contact-centre conversations in languages such as isiZulu and Sesotho. Its researchers have also released InkubaLM, a small language model for five African languages.

Global research labs have expanded their efforts too. Meta’s speech models now claim coverage of more than 1,600 languages.

This is not a field waiting to be discovered. It has years of difficult, often under-resourced work behind it, and whatever I build stands on that work.

The Distance I Kept Running Into

And yet, as a developer with a concrete problem, I kept running into the same distance.

A dataset existed, but not a model trained for my use case.

A model listed my language, but its error rates were far from what a product needed.

A model worked, but its licence ruled out commercial use, or it required hardware my users did not have.

The products that did exist had been built, sensibly, around particular languages and markets. That is how products should start, but it still left the speech I needed uncovered.

Over time, that experience hardened into a conviction. I sometimes put it bluntly:

Africa doesn’t need another conference paper. It needs products that are accessible to the people and work for them in the most efficient and natural way.

I should be clear about what I mean, because it is easy to read that statement as a criticism of research. It is not.

Papers, datasets, and benchmarks are how a field learns what works. Without them, there would be nothing for products to stand on. Research and product development are not opposites.

My point is about where the work tends to stop.

Knowledge has its greatest effect when someone carries it the rest of the way: into a model trained on real speech, served behind an interface a developer can call, packaged so a business can deploy it, and made good enough that the person on the other end stops noticing the technology.

That last stretch is often nobody’s job.

It is the stretch I want to work on.

Why Speech?

I chose speech and voice because I believe they will become some of the main ways people interact with AI and digital services generally. Yet many African languages remain underrepresented in precisely the systems that make those interactions possible.

That underrepresentation is more than a technical inconvenience. It limits what people can build.

A developer who wants to create a voice service for their community—a clinic line, an advisory service for farmers, or a support agent for a local business—cannot build it reliably if there is no capable model underneath.

It also shapes how people access services and how naturally they can speak to the technology around them.

When I listen to AI-generated speech in African languages today, I often hear the gap: pronunciation that is slightly off, an accent that belongs to someone else, or a delivery without the rhythm of a real speaker.

Something I watched recently made the stakes concrete. It was a demonstration of a system that allowed a person who had lost the ability to speak to communicate again in a synthetic version of their own voice.

Programmes such as ElevenLabs’ Impact Program offer voice-restoration support to people living with conditions such as ALS.

What stayed with me was not only the technical achievement, impressive as it was, but what had been returned to that person.

I found myself asking what the equivalent could mean for someone whose language such a system does not yet speak.

What I’m Building Towards

ElevenLabs is one of the clearest examples I know of carrying research the rest of the way into useful products.

Its work spans speech generation, voice cloning, dubbing, and conversational agents. What inspires me is less any single model than the range of things its products allow people to do.

I want Sauti Labs to make that same connection between serious technical work and useful products—for languages, accents, and settings that existing systems were not designed around, and with the linguistic, social, and technical challenges those contexts bring.

Sauti Labs is an AI research and products company. Its research areas span speech, language, language resources, model intelligence, and responsible AI.

The ambition extends beyond any single capability:

Speech recognition
Natural speech synthesis
Voice cloning and dubbing
Conversational systems and voice agents
Datasets and models
The infrastructure needed to develop and deploy these technologies

It also extends beyond any one language.

Dholuo shaped how I came to this work, but the work is meant for African languages generally.

These capabilities represent a direction, not a claim that every product or system is already complete. There is still a great deal to build, test, and learn.

I am learning from the communities and companies that came before me, and from the work itself.

Why Take the Risk?

Speech and language AI is expensive and research-intensive. It requires data, compute, funding, expertise, and time—precisely the resources many young Africans who recognise these problems clearly do not have.

I decided to take the risk anyway.

I believe these problems are important enough to justify starting early, even with limited resources. I also want people like me to be among those who build these systems, not only among those who receive technologies already designed around other languages and contexts.

This is not a claim that the work will be easy, or that conviction alone is enough. Building capable speech systems requires rigorous research, engineering, evaluation, and sustained investment.

But the difficulty is not a reason to ignore the problem.

I want African languages to take a full part in whatever AI becomes.

That is why Sauti Labs exists.

Sources and Further Reading
Masakhane — Research and community work in African-language NLP.
MasakhaNER: Named Entity Recognition for African Languages — Adelani et al. (2021), Transactions of the Association for Computational Linguistics.
African languages for AI: The project that’s gathering a huge new dataset — The Conversation.
Lelapa AI — African-language AI research and products.
InkubaLM: A Small Language Model for Low-Resource African Languages — arXiv.
Omnilingual ASR: Open-Source Multilingual Speech Recognition for 1600+ Languages — arXiv.
Robust Speech Recognition via Large-Scale Weak Supervision — Radford et al., the Whisper paper.
ElevenLabs Impact Program Announcement — ElevenLabs.

About Sauti Labs: Sauti Labs is working towards making African-language speech and language technology more useful, accessible, and deployable. Its long-term ambition spans research, models, datasets, and products across African languages.

Coverage Is Not Capability: What Whisper Taught Me About African Speech

Bernard Abuto — Tue, 27 Oct 2026 21:01:38 +0000

A language appearing in a model’s supported list says little about whether the model will work for your speakers. Why Whisper struggled with the speech I needed, and what I now check before building on any speech model.*

When I built the first version of Scribe AI in July 2026, speech recognition was the part I expected to be easy.

OpenAI’s Whisper was open, widely used, and described as multilingual. I ran it locally through Faster-Whisper, wired it into the live pipeline, and moved on to the parts I thought would be hard.

That expectation did not survive the speech I actually needed to handle. On the African languages and accents I cared about, the results were disappointing—not reliable enough to build on.

The problem was not a bug in my pipeline. When I went back to the Whisper paper, I found that the results were consistent with what the model’s own training data would lead us to expect.

What “Multilingual” Meant in Practice

Whisper was trained on 680,000 hours of labelled audio. The paper’s dataset statistics show how that total is divided:

438,218 hours of English speech recognition
125,739 hours of speech translation into English
117,113 hours of speech recognition across 96 other languages

Within that last group, the distribution is extremely uneven.

Swahili, one of Africa’s most widely spoken languages, is listed with approximately 5.4 hours of transcribed speech. Dholuo does not appear in Whisper’s language list.

“The amount of pre-training speech recognition data for a given language is very predictive of zero-shot performance on that language.” — Radford et al., the Whisper paper

Whisper was behaving in a way its training distribution helps explain.

The mistake was mine: I had treated multilingual as a uniform property of the model, when it actually described a highly uneven distribution of language coverage and capability.

The speech I needed sat in its thin tail.

Wider Coverage, the Same Question

Whisper is not the only option, and the field has moved forward.

In 2023, Meta released Massively Multilingual Speech (MMS), extending speech recognition to more than 1,100 languages. Much of its training data came from recorded readings of the New Testament, with roughly 32 hours per language.

In late 2025, Meta released Omnilingual ASR, which it describes as supporting more than 1,600 languages under the Apache 2.0 licence.

These are significant achievements. They expand what is possible for languages that previously had little or no speech recognition support.

But they sharpen the lesson rather than eliminate it.

Meta reports a character error rate below 10 for approximately 78% of the languages evaluated with Omnilingual ASR. Among low-resource languages, that figure falls to approximately 36%.

Coverage is a list. Capability is a distribution of error rates—usually measured on someone else’s test set.

When evaluating a speech model now, three questions matter more to me than whether a language appears on its supported-language list.

1. Does It Work on My Speakers?

Training and benchmark audio is often relatively clean and may consist largely of read speech.

Real-world audio can be very different.

A sermon, a phone call, or a customer-support conversation may contain spontaneous speech, unfamiliar accents, background noise, overlapping speakers, and frequent language switching.

A model that performs well on a benchmark may struggle under those conditions.

The most useful next step is to evaluate it on a small set of recordings representative of the intended environment, transcribed by hand to establish reference transcripts.

Then measure word error rate (WER) or character error rate (CER), as appropriate for the language and task.

The goal is not to find a model with an impressive headline metric. It is to find out how it performs on the speech your application actually needs to handle.

2. Can I Use It for What I Am Building?

Model quality is only one part of the decision. Licensing matters, too.

The original MMS models were released for non-commercial use only. That may be acceptable for some research projects, but it can prevent their use in a commercial product under those terms.

A model can perform well technically and still be unsuitable for a particular deployment.

Before building around one, I now consider the licence alongside performance, intended use, redistribution conditions, and deployment requirements.

An evaluation that ignores licensing can lead to an expensive architectural dead end.

3. Can It Run Where My Users Are?

Scribe AI is designed to run on the kind of laptop available at a church production desk, without depending on an internet connection.

That rules out models that are too large or too slow for the target hardware, regardless of how accurate they might be in a data centre.

Inference speed, memory requirements, quantisation support, and CPU performance all matter.

A model that achieves excellent accuracy on powerful hardware but cannot keep up with live speech on the intended machine is not a practical solution for that setting.

This is why model evaluation cannot end with a benchmark table. The deployment environment is part of the problem being solved.

Where That Left Scribe—and Me

For Scribe, the practical response was architectural.

Speech recognition sits in its own module, separate from detection and display, so a better model can be introduced later. A formal interface for swapping models is still on the roadmap.

Every detection also passes through a human operator before reaching the screen.

Neither decision improves the underlying recognition quality. Together, however, they help keep the system usable while recognition remains imperfect.

For me, the experience raised a larger question.

If a developer in Kenya wants to build a voice product for people who speak Dholuo, Kalenjin, or even Kenyan-accented English, what should they build it on?

Searching for an answer led me deeper into African speech and language AI as a field—and eventually to starting Sauti Labs.

I wrote separately about that journey: Why I Started Sauti Labs.

The broader motivation is straightforward: building useful speech technology requires more than making a language appear on a list. It requires understanding the data, the speakers, the deployment environment, and the limitations that remain.

Sources
Radford, A., et al. (2022). Robust Speech Recognition via Large-Scale Weak Supervision. arXiv.
OpenAI. Whisper language list (tokenizer.py). GitHub.
Pratap, V., et al. (2023). Scaling Speech Technology to 1,000+ Languages. arXiv.
The Decoder. Meta’s new open-source models speak more than 1,100 languages.
Omnilingual ASR: Open-Source Multilingual Speech Recognition for 1600+ Languages. arXiv.
The Decoder. Meta’s Omnilingual ASR brings speech recognition to 1,600 languages.

Project: Scribe AI — an offline-first system for detecting scripture references during church services, with human approval before display.

The API Chose My Sampling Design

Bernard Abuto — Tue, 27 Oct 2026 20:55:57 +0000

How an undocumented sort order in a public biodiversity API put 97% of my background points in January or February—and what I changed so that kind of bias gets caught before a model ever sees it.

Exploratory analysis is supposed to be the calm part of a project.

For QueleaGuard, it was where I discovered that 122 of my 126 background records—96.8%—fell in January or February. Among the real red-billed quelea observations, only 20.3% did.

Nothing had crashed. Every validation check up to that point had passed.

If I had gone straight to training, the model might have produced impressive-looking results for entirely the wrong reason. That is exactly what made the problem dangerous.

Why the Background Points Exist at All

QueleaGuard investigates where red-billed quelea occur around Ahero Rice Irrigation Scheme in Kenya.

The occurrence data comes from GBIF, which aggregates biodiversity observations, including citizen-science sightings from platforms such as eBird. This is presence-only data: it records where birds were observed, but not necessarily where someone looked and found none.

To model occurrence, I needed something to contrast the confirmed presences against.

I used an approximate target-group background: observations of other bird species recorded in the same area serve as a proxy for places where birders were active but did not record quelea.

The idea is to account, imperfectly, for observation effort. Bird sightings cluster around places people actually visit, so treating the landscape as though observation effort were evenly distributed would be misleading.

This approach has limitations. Individual bird records are a noisier proxy for observation effort than complete checklists, and I documented that limitation when adopting the method.

But the approach only helps if the background sample is drawn fairly across space and time.

Mine was not.

Why a Calendar Bias Is So Harmful

Almost every environmental feature in the dataset changes with the seasons:

Rainfall
Temperature
Dewpoint
Vegetation greenness

If nearly all background points fall in January and February while confirmed presences are distributed throughout the year, a model can distinguish the classes by learning the calendar rather than the ecology.

It might appear to predict quelea occurrence accurately, when it is actually exploiting a sampling artefact.

A confound like this does not produce an error. It produces a convincing result.

This is one of the more dangerous forms of data-quality failure: the pipeline can run successfully, the model can train without complaint, and the evaluation can look respectable.

The underlying research question, however, has been compromised before training even begins.

Finding the Cause

The effort-proxy pool came from a script that queried GBIF's occurrence/search endpoint one year at a time, with a cap of 150 records per year through pagination.

When I inspected the raw pool, several years—including 2000, 2011, and 2012—contained 150 January records out of 150.

GBIF does not guarantee a default sort order that would make this sampling strategy safe. Empirically, results from a year-only query were heavily front-loaded with January observations. Whenever a year contained more records than the cap, pagination stopped before the sample reached the rest of the year.

In effect, the API's response order was influencing my research sampling design.

The uncomfortable part was that I had already fixed a year-level version of the same problem when I first built the pool.

This was the same class of failure, one level deeper. It survived because I had not checked the monthly distribution of the background records.

The API had returned data. My code had accepted it. My validation had passed.

But I had not asked the question that mattered: What does the distribution of the returned records actually look like?

The Fix: Stop Depending on the Order

The endpoint accepts a month parameter alongside year.

Rather than trying to work around an undocumented ordering, I removed the dependency on it.

I changed the collection strategy to query individual year–month combinations:

16 years × 12 months = 192 queries, each targeting approximately 13 records.

The resulting pool looked substantially different.

Measure Before After
Effort-proxy records Year-capped, January-heavy 2,371 records, stratified by month
Largest single-month share 90.7% 8.8%
Records per month Extremely uneven 182–208

The key improvement was not simply collecting more records. It was making the sampling procedure explicit and reproducible rather than allowing the server's response order to determine which observations entered the dataset.

Another problem surfaced during the rebuild

While rebuilding the pool, I also closed a gap found during an earlier validation pass.

Three background records appeared to come from the same eBird checklist as a confirmed quelea sighting. That directly contradicted the purpose of using those records as background.

The rebuilt pipeline now excludes any effort-proxy record that shares both a grid cell and a date with a confirmed presence before sampling, rather than relying on later validation to catch the contradiction.

That rule removed 94 records that could otherwise have reintroduced the same problem.

The lesson here is important: fixing the monthly distribution alone would not have been enough. The sampling procedure also needed to enforce the assumptions behind the background data.

Checking Before Moving On

I deliberately held back the expensive part of the workflow—re-extracting rainfall, meteorological, and vegetation features for the new records—until the corrected sample passed its own validation checks.

The results were encouraging:

Monthly distribution: The largest single-month share was 18.8% of presences in November and 16.8% of background records in May. Neither class was concentrated in a single season.
Cross-class contradictions: There were zero cell-and-date pairs shared between presences and background.
Year coverage: Both classes spanned 2000–2026, with greater representation from 2021–2024 in both. This was consistent with the growth of eBird observations rather than an obvious artefact of the query strategy.
Spatial coverage: Background points now occupied 81 grid cells, up from 49.

I also kept the month-biased files, renamed and documented as superseded rather than deleting them.

That matters for reproducibility. If someone later wants to understand the original problem or investigate how much the sampling bias affected the analysis, the evidence is still available.

A corrected dataset is useful. A traceable record of how it became corrected is even better.

What I Took From It

Four lessons came out of this failure.

Whenever a data request has a cap, find out what determines which records are returned.

If the answer is effectively "whatever order the server uses," the sampling process is not fully under your control.

Stratify on the dimensions the model will be sensitive to.

Season influences almost every environmental feature in this project. Month therefore had to be part of the sampling design, not something I hoped would average out.

Check every dimension the model can see, separately for each class.

A pooled distribution can hide differences between presences and background records. Looking at the two classes separately exposed the problem.

Document the failure instead of quietly patching it.

The decision log now explains why the dataset looks the way it does. That record is part of the research, not administrative overhead.

These practices are useful beyond biodiversity modelling. Any pipeline that retrieves, filters, samples, or combines data can introduce a bias that remains invisible until someone examines the distribution of what actually came through.

The Research Models Have Not Been Trained Yet

QueleaGuard has not trained its research models yet, so I cannot tell you how much correcting this bias will change the eventual results.

I do not want to claim an improvement in predictive performance before the experiments have been run.

What I can say is that the dataset now has a more defensible sampling procedure, clearer validation rules, and a documented record of the problem that motivated the changes.

That is meaningful progress even before the first model is trained.

Whatever the results turn out to be, they should not simply be a measurement of what month it is.

Project: QueleaGuard — a research project investigating environmental, spatial, temporal, and agricultural drivers of red-billed quelea occurrence around Ahero Rice Irrigation Scheme in Kenya.

AI as a Detector, Not a Decision-Maker

Bernard Abuto — Tue, 27 Oct 2026 20:46:23 +0000

Designing Scribe AI’s live path: offline speech recognition, rule-based scripture detection, and a human approval step that keeps a wrong guess off a church screen.

Scribe AI listens to a church service and tries to catch scripture references as they are spoken — “turn with me to John chapter three, verse sixteen” — so the verse can be put on screen without a volunteer scrambling to type it.

It is a small system, but it operates in an unforgiving environment: whatever it gets wrong is projected in front of the whole room.

Two constraints shaped nearly every design decision: the system must keep working without the internet, and nothing it detects should reach the screen without human approval.

Offline Is a Requirement, Not a Feature

In the settings Scribe is designed for, a dropped connection in the middle of a service is ordinary, not an edge case. So everything in the live path runs locally against local data: microphone capture, speech recognition, detection, Bible lookup, and display. There is no network call anywhere in this path.

Speech recognition uses Faster-Whisper’s small model on the CPU, quantised to int8, with greedy decoding (beam_size=1) and voice-activity filtering to skip silence. Audio is captured at 16 kHz and transcribed in five-second chunks.

These are deliberate trade-offs for the kind of laptop a church production desk actually has: a smaller, faster model designed to keep up with speech, rather than a potentially more accurate one that falls behind it.

Offline operation is not simply a convenience. If the internet connection fails during a service, the system should still be able to do its job.

Rules, Where Rules Are Enough

It would have been easy to reach for a learned model to find scripture references in the transcript. I did not, because the detection problem does not require one.

Spoken references tend to follow a limited number of patterns. The detector covers four common forms:

John 3:16
John chapter 3 verse 16
John 3 16
John 316

The last example matters because speech recognition can compress a spoken reference into a run of digits.

The patterns match against all 66 Bible book names and common abbreviations. Each match is then checked against the actual number of chapters in that book. For example, Genesis 60 is rejected because Genesis has only 50 chapters.

That validation is particularly important for compressed references, where the detector must decide where the chapter number ends and the verse number begins.

The benefit is not accuracy for its own sake. It is inspectability. When the detector fires—or fails to fire—the logic behind the decision can be examined. There is no confidence score, and I have not pretended there is one. The detector checks whether a reference is valid according to its rules.

This is a useful reminder that not every component in an AI system needs to be another learned model. Sometimes a small, explicit rule set is easier to understand, test, and maintain.

References Don't Respect Chunk Boundaries

A preacher does not pause neatly every five seconds.

“John chapter three” might land at the end of one audio chunk, while “verse sixteen” arrives at the beginning of the next. If each chunk were processed independently, the detector could miss the complete reference.

To address this, when a chunk produces no detection, the system carries the last 60 characters of its transcript forward and prepends them to the next chunk.

When a chunk does produce a detection, the carried text is cleared to reduce the chance of detecting the same reference twice.

It is a small implementation detail, but it reflects a broader engineering problem: real-time systems have to account for the difference between how data is processed and how events actually occur.

The audio arrives in chunks. Human speech does not follow those boundaries.

The Approval Step

A detected reference never goes straight to the screen.

Instead, it appears in an operator console: a separate, always-on-top window where a person can approve the detection, dismiss it, or type a reference manually. Only an operator's action—approving a detection or entering a reference themselves—puts a verse on the display.

This is the system's answer to a simple question:

What happens when the AI is wrong?

A misheard reference costs the operator a click. Without the approval gate, it could mean displaying the wrong verse in front of an entire congregation.

Manual entry is equally important. The operator is never dependent on the detector. If the system misses a reference, the service can continue without waiting for the AI to recover.

The implementation also separates audio processing from the user interface. Audio capture and transcription run on a background thread, while the console and display belong to the Tkinter UI thread.

The audio thread never manipulates the interface directly. Instead, it schedules work on the UI thread with root.after, helping prevent the two threads from interfering with the same widgets.

The design principle is broader than this particular application: automating detection does not require automating the final decision.

Being Clear About What Is Not Connected

Scribe also contains a service-state machine—keyword rules that track whether the service is in worship, sermon, prayer, or announcements—and a lyric detector that fuzzy-matches transcript text against a song library.

Both are implemented and tested. Neither is connected to the live microphone path yet. They run together in a separate pipeline driven by simulated text.

That distinction matters.

It would be easy to describe the modules the system contains and leave readers with the impression that everything operates live. But having a working module is not the same as integrating it into the complete application.

There are other limitations, too. The lyric matcher's threshold has only been tested on clean text, and the song library contains placeholder data.

These limitations belong in the description of the system, not in a footnote. A clear account of what works, what has been tested, and what remains disconnected is more useful than a broader claim that the implementation cannot yet support.

What Comes Next

There are three main priorities for the next stage of Scribe AI:

Build a real-world evaluation set. Use recordings from actual services, including accents, crosstalk, and music, to measure detection performance under the conditions the system will encounter.
Integrate the separate pipelines. Create one live entry point that includes service-state tracking and lyric detection, replacing the split between the live path and the simulated pipeline.
Make speech recognition interchangeable. Introduce an interface that allows other models—including models better suited to African languages—to be swapped in and compared fairly.

These steps move the project beyond demonstrating that its components work in isolation and towards evaluating how well the complete system performs in practice.

The Model Is Not the Whole System

The general lesson I keep returning to is this: the most important design decision in an applied AI system is often not the model.

It is where the model's output is allowed to go, what happens when that output is wrong, and who gets to say no.

In Scribe AI, speech recognition proposes what it heard. Rules check whether a scripture reference is valid. A human operator decides whether the verse reaches the screen.

That separation is intentional. In a live environment where an incorrect output is immediately visible to everyone in the room, a useful AI system is not simply one that produces answers quickly. It is one designed to handle uncertainty without taking control away from the person responsible for the outcome.

Project: Scribe AI — an offline-first system for detecting scripture references during church services, with human approval before display.

Modelling the Landlord Who Isn’t There

Bernard Abuto — Tue, 27 Oct 2026 20:40:04 +0000

Modelling the Landlord Who Isn’t There

Most rental software assumes both sides of a tenancy are on the platform. That assumption fails for many tenants, so Rentra had to represent the relationship before the landlord arrives.

The first version of most rental-management software makes a quiet assumption: the landlord signs up, adds a property, and invites tenants. Every record begins on the landlord’s side.

When I started building Rentra in June 2026, I began from that assumption too. The first entities in the repository were users and the passkeys a landlord issues to tenants.

It took about two weeks for the assumption to break.

If Rentra only works once a landlord has joined, a tenant whose landlord never joins gets nothing: no rent history, no reminders, and no record of what they have paid. For a product meant to make rental life more orderly, the tenant is often the person who most needs that record.

Two Kinds of Tenant

Rentra now distinguishes two kinds of tenant.

A managed tenant is linked to a real tenancy: a unit, in a building, in a landlord’s portfolio.

An independent tenant is someone whose landlord is not on Rentra. They declare their own rental—a name for the property, the rent, how often it is due, and where it is paid—and Rentra keeps the record on their behalf.

In the code, that self-declared rental is its own entity, ShadowRentalRelationship, rather than a tenancy with some fields left empty.

There were three reasons for keeping it separate.

The ownership relationship is different.

A managed tenancy has an owner on the other side; a self-declared rental has only the tenant’s account of the arrangement. Mixing them in one table would mean every query about rent, arrears, or occupancy has to ask which kind of record it is looking at. Every authorisation rule would also have to account for a landlord who might not exist on the platform.

The information is genuinely different.

A self-declared rental records where rent is actually paid—an M-Pesa Paybill, a Till number, or a bank—and allows daily, weekly, or monthly billing cycles, because those are the facts a tenant knows.

A managed tenancy gets its structure from the landlord’s records instead.

Uncertainty remains visible.

Each self-declared rental carries a status: unverified, converted, or ended.

That distinction matters. A tenant’s declaration is useful information, but it is not the same as a tenancy verified by both sides. The data model should not imply otherwise.

When the Landlord Arrives

The interesting part is what happens when the absent landlord eventually joins.

Rentra’s approach is a passkey: a code the landlord generates for a specific unit. A new tenant can redeem it to register directly as a managed tenant. An independent tenant who already has an account can redeem it to link that account to the real unit.

But the transition is not complete yet.

The step after redemption—carrying the self-declared rental’s history into the managed tenancy—has not been implemented. The converted status exists in the schema, but no code path sets it, and payments are not yet linked to self-declared rentals at all.

I would rather leave that gap visible than paper over it, because merging two records about the same rental is where the hard questions live.

Which rent amount wins if the two disagree?

Does a payment recorded by the tenant become confirmed once the landlord can see it, or only once the landlord agrees?

What happens when the tenant’s record and the landlord’s record disagree about the history of the tenancy?

These are not merely database questions. They affect what the system claims to know, what each party can trust, and how disputes might be handled.

A conversion mechanism that simply merges records would conceal those decisions rather than resolve them.

Roles Are Not Ownership

The second modelling lesson came later, when I added role-based authorisation.

Rentra has three roles: tenant, landlord, and caretaker. The backend enforces them with guards on its controllers, so a modified mobile client cannot grant itself permissions simply by changing its local state.

But role checks answer only one question:

Is this kind of user allowed to do this kind of thing?

They do not answer the question that matters most for a tenant’s data:

Is this your record?

The tenant role might permit a user to view a tenancy, but it must not permit them to view someone else’s tenancy merely because they are a tenant.

That second check, ownership scoping, is still being built. It requires a different mechanism because it depends on the relationship between a specific user and a specific record, rather than on a label attached to the user.

Caretakers expose the same gap from the other side.

A caretaker acts on a landlord’s behalf—but for which buildings?

There is not yet an entity that scopes a caretaker to particular properties. The role exists, but the relationship that would make it safe to grant access across specific properties is not yet modelled.

The lesson is that role-based access control and resource-level authorisation solve different problems. Having the right role should not automatically grant access to every resource of that type.

Two Vocabularies

One smaller decision has held up well.

Internally, the backend talks about organisations and rooms. People using the app see a property portfolio and units.

The internal names are precise and stable, while the product names are the ones people actually use.

Keeping them separate lets the data model be refactored without rewriting the interface. It also lets the interface speak plainly without exposing database concepts to users.

The distinction is small, but it reflects a broader principle: the language used to implement a domain does not have to be the language used to explain it to customers.

What I Took From It

Domain modelling is mostly the work of noticing which real situations your first schema cannot represent.

The absent landlord is not an edge case in the markets Rentra is designed for. I suspect it is closer to the norm.

Giving that relationship its own entity, with an explicit status and an explicit path towards becoming something else, made the system more honest about what it actually knows.

It also made the unfinished work easier to identify. The conversion process still needs to reconcile conflicting records. Payments need to be linked to self-declared rentals. Ownership scoping needs to be completed. Caretaker access needs a property-level relationship.

Those gaps are easier to reason about when they are visible instead of being hidden behind a schema that pretends every tenancy starts with a landlord.

The repository’s README now lists, line by line, which pieces exist in code and which do not.

That list has been almost as useful to me as the code itself.

Project: Rentra — rental-management software designed to help tenants and landlords maintain clearer rental records, including situations where a landlord has not yet joined the platform.

Spatial Cross-Validation When the Data Won’t Spread Out

Bernard Abuto — Tue, 27 Oct 2026 20:04:11 +0000

Spatial Cross-Validation When the Data Won’t Spread Out

Random k-fold cross-validation can overstate model performance on clustered ecological data. But the obvious alternatives failed on my dataset too. Here is the spatial fold design I settled on for QueleaGuard, why the first two attempts failed, and what I verified before training a model.

Before QueleaGuard trains a research model, it needs a reliable way to evaluate whether that model generalises. For ecological point data, this is harder than it sounds. I tried two validation designs that failed before settling on one I trust.

Why Random Folds Are Not an Option

Observations close together in space tend to share characteristics: similar rainfall, similar vegetation, and similar distances to water.

If a random split places one observation in the training set and its neighbour a few hundred metres away in the test set, the model is partly being evaluated on data it has effectively already seen.

Research by Roberts et al. (2017) and Valavi et al. (2019) explains why ignoring spatial structure can underestimate predictive error and why spatially structured validation is often necessary.

The question for QueleaGuard was not whether to account for spatial structure. It was how to do so with an extremely uneven dataset.

Attempt 1: Use the Grid I Already Had

The analysis already divided the area around Ahero into 328 grid cells, each approximately 5.5 km across.

Blocking observations by these cells seemed like the natural starting point. But only 93 of the 328 cells contained records, and one persistent site along the Winam Gulf shoreline accounted for 62 of the 266 observations.

Grouping folds by grid cell would have produced folds dominated by a small number of cells, while others would have contributed little or no data.

The existing grid was useful for spatial analysis, but it did not automatically provide a workable cross-validation design.

Attempt 2: Cluster All the Points

Next, I applied k-means clustering to the coordinates of all records, using five clusters.

One resulting fold contained no presence observations at all.

In hindsight, the problem was straightforward. Background points were distributed across the entire 50 km analysis extent, while presence observations were concentrated around the rice scheme and the persistent shoreline site.

Clustering all points together could isolate a region containing only background observations.

That creates an evaluation problem: a fold without positive cases cannot provide meaningful estimates of recall or F1, and precision may also be undefined depending on the model's predictions.

A spatial partition can look reasonable geographically and still be unsuitable for the evaluation task.

What Worked: Anchor the Clusters on Presences

I changed the clustering strategy.

Instead of fitting k-means to all observations, I fitted it to presence coordinates only, using five clusters and a fixed random seed. I then assigned every record—both presence and background—to its nearest centroid.

This placed the centroids among the observed presences, ensuring that every cluster contained at least one presence observation.

The resulting fold distribution was:

Fold| Presence| Background| Total
0| 8| 42| 50
1| 9| 5| 14
2| 11| 20| 31
3| 36| 22| 58
4| 69| 44| 113
Total| 133| 133| 266

The folds are uneven. I kept them that way.

Fold 4 is large because it contains the persistent shoreline site, while fold 1 is small. Forcing the folds into equal sizes would mean prioritising numerical balance over the spatial structure I was trying to preserve.

The objective was not to make every fold identical. It was to construct spatially meaningful partitions that remained usable for evaluation.

Checking That the Folds Do What They Claim

I checked the resulting assignments against several invariants.

The persistent site stays together. All 62 records from the shoreline site landed in one fold, preventing that site's observations from being split between training and testing.

Grid-cell splitting is limited. Only one grid cell was split across two folds. Its two records are 4.6 km apart, farther than the largest 2 km neighbourhood used by the rice-landscape features. Consequently, those records do not share the same feature window.

This does not eliminate every possible source of spatial autocorrelation, and I do not claim that it does.

Every record is accounted for. The fold file covers the modelling dataset exactly: 266 records, each assigned once, without duplicates, across five fold IDs. Every fold contains both classes.

The assignment is reproducible. Repeating the clustering with the same data and configuration produces zero mismatches in fold assignments.

These checks do not prove that the validation design eliminates all spatial dependence. They establish that the implementation satisfies its intended assignment rules and addresses the specific failure modes encountered in the earlier attempts.

A Related Decision: Keep Coordinates Out of the Model

The same reasoning influenced the baseline predictor set.

I deliberately excluded raw latitude and longitude.

With observations this geographically concentrated, a model given raw coordinates could learn where the clusters occur instead of learning which environmental conditions are associated with quelea occurrence.

That would complicate interpretation: even with spatially structured folds, I would need to distinguish environmental relationships from geographical patterns that the model could exploit.

The baseline instead uses ten environmental and landscape predictors, plus season, selected after checking candidate predictors for redundancy.

The intention is to evaluate relationships with environmental and landscape conditions rather than hand the model explicit coordinates as shortcuts.

What This Design Does Not Fix

Fold 1 contains only 14 observations, nine of which are presences. Metrics computed on such a small sample will be noisy.

The appropriate response is to report per-fold results alongside the aggregate results, rather than allowing one average to conceal substantial variation between folds.

The dataset itself is also small: 133 presence observations. No cross-validation design can manufacture additional independent evidence from those records.

There are further limitations. Assigning records to the nearest presence-derived centroid does not guarantee a minimum geographic separation between training and test observations, nor does it remove all spatial autocorrelation. The design should therefore be treated as a deliberate spatial partition, not proof of complete spatial independence.

Most importantly, no model has been trained using these folds yet. This work establishes the evaluation design before performance results exist.

That order matters. If the validation scheme is fixed and documented first, there is less temptation to choose whichever design produces the most favourable scores.

For QueleaGuard, the immediate achievement is not a high-performing model. It is a reproducible evaluation setup whose assumptions, trade-offs, and limitations are explicit.

Project: QueleaGuard — research into environmental, spatial, temporal, and agricultural drivers of Red-billed Quelea occurrence around the Ahero Rice Irrigation Scheme.

References

Roberts, D. R., et al. (2017). Cross-validation strategies for data with temporal, spatial, hierarchical, or phylogenetic structure. Ecography. https://doi.org/10.1111/ecog.02881
Valavi, R., et al. (2019). blockCV: An R package for generating spatially or environmentally separated folds for k-fold cross-validation of species distribution models. Methods in Ecology and Evolution. https://doi.org/10.1111/2041-210X.13107