Armenian, Russian and English in One Production AI System

A multilingual AI system for Armenian, Russian and English is not a translation widget attached to a chatbot. It is a production architecture in which language is explicit state: the system detects it, preserves it through integrations, evaluates each language separately and chooses a safe fallback when confidence is insufficient.

For a company in Armenia, this matters because one real workflow may cross all three languages. A customer can write in Armenian, an operator may search internal material in Russian, and a product catalogue or API may use English identifiers. If the architecture silently treats English as the default, the demo can look convincing while names, dates, negation, product codes or permissions fail in production.

This guide defines a reusable architecture, component contracts, failure modes and a production check. It is technical long-tail guidance supporting the broader AI specialist in Armenia service page; it does not replace that commercial landing page.

1. Start with the workflow, not with the language list

“Support Armenian, Russian and English” is too vague to implement. A production requirement must identify who sends each input, what decision follows, where source data lives and how an operator corrects the result.

Consider a support-routing example:

• customers write free-form messages in Armenian, Russian or English;
• the system extracts account, product, intent and urgency;
• retrieval searches approved policies and product documents;
• a model drafts a response or routing recommendation;
• a human approves sensitive answers and every consequential CRM write;
• the audit record stores the original text, detected language, sources, output and reviewer action.

The requirement is not “translate every message to English.” It is “preserve meaning and traceability while moving a multilingual request through a controlled business process.” That distinction determines the data model and the tests.

Before choosing a model, record representative examples for each language, mixed-script messages, transliterated Armenian, product names, dates, numbers and the common exceptions operators already handle. The same inventory helps an AI workshop in Yerevan move from discussion to an evidence-based pilot.

2. Production requirements are contracts

A useful language contract should answer five questions.

1. Input: What encodings, scripts, channels and attachment types are accepted?
2. State: Which language attributes must survive every queue, API and database write?
3. Output: Must the answer match the user language, a configured account language or an operator choice?
4. Evidence: Which sources, transformations and model version must be traceable?
5. Fallback: What happens when the language or meaning is ambiguous?

A minimal message envelope can look like this:

type LanguageCode = "hy" | "ru" | "en" | "mixed" | "unknown";

type MultilingualEnvelope = {
  messageId: string;
  originalText: string;
  detectedLanguage: LanguageCode;
  detectionConfidence: number;
  normalizedText?: string;
  outputLanguage: "hy" | "ru" | "en";
  glossaryVersion: string;
  sourceIds: string[];
  requiresHumanReview: boolean;
};

The original text must remain immutable. Normalization and translation are derived artifacts, not replacements. Without that rule, an operator cannot reconstruct why a later classifier, retrieval query or response was wrong.

3. The LANE architecture

The original architecture used in this guide is LANE: Language-Aware Normalization and Execution. It separates the workflow into gates rather than asking one prompt to detect, translate, retrieve, decide and act.

This separation is more important than the choice of a particular model. Components can change independently while the envelope and acceptance gates remain stable.

Capture and Unicode normalization

Unicode normalization should be deliberate. Normalize to a documented form, preserve the original bytes or text, and test punctuation, Armenian quotation marks, combining characters, emojis and copied text from office documents. Do not lowercase blindly: case can carry product or legal meaning in Russian and English, while mixed identifiers may be case-sensitive.

Language detection is a routing hint

Short inputs such as names, “OK,” product codes or addresses may not contain enough language evidence. A detector must be allowed to return mixed or unknown. Confidence is not a universal probability; calibrate thresholds on the actual channel and message length.

Use deterministic rules for obvious conditions, a tested detector for ordinary messages and a human clarification route for ambiguity. Never let a low-confidence language label silently choose a high-impact action.

Translation is optional, not the architecture

Some components may work better with an English pivot, but translating everything can erase distinctions and introduce a second error surface. Prefer native processing when evaluation shows it is reliable. If a pivot is necessary, keep both original and translated text, store the translation version, and validate critical entities against the original.

Names, addresses, amounts, dates, contract terms and negation deserve explicit checks. A fluent translation is not proof that the business meaning was preserved.

4. Retrieval and knowledge design

Multilingual retrieval has three common patterns:

• separate indexes by language for strong control and clear ownership;
• one multilingual embedding index for cross-language discovery;
• hybrid routing that searches the primary language first and expands under controlled conditions.

The right choice depends on the documents. If Armenian policies are authoritative and Russian copies are outdated, a cross-language search must not rank the stale copy above the source of truth. Each chunk therefore needs language, document status, owner, version, effective date and access-control metadata.

Retrieval should return source identifiers and relevant passages, not an untraceable blob. The generation step must be able to abstain when no approved source supports an answer. Access control must be applied before or during retrieval, never only after text has reached the model.

For mixed-language queries, create language-specific query variants only when needed and log them. Evaluate retrieval separately from answer quality: the model cannot cite the correct policy if the retriever never returned it.

5. Model routing and structured output

A single model can serve all three languages if it passes the evaluation set, but model capability is only one part of routing. Production routing can also consider task type, sensitivity, latency budget and whether the result is a draft or an action.

Ask components to exchange typed objects. For example, an intent classifier should return a schema with intent, entities, language, confidence, evidence and review_required. Validate the object before it reaches CRM, n8n or another system.

Prompt instructions should say which language the output must use, whether transliteration is acceptable, how to preserve identifiers and when to abstain. System prompts are not security boundaries; permissions and validation belong in application code.

6. Integrations must preserve language state

Multilingual errors often appear outside the model:

• a webhook assumes ASCII or trims Unicode incorrectly;
• a CRM field has the wrong length or encoding;
• a queue loses detectedLanguage during serialization;
• a search endpoint tokenizes Armenian poorly;
• a notification template defaults to Russian;
• an operator correction is stored without linking it to the original output.

Define one canonical envelope and version it. Every integration must either preserve required fields or explicitly map them. Idempotency keys should be independent of translated text; otherwise the same message translated differently can create duplicate actions.

Consequential writes need least privilege, schema validation and human approval where error cost is material. This is an engineering boundary, not a prompt preference.

7. Failure modes to design before launch

The most dangerous failures are often silent. A crash is visible; a plausible response with a wrong amount or outdated source can pass unnoticed. Acceptance criteria must therefore measure severe semantic errors, not only grammatical quality.

8. Build an evaluation set by risk

Create a versioned evaluation set from real, permissioned and anonymized cases. Balance by language, channel, message length, task type and risk. Include:

• native Armenian in formal and conversational forms;
• Russian business language and common abbreviations;
• English product and technical terminology;
• Armenian written with Latin characters;
• mixed Armenian/Russian/English messages;
• spelling errors, voice-transcription artifacts and incomplete requests;
• names, addresses, dates, currencies, units and product codes;
• ambiguous cases where the correct behavior is clarification or abstention;
• adversarial instructions inside retrieved documents or user text.

Score component stages separately: language routing, entity preservation, retrieval recall, citation correctness, schema validity, output-language consistency and action safety. Then score the end-to-end workflow.

A launch threshold can require zero severe permission or amount errors, complete schema validity, tested abstention, and a documented minimum for each language. An average across three languages is insufficient: strong English performance must not conceal weak Armenian performance.

9. Testing pyramid for a multilingual AI system

Deterministic unit tests

Test Unicode normalization, field mapping, validators, permission checks, idempotency, retry limits and template selection. These tests should be fast and stable.

Component evaluations

Run labelled cases against detection, retrieval and structured generation. Pin datasets and record model, prompt, glossary and index versions so regressions are explainable.

Contract and integration tests

Send Armenian, Russian, English and mixed payloads through webhooks, queues, databases, CRM sandboxes and notification services. Verify round-trip text equality and required envelope fields.

End-to-end acceptance

Exercise the actual operator workflow: receive a case, retrieve evidence, draft or route, review, write, audit and rollback. Include timeouts and unavailable dependencies.

Browser and accessibility checks

Interfaces need fonts with Armenian and Cyrillic glyph coverage, correct line breaking, searchable original text and readable side-by-side evidence. Test mobile overflow because long identifiers and mixed scripts frequently expose layout defects.

10. Production checklist

Do not launch until the following statements are demonstrably true:

• original text is immutable and visible to reviewers;
• every derived translation or normalization is versioned;
• hy, ru, en, mixed and unknown are valid states;
• output language is selected by an explicit rule;
• critical entities are compared with original spans;
• retrieval applies status, language and access filters;
• every answer can cite approved sources or abstain;
• structured output is validated before integration writes;
• retries are bounded and idempotent;
• human approval protects consequential actions;
• evaluation results are reported separately for each language;
• monitoring includes detector drift, no-answer rate, severe errors, latency and cost;
• an incident runbook, rollback and named owner exist.

11. Observability and improvement

Log enough to diagnose a decision without storing unnecessary sensitive content. Useful fields include trace ID, language state, component versions, retrieval source IDs, validation outcome, approval state, latency, token usage and final route. Apply retention and access rules to traces just as carefully as to the primary business data.

Review quality by language and workflow stage. A rising Armenian no-answer rate may indicate missing documents, not a weaker model. A Russian latency spike may come from a translation branch. English entity failures may originate in a CRM mapping. Component-level traces prevent every problem from being mislabelled as “the AI model.”

Operator corrections are valuable only when captured as structured feedback: what was wrong, which span or source caused it, what the correct outcome was and whether the issue belongs to data, retrieval, prompt, model or integration.

12. From prototype to production

A prototype can use one endpoint, one prompt and a spreadsheet of examples. Production requires separation of concerns and operational ownership.

1. Frame one bounded multilingual workflow and its risk.
2. Collect representative cases with permission and expected outcomes.
3. Implement the canonical envelope and immutable original text.
4. Evaluate detection, normalization, retrieval and generation separately.
5. Add validation, approval, fallback, idempotency and audit.
6. Run a controlled pilot with per-language thresholds.
7. Expand only after failures are classified and ownership is proven.

For a broader view of local delivery evidence, see case studies and the about page. If your team already has a prototype but cannot explain its multilingual failure modes, request an architecture review or technical audit before connecting it to production systems.

Conclusion

One AI system can support Armenian, Russian and English without becoming three unrelated products. The key is to make language a first-class contract, preserve original evidence, isolate components, validate every boundary and measure each language independently.

The LANE architecture is intentionally model-agnostic. Models, detectors and indexes will change; the envelope, permissions, evaluation set, failure routes and operational ownership are what make the system maintainable. Start with one workflow, prove the severe-error controls, and only then broaden languages, channels or actions.