Aisha: a culturally aligned assistant on infrastructure its owners control

Section 01

The problem

General-purpose assistants are trained on a corpus that reflects who has been writing on the open web, and who has been writing about whom. For a Black user the result is rarely a refusal. It is something subtler and harder to argue with: an answer that is technically accurate, culturally tone deaf, and sourced from people describing a community rather than people inside it. Ask about a health symptom, a neighbourhood, a hair product, a historical figure or a piece of slang, and the gap shows up as flattening, hedging, or a confident explanation drawn from an outsider's account.

Onyx Impact did not want a chatbot with a different personality. They wanted a system whose answers were grounded in sources the community would recognise as authoritative, that behaved predictably on the questions where mainstream models fail, and that did not quietly send every conversation to a third party to be used as training data.

Section 02

Why not just prompt a frontier model

The obvious approach is a long system prompt on a frontier API. We tried it first, because it is cheap to test and occasionally it is the right answer.

It failed on three counts. A prompt shifts tone but does not change what the model knows, so the underlying sourcing problem survives. Prompt-level behaviour is not stable across model versions, and the provider changes the model on their schedule, not yours. And the conversations themselves leave the building, which for an organisation whose value rests on community trust is not a technical detail but the whole argument.

So the design question became: what is the smallest change to the stack that fixes sourcing, behaviour and custody at the same time.

Section 03

The architecture

The system is a foundation model with a trained alignment layer in front of the response, a retrieval step over a curated corpus, and a routing policy that decides which of those paths a given question takes.

The foundation model provides general reasoning and fluency. It is open weight, which matters for three reasons: it can be hosted anywhere, it can be frozen at a known version so behaviour does not move under the product, and its weights can be adapted rather than merely prompted.

The alignment layer is a separately trained model that sits between the foundation model's draft and the user. It is not a profanity filter and not a blocklist. It is trained on paired examples of weaker and stronger answers to the same question, judged by reviewers from the community, and it rewrites framing, restores context the base model dropped, and flags answers that should be grounded in a source rather than generated from memory.

The retrieval step draws on a curated corpus assembled with Onyx Impact: Black-owned publications, historical archives, public health material written for the community, and reference works chosen by their editorial team rather than scraped indiscriminately.

The router decides. Most questions are ordinary and pass through with light touch. Questions in the categories where mainstream models are known to fail are sent down the retrieval path and through the full alignment pass.

Section 04

Building the alignment layer

Section 05

Routing and when the layer intervenes

The router classifies each question and applies a policy that Onyx Impact can read and change. Ordinary factual and task questions take the light path, because a culturally aware assistant that is slow and strange about arithmetic is not serving anyone. Questions touching health, history, identity, safety, law enforcement, education and money take the full path, because those are where the failures are both most likely and most costly.

Two properties matter more than the classifier's accuracy. The policy is legible, so a person can read the rules and object to them. And the fallback is safe: if retrieval or the alignment layer is unavailable, the system answers from the base model and says that it is doing so, rather than failing or silently degrading.

Section 06

How we evaluated it

Automatic metrics on their own are close to worthless here, because the thing being measured is whether a person recognises an answer as speaking to them.

The evaluation had three parts. A held-out set of questions written by the community, never seen in training, scored blind by reviewers against the rubric that came out of the preference work. A side-by-side preference test against the unmodified base model and against two frontier assistants, with reviewers unaware of which system produced which answer. And a standing red team of community reviewers probing for the specific failures the product exists to prevent: erasure, stereotype, false authority and unnecessary refusal.

The evaluation sets belong to Onyx Impact. That is deliberate. An organisation that cannot re-run the test on its own is dependent on the vendor's word, which is the position this project was built to get out of.

Section 07

Results

The figures below compare the full system against the same foundation model with no alignment layer and no retrieval, on the held-out question set.

Two results are worth separating. The gap is widest exactly where the product exists, on health, history and identity, and narrowest on everyday tasks, which is the correct shape: a culturally aligned assistant should be unremarkable when you ask it to convert a measurement. And sourcing improved more than tone did. That is the part that changes what the product is, because a claim a user can check is a different kind of object from a claim they have to trust.

Section 08

Hosting, privacy and data residency

Aisha runs on Contabo infrastructure in Canadian data centres in Vancouver, Calgary and Montreal, on hydroelectric grids. Conversations are not used to train the model.

That is a product decision before it is an infrastructure one. An assistant whose value rests on community trust cannot ask that community to route its most sensitive questions through a company it has no relationship with. Open weights are what make the choice available: the model can be frozen, moved, audited and run somewhere its owners are comfortable with, which is not on offer when the model is a rented endpoint.

Region and residency

Canada: Vancouver, Calgary, Montreal

Retention policy

Conversations are not used to train the model.

Who holds the weights

Onyx Impact

Who holds the evaluation sets

Onyx Impact

Section 09

What we would do differently

• Start the reviewer panel earlier. The preference data shaped every later decision, and we built parts of the pipeline before we had it. Some of that work was thrown away.
• Separate tone from sourcing sooner. For several weeks we measured them as one quality score, which hid the fact that they were improving at very different rates and for different reasons.
• Design the refusal behaviour with the community, not for it. Our early instinct was to refuse more often on sensitive topics, and reviewers told us plainly that an over-cautious assistant is its own kind of condescension.

Section 10

Conclusion

A general model with a long prompt can sound different. It cannot know different, it cannot hold still across versions, and it cannot keep a conversation inside the building. Changing all three took a foundation model that could be frozen and hosted, a layer trained on judgements from the people the product serves, and a routing policy its owners can read and change.