OptiVis
Book a diagnostic

AI engineering · Sugar Land, Texas

We build production AI that proves its own work.

Custom models, private knowledge systems, and the infrastructure to run them in production.

Book a diagnosticSee the work

The work

Three exhibits. Separate systems, not one platform.

Each one states its status, where its data runs, and how it is accepted.

  1. 01Private retrievalAnswers from your own documents, with the passage shown
  2. 02The evaluatorA smaller model taught to make the same calls as Jev
  3. 03One retailerReferral conversion, measured in Shopify attribution

Exhibit 01Private retrieval

Answers from your own documents, with the passage shown.

We build retrieval that answers only from a client’s documents and shows the passage each answer came from. It runs on GPU compute we operate, alongside private inference on open-weight models.

Legal-OS: span-verified retrieval

Built for a Texas law practice. The model may only point to spans in the documents; it is not allowed to write a quotation of its own. Every quote is checked character for character against the source, and a quote that fails the check is refused, visibly.

It does not decide whether a document is the right authority, and it does not replace the attorney’s judgment. That stays with the attorney.

Status
Built for a Texas law practice.
Boundary
Documents are read by OCR in a service with no network access.
Acceptance
A quote that fails the character check is refused, and you see the refusal.

Library Intelligence

Private retrieval over a large document library. OCR, embeddings and search run on compute we operate, and a search returns the passages themselves, each with its source.

Status
Runs on our own library.
Boundary
OCR, embeddings and search on compute we operate.
Acceptance
Every result shows its source passage.

The compute under it: a GPU job router

Our own work runs on GPU compute we operate, scheduled by a job router we wrote. Before it sends work to a machine, it proves the machine with a real computation. It splits jobs into checkpointed units, retries a failed unit on a different machine, and keeps a ledger you could reproduce.

How a job run is checked
  1. 01 Machine proofA real computation runs before work is sent.
  2. 02 CheckpointWork is split into units that save their state.
  3. 03 Failed unitEXCEPTIONOne unit fails. The exception stays on the record.
  4. 04 Retry on another machineFROM CHECKPOINT 02The unit resumes from its checkpoint elsewhere.
  5. 05 LedgerEach step is written to a ledger you could reproduce.
Status
Runs our own work.
Boundary
GPU compute we operate.
Acceptance
No machine gets work until it passes a real computation. Every job leaves a ledger.

Exhibit 02The evaluator

We taught a smaller model to make the same calls as the evaluator.

The evaluator is Jev, from TypeSafe AI. The smaller model is ModernBERT-large, distilled from 68,828 Jev-labeled training examples, so the same calls run on compute we operate.

It is measured as teacher agreement, not accuracy, on two cohorts, with zero-shot Laya as the baseline.

In-KB n = 4,387

ModernBERT-large, distilled89.0%
Laya, zero-shot52.1%

Unseen KB n = 1,301

ModernBERT-large, distilled80.0%
Laya, zero-shot49.3%

The limit. Rare flags are not claimed.

Teacher agreement with Jev, not accuracy: how often the smaller model makes the same call as Jev, not whether Jev is right. Bars start at zero on the same scale.
Status
Measured. The figures are published on OptiVis AI Labs.
Boundary
Trained and run on GPU compute we operate.
Acceptance
Teacher agreement on two cohorts, against a zero-shot baseline.

The research on OptiVis AI Labs

Exhibit 03One retailer

Commerce is an application of the work, not a practice.

An auto-parts retailer whose Shopify store we build and run. One measured window, both denominators, and the limit of what it shows.

Referral sourceOrdersSessionsConversion
ChatGPT1915112.58%
Google search763,9881.91%

Shopify session report, Q3 2026: ChatGPT, 19 orders from 151 sessions, 12.58%; Google search, 76 orders from 3,988 sessions, 1.91%.

The limit. Attribution shows where orders came from. It does not prove profit, and it does not prove that our work caused them. Small sample, one store, one quarter.

Status
We build and run the store.
Boundary
The client’s store and the client’s Shopify data.
Acceptance
Re-measured from Shopify attribution each quarter, whatever it shows.

Conversations the systems are built to handle

Intake, a discovery deadline and a parts-fitment question, from PI ENGINE, LITIGATOR and our commerce systems.

Examples. Names and details changed.
ExampleIntake · PI ENGINE
2:13
‹
L
Lead · (281) 555-0142
iMessage›
ExampleDiscovery deadline · LITIGATOR
10:02
‹
PM
Paralegal · Maria
iMessage›
ExampleFitment check · Parts store
7:52
‹
C
Customer · (832) 555-0126
iMessage›

Engineering standard

One standard under every system.

Evaluation

A system is measured against a baseline before we call it done, the way the distillation above was measured against zero-shot Laya.

Evidence-backed retrieval

Answers point to the passages they came from. A quote that does not match its source is refused, not shown.

Written acceptance

Acceptance tests are written down before the build, and the build is accepted against them.

Models and platforms we build with

Frontier models

Claude AnthropicGPT and Codex OpenAIGrok xAIKimi Moonshot AIPerplexity Web research

Decision and evaluation

Jev TypeSafe AILaya Convai, open sourceBlind evaluation harness OptiVis

Open-weight models we host

ModernBERT-large Answer.AI and LightOnQwen3 Alibaba QwenQwen-Image Alibaba QwenDeepSeek-OCR DeepSeekPaddleOCR-VL Baidu PaddlePaddledots.ocr rednote hilabWhisper OpenAIBGE-M3 BAAISAM MetaLlama 3.2 MetaPhi Microsoft

Compute

CUDA GPUs NVIDIAGPU job router OptiVisRunPod Burst GPUs

We choose the stack around your workflow, data boundaries, and acceptance tests. Open-weight models are pulled from Hugging Face and run on GPU compute we operate.

Written data boundaries

The boundary is a document, one per engagement.

“Private” is a claim a procurement reviewer should test, so we write it down. For every system we build, a data-boundary document states where each component runs, which model calls leave your environment and to which provider, and how OCR, embeddings, logs, backups and support access are handled, with retention and deletion. You get the first version in the diagnostic, before anything is built.

Client data is processed only within the deployment boundaries agreed in writing. Any external provider, data transfer, and retention policy is documented before use.

Component placement
Where each component runs
Model calls
Which provider receives which data
OCR
Where processing occurs
Embeddings
Where vectors are stored
Logs
What is retained
Backups
Where copies reside
Support access
Who can access what
Retention and deletion
Duration and removal procedure

These are the fields each document answers, not a record of a particular deployment.

People

The people on this page are the people who build your system.

  • Portrait of Abdullah Siddiqui

    Abdullah Siddiqui

    Founder, CEO & Head Systems Architect

    Designs the architecture and the AI systems.

  • Portrait of Alexis George Cownan, Esq.

    Alexis George Cownan, Esq.

    Trial Counsel

    Practicing Texas trial attorney. Co-developed LITIGATOR and decides what in a legal workflow gets automated and what stays with the attorney.

  • Portrait of Hasan Abdul Kadir

    Hasan Abdul Kadir

    Director of Logistics and Technologies

    Oversees deployment, testing and client onboarding.

About the firm

Engagement

How an engagement is priced.

  1. Diagnostic

    $7,500

    Ten business days, one workflow. Credited in full against a build signed within 60 days.

  2. Production build

    From $25,000

    Fixed price, accepted against tests written before the build.

  3. Operate

    From $2,500 a month

    Bounded and optional.

Start with the diagnostic.

One workflow, with its data boundary written down before anything is built.

Book a diagnostic