> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mibyanai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Technical report
> Mibyan 4.1: adaptation direction, system behavior, evaluation, and deployment accountability
This report describes how Mibyan 4.1 is developed and evaluated as an Arabic-first model system. It is written for researchers, technical buyers, and product teams who need more than a benchmark table before putting a model into a real workflow.
## Executive summary
Mibyan begins with a K2.6 foundation and is adapted for Arabic professional work. The work focuses on language fit, constraint retention, structured outputs, bilingual operating contexts, and a controlled service boundary. We evaluate the result as a system: quality, latency, reliability, and recoverability are reported together.
We deliberately distinguish what we publish from what is operationally sensitive. The report describes behavior and method, but not private customer data, credentials, internal hosts, or live routing configuration.
## Continued pretraining and fine-tuning
Mibyan is developed with a focus on Arabic and practical work. The data and task mix emphasizes Modern Standard Arabic, Gulf terminology, Arabic-English code switching, business writing, structured outputs, and instruction following.
The goal of fine-tuning is not simply to make Arabic text fluent. It is to improve the complete behavior users need: understanding an underspecified request, preserving constraints, choosing a useful structure, and producing an output that can be reviewed and edited.
### Adaptation principles
| Principle | Why it matters | Observable test |
| --------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Regional language fit | Literal translation loses register and business meaning | Experts check terminology, tone, and intent on held-out Arabic tasks |
| Constraint-first completion | A polished answer can still fail the request | The scorer counts every requested format, length, audience, and exclusion |
| Bilingual continuity | Real work frequently crosses Arabic and English inside one prompt | Mixed-language tasks check meaning preservation across the boundary |
| Structured usefulness | A work product should be reusable by a person or application | Schemas, sections, and required fields are validated before style is scored |
| Honest uncertainty | Fluent fabrication is more dangerous than a bounded answer | Failure analysis separates unsupported claims from clearly marked uncertainty |
## Model-system boundary
The model is exposed through the stable public identifier `mibyan-4.1` and an OpenAI-compatible contract. The public boundary is intentional: applications integrate against a consistent interface while the service can improve routing, serving, safety controls, and observability behind that boundary.
This is not obscurity for its own sake. Publishing operational endpoints or private routing details would not make a customer integration more reproducible; it would weaken the service boundary. Reproducibility belongs in the evaluation artifact: versioned prompts, datasets, settings, metrics, and aggregate outcomes.
## Real-world evaluation
Public leaderboards are useful signals, but they often contain short prompts, narrow answers, or tasks that do not represent a real work session. Mibyan evaluation should therefore include held-out tasks derived from real Arabic workflows: reports, plans, extraction, bilingual rewriting, calculations, and multi-step agent tasks.
Each release should be evaluated with the same harness across Mibyan and selected frontier references. The harness must record the model ID, prompt version, dataset version, sample count, decoding settings, tools, judge rubric, and failure categories.
The graphic shows the evaluation structure, not numerical model results. Published scores belong on the [benchmark page](/models/benchmarks) only after the corresponding run is complete and reproducible.
## Performance and cost
For an interactive platform, quality is only one part of performance. Report quality alongside time-to-first-token, total latency, streaming stability, error rate, token usage, and cost per accepted output. For agentic workloads also report steps, tool-call success, recovery rate, and time to completion.
The useful comparison is a Pareto view: how much quality a model delivers for a given latency and cost on the tasks your users actually perform. A general frontier model may lead on breadth while Mibyan may be the better fit for Arabic professional work or a controlled API workflow.
For the engineering treatment of this trade-off, see [efficient serving](/models/efficient-serving). A lean footprint is meaningful only when the workload, concurrency, quality, and reliability conditions are disclosed alongside it.
## Safety and responsible use
Mibyan is intended to support people and applications, not replace controls around consequential decisions. Product teams should use the model inside a system that has scoped access, request correlation, rate and budget limits, validation for structured outputs, and an escalation path for uncertain or high-impact work.
| Risk | Product mitigation |
| --------------------------------- | ----------------------------------------------------------------------------------------------- |
| Hallucinated or stale information | Ground the task in authoritative material and ask for citations or verification |
| Missed instruction | Validate required fields, formats, and business rules in the application |
| Tool misuse | Keep permissions and approvals in the application; treat tool output as untrusted until checked |
| Sensitive decisions | Require human review and preserve an audit trail |
| Operational instability | Use timeouts, retries with backoff, idempotency where appropriate, and request IDs |
## Production use
Use the public model ID `mibyan-4.1` through the OpenAI-compatible API.
Production readiness also requires project-scoped keys, rate and budget controls, request correlation IDs, usage logs, retries with backoff, and application-level validation for structured outputs.
## Limitations
Mibyan can still hallucinate, misunderstand ambiguous prompts, miss a constraint, or produce a linguistically fluent but factually incorrect answer. Do not use aggregate benchmark scores as a substitute for domain evaluation, retrieval from authoritative sources, or human approval in high-impact workflows.