Local Voice Pack Fallback: How a Public API Kept Kojo’s Conversation Moving

Synthesis stays available by preferring a verified, locally cached MMS voice revision and using a public API only when the preferred local path cannot serve the request. Where a corresponding local pack exists, the public path remains fallback-only, and provider availability is never guaranteed.

Imagine Kojo, a composite example, standing under the awning of a closed shop in Kumasi as rain taps against the metal roof. He is holding his phone close, rehearsing a mixed Twi and Ghanaian English message before calling his aunt. The wording matters because she is waiting for his answer before making a family arrangement.

He presses and holds to speak. Nothing comes back.

The local synthesis service is under a public-service constraint at that moment. If the app quietly drops the request, Kojo cannot tell whether his connection failed, his speech was misunderstood, or the reply never existed. His aunt may go ahead without him. The arrangement could fall apart before he explains himself.

That uncertainty is exactly why fallback policy matters.

Local voice packs take the preferred path

When the corresponding local voice pack exists, synthesis should begin with the verified MMS revision stored in the local cache. This preference gives the system a known voice artifact to request first rather than sending every reply directly to a public provider.

“Verified revision” matters here. A cache can contain several files, stale revisions, or incomplete material. Presence alone does not make a pack suitable. The application needs evidence that identifies the expected pack and revision before treating it as the preferred synthesis path.

The rule is simple:

1. Match the requested voice or locale to its corresponding local pack.
2. Confirm that the cached MMS revision is the verified one.
3. Attempt synthesis through that local path.
4. Use the public API only if the preferred path cannot serve the request.
5. Show an error if neither path returns usable speech.

This order prevents an available local pack from becoming decorative while routine traffic goes to the public service. It also makes behavior easier to inspect. A developer can see which path was preferred, which path answered, and where a failure occurred.

Language selection needs equal care. A valid pack paired with the wrong locale or unsuitable speech text can still produce the wrong result. What happens when the locale key and speech text disagree? examines that separate failure boundary.

The public API has one defined job

The public API provides a second route when the preferred local path cannot complete synthesis. It does not replace the local preference where the corresponding pack exists.

Suppose Kojo’s reply has already been generated as text, but the verified local MMS revision cannot produce audio during that request. The application can pass the eligible speech text to the public provider and wait for synthesized audio. If the provider responds successfully, Kojo hears the reply and can continue his hands-free conversation.

With the call to his aunt now close, that turn arrives just in time. He hears the response, interrupts naturally to correct one phrase, and rehearses the message once more. Then he steps away from the awning and makes the call.

The public route still carries an important limit: provider availability is not guaranteed. The provider may be unreachable, reject a request, or fail to return usable audio. Fallback reduces dependence on a single synthesis path, but it cannot promise that speech will always be produced.

That distinction should remain visible in both implementation and copy. “Fallback available” describes a routing policy. “Voice always available” would promise an outcome the evidence cannot support.

Walk through a synthesis request

Consider a request containing natural Twi and Ghanaian English. The person holds to speak, the conversation produces a reply, and the app needs to read that reply aloud.

First, the system identifies the appropriate local voice pack. If the corresponding pack exists and its cached MMS revision matches the verified evidence, that revision receives the synthesis request.

If the local attempt succeeds, the app plays the audio. The public API is not called.

If the local attempt cannot serve the request, the system moves to the public fallback. A successful public response supplies the audio for that turn. This supports the same conversational moment, including hearing the reply and interrupting naturally, without changing the public route into the default.

If the provider is also unavailable, the app must surface the failure. Nkomo never fails silently: errors are shown rather than swallowed. The person can then decide whether to retry, continue with typed conversation, or stop. They are not left staring at a motionless screen and guessing what happened.

The walkthrough also reveals what the fallback does not prove. It does not prove that every locale has a corresponding local pack. It does not prove permanent public-provider uptime. It does not turn proposed packs or planned revisions into live capabilities. Only verified, currently available evidence belongs in the production path.

Test the boundary, not only the happy path

A useful test begins with the local pack available and verified. Confirm that synthesis uses it and that no public request occurs.

Next, make the local path unable to serve the request. Confirm that the public API receives the eligible fallback request and that returned audio plays.

Then make both paths unavailable. The expected result is a visible error, not silence, an endless loading state, or invented audio. This final check protects the moment that matters most: the person knows the request failed and retains control over what to do next.

For Kojo, the changed state is modest and concrete. He makes the call knowing which sentence he wants to use. For the system, the lesson is equally concrete: prefer verified local evidence, keep the public path in its fallback role, and make the last failure visible.