Sort AI
Get in touch

R&D · Sort AI Lab

The models and data we're building to run the work, not just assist it.

In development

Frontier models have read the public internet. They have never read a facility agreement's EBITDA definition or a 3 a.m. shift log from a hot-rolling mill. That knowledge lives inside the firms we deploy into, so that is where we build. Everything on this page is in development.

Where the data lives

Trading desks and factory floors, connected from DIFC.

The documents behind a deal and the signals behind a breakdown sit in different buildings, but the problem is the same: the knowledge lives in the work, not in a public dataset. We build from both. Drag the globe to explore.

  • Sort AI · DIFC, Dubai
  • Financial centres
  • Industrial hubs

01Why a lab

Selling a tool is a race against the next model. Selling the outcome is not.

A copilot hands a professional a tool and hopes they use it. An AI-native company delivers the finished work, such as the reconciled credit file or the approved work order, and gets cheaper and better every time the models improve. When a frontier lab ships a better model, we put it inside the harness the same week. What it won't arrive with is a bank's covenant definitions, a plant's failure history, or thousands of expert corrections. That part is ours.

  1. 01

    Outcome, not software

    We are paid for the spread that ties out and for the failure caught two weeks early, not for logins. That forces us to measure the result instead of the demo.

  2. 02

    Data nobody publishes

    Compliance certificates, data-room schedules, historian tags and maintenance logs are the raw material of the work. No foundation model has seen them, and that is the gap we close.

  3. 03

    The deployment is the lab

    Our forward deployed engineers sit next to the analyst and the shift planner. Each correction they watch becomes training signal, with the client's consent.

  4. 04

    Better base models make us stronger

    Our models sit on top of the best open and frontier foundations and specialise them. Each new base model raises our floor, and our data and evaluations keep the ceiling ours.

02Model families · in development

Two foundation models and the proprietary data underneath them.

One for the documents that move capital, one for the machines that make things, and the proprietary record that teaches both. Every figure below is a target we hold ourselves to, not a result.

In developmentSAI-M1

MIZAN™

Arabic for balance, the scales

Financial services · Financial-document foundation model

Reads deal and credit documents the way a second-year associate wishes they had time to.

Now: Continued pre-training on financial documents, then definition-level fine-tuning

Target
100% of findings linked to a source page
Target
≥ 98% field accuracy vs double-keyed analyst spreads
Target
AR · EN from the first release

From the floor

On a sell-side mandate the CIM is the easy part. The work is the data room: two thousand files, half of them scans, where the change-of-control clause that reprices the deal sits in a schedule to a supplier contract nobody opened. Then a quarter later the credit team re-keys the same financials to test covenants, because 'Consolidated EBITDA' in one facility agreement allows capped run-rate synergies and in the next it doesn't. General models read these documents like web pages. They miss the definitions, and the definitions are where the money is.

Trained on

  • Facility agreements and their definitions
  • Data-room schedules and disclosure letters
  • Audited vs management accounts, reconciled
  • Arabic and English filings

Under the hood

  1. 01

    Ingest

    OCR + layout parsing of scans, tables and footnotes, Arabic and English; every token keeps its page coordinates

  2. 02

    Definition graph

    Clause segmentation; defined terms (Consolidated EBITDA, Permitted Acquisition) resolved into a cross-reference graph

  3. 03

    Embed + retrieve

    Domain-tuned embeddings, hybrid BM25 + vector search over a per-deal index held in the client's tenancy

  4. 04

    Model

    Open-weight LLM, continued pre-training on financial text, LoRA fine-tune; constrained JSON decoding to a fixed chart of accounts

  5. 05

    Verify

    Cross-footing (totals must reconcile) and citation checks against page coordinates before anything is shown

  6. → Result

    Outcome

    A red-flag report and a reconciled spread on the analyst's desk the morning after the data room opens, with every number linked to its page and the covenant headroom recalculated under that facility's own definitions.

Base
Open-weight, vendor-agnostic; frontier APIs where policy allows
Training
Continued pre-training → SFT on definition-level labels → preference tuning on ATHAR edits
Context
Whole data room via retrieval; long-context pass on each agreement
Evaluation
Field-level F1 vs double-keyed spreads; citation precision; held-out facility agreements
In developmentSAI-S1

SINA™

From sinā'a, Arabic for industry

Manufacturing · Industrial time-series foundation model

Joins what the sensors saw with what the night shift wrote down.

Now: Pre-training corpus: aligning sensor, log and work-order timelines across plants

Target
≥ 14 days warning on critical rotating-equipment failures
Target
< 1 false alarm per asset per month
Target
0 work orders issued without a planner's approval

From the floor

A plant historian logs thousands of tags every second and almost none of it is read until something trips. Why a line stopped is rarely in the sensor data alone. It is in the shift log: 'abnormal noise on ID fan, greased, monitor', written at 3 a.m. in a mix of English, Arabic and Urdu by a technician who has since gone home. Critical spares can take months to arrive, so a failure you could have seen two weeks earlier becomes weeks of lost output. Generic forecasting sees a curve. It doesn't know the 'anomaly' every Thursday is the cleaning cycle, or that a furnace behaves differently after a reline.

Trained on

  • Historian time-series at second resolution
  • CMMS work orders and failure codes
  • Multilingual shift and maintenance logs
  • OEM manuals and plant SOPs

Under the hood

  1. 01

    Ingest

    Historian tags over OPC UA / PI, resampled and unit-normalised; CMMS work orders; raw shift logs

  2. 02

    Read the logs

    Multilingual entity extraction on code-switched English, Arabic and Urdu, mapped to the asset hierarchy and ISO 14224 failure modes

  3. 03

    Align

    Event-time join: each log entry matched to its sensor window and the work order that followed

  4. 04

    Model

    Patch-based time-series transformer pre-trained across plants, fused with a log-text encoder, fine-tuned per asset class

  5. 05

    Decide

    Remaining-useful-life estimate with a calibrated alarm threshold, drafted into a work order with its evidence

  6. → Result

    Outcome

    A prioritised work order raised before the failure, with the trend, the matching shift-log entries and the likely cause attached, approved by the maintenance planner and not by the model.

Base
Time-series foundation model + small multilingual text encoder
Training
Self-supervised pre-training on unlabelled sensor history → supervised on recorded failures
Inputs
Second-resolution sensor windows, maintenance text, asset metadata
Evaluation
Back-tests on past failures: lead time, false alarms per asset per month
In developmentSAI-A0

ATHAR™

Arabic for trace, the mark left behind

Across every deployment · Proprietary dataset

The record of experts correcting the machine: judgement, labelled.

Now: Capture schema live in the first deployments

Target
Every approval and edit captured as a decision trace
Target
100% of pooled data with written client consent
Target
Each model release evaluated on real decisions

From the floor

Every deployment produces something no model has seen: a professional overruling a draft. When a credit analyst strikes an add-back, or a planner downgrades a work order from urgent because the spare is already on site, that edit is the most valuable data in the building. Most firms throw it away in an email thread. ATHAR keeps it as a structured decision trace: the input, the draft, the edit, the reason given, and what actually happened three months later.

Trained on

  • Approvals, edits and rejections
  • The reason the expert gave
  • The outcome, captured after the fact
  • Kept in the client's tenancy unless they opt in

Under the hood

  1. 01

    Capture

    The harness logs every draft, edit, approval and rejection as an event, with who made it and when

  2. 02

    Diff + reason

    Structured diff between the model's draft and the expert's final version, plus a reason code and free text

  3. 03

    Link outcome

    Joined later to what happened: the covenant breach, the bearing failure, the alert outcome

  4. 04

    Store

    Per-client, encrypted, in-tenancy; PII redaction and consent flags on every record

  5. 05

    Reuse

    Becomes held-out evaluation sets and draft-vs-corrected preference pairs for tuning MIZAN and SINA

  6. → Result

    Outcome

    Evaluation sets built from real decisions rather than invented benchmarks, so every MIZAN and SINA release is judged against the people it is meant to help.

Unit
Decision trace: input → draft → edit → reason → outcome
Used for
Evaluation sets, preference tuning (DPO-style), error analysis
Governance
Client-owned; pooled only with written consent
Quality
Inter-annotator agreement tracked per task

03The harness

Every model ships through one control layer.

In developmentHarness

SORT HARNESS™

The control layer every model and agent of ours runs inside.

Models change every few months, but how a bank or a plant lets software act shouldn't. The harness is model-agnostic: it runs frontier models where the client allows them and our own where it doesn't, inside the client's cloud.

  • Evaluation gates

    A release ships only if it beats the last one on held-out decisions from ATHAR. A good demo doesn't count.

  • Citation or nothing

    Any claim without a source page, cell or sensor window is dropped before a person sees it.

  • Human approval

    Credit files, work orders and alerts need a named person's sign-off before they leave the system.

  • Full audit trail

    Prompt, sources, draft, edit and approval are stored together, ready for a regulator or an insurer.

  • Model routing

    Each task goes to frontier or open-weight models according to cost, latency and the client's data policy.

  • Runs in your tenancy

    Deployed in the client's cloud or on-premise. Nothing leaves unless they say so.

04Research notes

Working notes, in preparation.

What we're learning in the deployments, written up as we go. Published once the results hold up.

  1. 01

    EBITDA isn't one number: definition-aware extraction from facility agreements

    MIZAN · Draft
  2. 02

    Reading the night shift: fusing maintenance logs with historian data to buy failure lead time

    SINA · Draft
  3. 03

    Edits as labels: capturing decision traces in regulated deployments

    ATHAR · Draft

05From the lab

Work in progress.

A look at the lab's internal tooling. Results are published after the design-partner pilots, not before.

sort-lab · internal CLI · illustrative

$

Looking for design partners.

We are choosing a small number of banks, funds and manufacturers to pilot MIZAN and SINA on their own documents and plant data, inside their own cloud.

Get in touch