Introduction

Nabra converts natural human speech into validated structured data that matches a schema you define. You describe the data you need — fields and their types. People talk the way they normally do, in Arabic dialect or English. You get back JSON in the shape of your schema, with every value checked against what was actually said.

The pipeline

1. Schema — you define what to extract (or use a built-in example).
2. Speech-to-text — a replaceable speech model (faster-whisper today) that detects the spoken language. Text input skips this step.
3. Language and dialect detection — English, Arabic or mixed; for Arabic, the dialect family and dialect when the evidence is clear.
4. Extraction — a language model maps what was said onto your fields.
5. Normalization and validation — deterministic code turns values into canonical forms (phones, dates, amounts) and checks each one against the transcript. This step decides what survives.
6. Result — every field with a status, a confidence and requiresConfirmation; the missing fields; and data, the plain JSON for your application.

The language model understands; code normalizes, validates and enforces the schema; your application runs the business logic. That split is deliberate.

What it does not do

Nabra never creates orders, books appointments, charges money, assigns drivers, updates your database or sends notifications. It knows nothing about the domain of a schema — delivery, restaurants, clinics or HR are all just schemas. Your application receives the data and decides what happens next.

Any language, no setup

English, Arabic in its Levantine and Gulf dialects, and speech that mixes both are detected per request. You send a schema and the input — never a language. See Languages & dialects.