Skip to content

Dayan Ibrar / Research & engineering

AI & machine learning research engineer

Reliable data pipelines, AI, and ML models. Built from the data up.

I'm Dayan. I build production data systems and applied AI, and study what makes them reliable. My work connects data engineering, graph analysis, and machine learning with questions worth investigating.

Fig. 01 / Software intelligenceConcept map
SOFTWARECONTEXTQUESTIONSINSIGHTCONNECTED SYSTEMSREVISIT THE ASSUMPTIONS

An illustration of connected software systems.

Software / context / understanding

Built in practice

Federal & aerospace data systems

Investigating now

Reliable ML, graphs & evidence

Documenting along the way

Research notes, experiments & lessons

Continuing practice / 14 credentials & recognitions

Learning, put into practice.

Research / Current investigations

Questions becoming systems.

Research index

Three connected directions: understanding complex systems, tracing evidence through software, and building a foundation for biomedical research.

Expertise / from source to system

Full-stack engineering.
From data to deployment.

I design and build across the stack: data pipelines, ML systems, backend services, frontend applications, and cloud infrastructure. My work carries through deployment, security, and production operations. Explore the disciplines behind that end-to-end practice.

End-to-end delivery

  1. Data

    Ingest · model · transform

  2. ML & AI

    Train · retrieve · evaluate

  3. Build

    Interfaces · APIs · services

  4. Deploy

    Cloud · infrastructure · CI/CD

  5. Operate

    Observe · secure · improve

Engineering disciplines

07 connected areas of practice
Read AI / ML details

Hover or focus to explore. Click to pin; click again or press Escape to release.

01 / AI & machine learning

What would make this answer defensible?

Retrieval, representation learning, and evaluation belong together. I work from a baseline toward hybrid retrieval, reranking, and claim-level checks; deep learning is useful when its assumptions fit the problem.

What I check

Inspect recall@k, citation faithfulness, and failure cases. A cited source still has to support the claim.

  • Atomic Retrieval Fabric
  • CRAG
  • GraphRAG
  • Hybrid Retrieval
  • BM25 + Dense
  • SPLADE
  • ColBERT
  • RRF Fusion
  • Cross-Encoder Rerank
  • Claim-Level Verification
  • Evidence Packets
  • Model Routing
  • Model Hub
  • MCP Agents
  • LangGraph
  • Evals (recall@k · groundedness)
  • Citation Faithfulness
  • PyTorch
  • Hugging Face
  • ONNX Runtime
  • TensorRT
  • SageMaker
  • pgvector
  • Qdrant
  • Embeddings
  • Fine-Tuning / PEFT
  • Quantization
  • Transformers
  • NLP
  • Computer Vision
  • Anomaly Detection
  • Cryptographic Evidence (BLAKE3 · Merkle)
  • Ollama
Explore Structura

What I do / Data · GenAI · Full-stack

From raw data to proven answers.

I build by the evidence: understand the mathematics, test the assumptions, and inspect what fails. These are the decisions behind the tools.

Retrieval that can be checked.

An answer should lead back to the material that supports it. I build around addressable evidence: a page region, a table cell, a JSON path. Retrieval, generation, and verification are separate responsibilities.

BM25, dense embeddings, and learned sparse retrieval offer different signals. Fuse the rankings, rerank the candidates, and check each claim against its cited source. A citation is a starting point for verification, not proof by itself.

retrieval.rsRust · pseudocode
// Retrieve first. Evaluate support separately.let hits = rrf_fuse(&[    bm25.search(query),    dense.search(query),    sparse.search(query),]);let evidence = rerank(query, hits);let draft = generate(query, &evidence);match check_support(&draft, &evidence) {    Supported => release(draft.with_citations()),    Insufficient => abstain("missing evidence"),}
retrieval_eval.pyPython · illustrative check
# A useful result is a reproducible one.def recall_at_k(retrieved, relevant, k):    if not relevant:        return None  # no labeled positives    hits = set(retrieved[:k]) & set(relevant)    return len(hits) / len(set(relevant)) # Report by query slice, not only an average.# Inspect misses and unsupported citations.# Keep the corpus and label versions fixed.

Illustrative patterns. Simplified for reading; these are not public SDK contracts or performance results.

Interactive study / Retrieval

Ask the fabric.

Pick a question. Inspect its sources. See where the answer has to stop. The useful part of retrieval is the connection you can check.

Scripted demonstration. Synthetic records and prewritten answers; no live model, database connection, or patient data. The clinical example illustrates data lineage, not medical advice.

Choose a question

The fourth question has no supported answer. That is part of the demonstration.

structura / evidence walkthroughfixture 01 · browser only

Where does the OSA severity flag come from?

Release a bounded answer with inspectable citations, or explicitly abstain. A well-formed citation still needs a support check.

Source atoms / Select to inspect

Sample answer / Inspect the citations

In this fictional record, the report states an AHI of 34.2 and a severe OSA finding . The table preserves that value and its source locator . The ETL copies the extracted finding into the severity field . This explains the record's lineage; it does not establish a clinical diagnosis.

3 source atoms citedPrewritten example · not an evaluation result

The verification question

The report, stored value, and transform support the narrow claim about where this field came from.

Mathematics / Methods / Evidence

Start with the mechanism.
Then test the claim.

Building by evidence means understanding the mathematics, reading the research, and designing an experiment that could show me I am wrong. I want to know what a model optimizes, what its data leaves out, and which failure matters to the person using it.

01 / Learning objective

Choose what to minimize.

J(θ) = (1/n) ∑ᵢ ℓ(fθ(xᵢ), yᵢ) + λΩ(θ)

Across n examples, loss ℓ measures error; Ω penalizes complexity, with strength λ. A lower training objective still needs to earn its value on held-out data.

Logistic regression · Gradient boosting · Neural networks · SGD / Adam · Regularization

Deep Learning, ch. 8

02 / Representation

Understand the operation.

Attn(Q, K, V) = softmax(QKᵀ / √dk)V

Queries Q and keys K produce weights over values V; dk is the key dimension. That mechanism explains a computation. Its usefulness still has to be evaluated on the task.

Deep learning · Transformers · Embeddings · Backpropagation · Fine-tuning / PEFT

Attention Is All You Need

03 / Decision & evaluation

Make the tradeoff explicit.

Precision = TP / (TP + FP)

Recall = TP / (TP + FN)

True positives (TP), false positives (FP), and missed positives (FN) expose different costs. The threshold is a decision; class balance and the evaluation split belong beside the result.

Temporal validation · Leakage checks · PR curves · Calibration · Error analysis

Introduction to Information Retrieval

Worked example / Synthetic data

Same scores. Different decisions.

Move the threshold to classify ten fixed examples. Each square is one example; the outline marks a predicted positive. These are teaching values, not a project benchmark.

−
0.12
−
0.22
+
0.31
−
0.43
+
0.54
−
0.61
+
0.72
+
0.81
−
0.88
+
0.96

+ labeled positive · − labeled negative · red outline: predicted positive

Precision

0.67

Recall

0.80

TP / FP / FN

4 / 2 / 1

My working discipline: establish a baseline, isolate the change, inspect failures, and record the data, configuration, and limitations with the result.

Architecture / Interfaces & invariants

Systems thinking.

The useful question is what happens between the boxes: who can act, what can fail, and how the result can be checked.

Reference architecture · 16 components / 5 tiersIllustrative relationships, not a deployed topology

01 / Client

02 / Edge / gateway

03 / Services

04 / Data layer

05 / AI / ML

Inspecting / Services

AI service

Coordinate retrieval, models, and tools with bounded execution. Record evidence and evaluation decisions so failures can be investigated beyond the final text.

The design question

What can this service claim, and when must it abstain?

Hover or focus to trace relationships. Select a component to inspect its purpose, assumptions, and neighboring services.

Engineering philosophy

Built to spec.
Tested against evidence.

Aerospace engineering shaped how I think about software: understand the requirement, make the interfaces explicit, and test what happens when assumptions break.

For machine learning, that means looking beneath a score. What objective did we optimize? What information was available? Which errors matter? The mathematics explains the method; experiments establish its limits.

The experience behind the practice
Study 01 / Propulsion
An illustrative F135-inspired turbofan study. A reminder to reason across interfaces, operating conditions, and failure modes.

Requirement

What must hold?

Model

Under which assumptions?

Evidence

How would we know?

01 / Working principle

State the requirement.

Define the operating conditions, failure modes, and acceptance criteria before choosing an architecture.

02 / Working principle

Make the model explicit.

Start with the mathematics or mechanism. Record assumptions, units, uncertainty, and where the model stops being useful.

03 / Working principle

Try to disprove it.

Compare against a baseline. Test boundaries, inspect errors, and keep enough evidence for someone else to repeat the check.

Technologies / working inventory

Tools I work with.

Chosen for the work: a query engine for the data, a runtime for the workload, an interface for the person using it. The interesting part is how the pieces meet.

01

Languages & interfaces

Express the model. Make the result usable.

  • Python
  • Rust
  • Go
  • TypeScript
  • Scala
  • React
  • Next.js
  • Node.js

02

ML, retrieval & agents

Represent, retrieve, evaluate, and serve.

  • PyTorch
  • Hugging Face
  • LangGraph
  • MCP
  • ONNX Runtime
  • TensorRT
  • SageMaker
  • Ollama
  • pgvector
  • Qdrant

03

Data & storage

Move data with its meaning intact.

  • Apache Spark
  • Apache Kafka
  • Polars
  • DuckDB
  • Airflow
  • dbt
  • Redshift
  • Databricks
  • PostgreSQL
  • Redis
  • AWS Glue
  • Athena

04

Services & runtime

Control concurrency and define boundaries.

  • Tokio
  • Axum
  • PyO3
  • FastAPI
  • Tonic gRPC
  • REST
  • SOAP
  • NixOS
  • QEMU
  • BLAKE3

05

Cloud & delivery

Provision, release, observe, recover.

  • AWS GovCloud
  • GCP
  • IBM Cloud
  • AWS Lambda
  • S3
  • EC2
  • RDS
  • MSK
  • Terraform
  • Terragrunt
  • Docker
  • Kubernetes
  • GitLab CI/CD

06

Identity & assurance

Make permissions and evidence inspectable.

  • KMS
  • Vault
  • Keycloak SSO
  • SigV4
  • Ed25519
  • XChaCha20
  • Zero-Trust
  • Tamper-Evident Audit

Selected systems / Applied engineering

Retrieval, governed development, and computing at the disconnected edge. These technical write-ups describe the implementation choices behind Structura, Praxis, and AegisOS.

SYS-01Engineering system

Structura

Atomic Retrieval Fabric

The evidence layer for production AI — sources stay addressable as atoms, every claim is verified, and BLAKE3 + Merkle proofs make each answer replayable.

  • Rust
  • ONNX
  • Qdrant
  • BLAKE3
  • hybrid retrieval
SYS-02Engineering system

Praxis

Evidence-Native Dev Platform

Learns a business, builds a governed knowledge fabric and graph, stands up grounded agents, and runs a software factory that ships reviewable code.

  • TypeScript
  • Python
  • LangGraph
  • MCP
  • pgvector
SYS-03Engineering system

AegisOS

Offline-First Secure Edge OS

A Rust-first AI operating system for the disconnected edge — cryptographic node identity, tamper-evident timeline, encrypted vault, multi-path mesh, offline RAG.

  • Rust
  • Tokio
  • Ed25519
  • NixOS
  • Ollama

Further engineering work

The rest of the hangar.

All systems
PRJ-04Project record

Medical RAG

Clinical retrieval pipeline

Retrieval-augmented pipeline over clinical documents — semantic chunking, hybrid retrieval with reranking, and LLM synthesis under PHI guardrails with enforced citations.

  • Python
  • pgvector
  • Claude
  • FHIR/HL7
PRJ-05Project record

Mortgage Platform

Full-stack lending system

A lending workflow connecting application intake, document verification, risk assessment, and underwriting review.

  • Next.js
  • Node
  • PostgreSQL
  • Document AI
PRJ-06Project record

ViDaT

Data & visualization tooling

Visual data tooling for engineering teams — turning raw pipeline output into explorable, decision-ready views.

  • TypeScript
  • React
  • Data Viz
PRJ-07Project record

SignalForge

Signal & data processing

Processing infrastructure for high-volume signal data — ingestion, transformation, and analysis built for throughput.

  • Python
  • Pipelines
  • AWS
PRJ-08Project record

Neuro Sentinel

AI monitoring system

Intelligent monitoring — anomaly detection and alerting over live operational data streams.

  • Python
  • ML
  • Streaming
PRJ-09Project record

Guardis

Security tooling

Defense-minded security tooling — policy, visibility, and enforcement primitives for hardened environments.

  • Security
  • IAM
  • Infrastructure

Writing / In the spotlight

The latest collection.

15 selected essays on the decisions behind data systems, machine learning, and applied AI—from the first data contract to the evidence behind an answer.

All writing

Contact / An open conversation

There is always
a better question.

I'm interested in research engineering opportunities and collaborations in data, machine learning, and reliable AI.