01 / Computational research
AXIOMERIS
An independent research initiative at the intersection of data, machine learning, and complex systems.
Early-stage research · public overview
Research overviewDayan Ibrar / Research & engineering
AI & machine learning research engineer
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.
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
Research / Current investigations
Three connected directions: understanding complex systems, tracing evidence through software, and building a foundation for biomedical research.
01 / Computational research
An independent research initiative at the intersection of data, machine learning, and complex systems.
Early-stage research · public overview
Research overview02 / Software systems
An ongoing investigation into software relationships, engineering judgment, and reliable AI-assisted development.
Early-stage research · public overview
Research overview03 / Biomedical data
An early-stage exploration of biomedical data, research evidence, and responsible applications of machine learning.
Early-stage research · public overview
Research overviewExpertise / from source to system
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
Ingest · model · transform
Train · retrieve · evaluate
Interfaces · APIs · services
Cloud · infrastructure · CI/CD
Observe · secure · improve
Engineering disciplines
07 connected areas of practiceHover or focus to explore. Click to pin; click again or press Escape to release.
01 / AI & machine learning
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.
What I do / Data · GenAI · Full-stack
I build by the evidence: understand the mathematics, test the assumptions, and inspect what fails. These are the decisions behind the tools.
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.
// 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"),}# 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
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.
Where does the OSA severity flag come from?
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.
The verification question
The report, stored value, and transform support the narrow claim about where this field came from.
Mathematics / Methods / Evidence
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
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. 802 / Representation
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 Need03 / Decision & evaluation
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 RetrievalWorked example / Synthetic data
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.
+ 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
The useful question is what happens between the boxes: who can act, what can fail, and how the result can be checked.
01 / Client
02 / Edge / gateway
03 / Services
04 / Data layer
05 / AI / ML
Inspecting / Services
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
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 practiceRequirement
What must hold?
Model
Under which assumptions?
Evidence
How would we know?
01 / Working principle
Define the operating conditions, failure modes, and acceptance criteria before choosing an architecture.
02 / Working principle
Start with the mathematics or mechanism. Record assumptions, units, uncertainty, and where the model stops being useful.
03 / Working principle
Compare against a baseline. Test boundaries, inspect errors, and keep enough evidence for someone else to repeat the check.
Technologies / working inventory
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
Express the model. Make the result usable.
02
Represent, retrieve, evaluate, and serve.
03
Move data with its meaning intact.
04
Control concurrency and define boundaries.
05
Provision, release, observe, recover.
06
Make permissions and evidence inspectable.
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.
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.
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.
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.
Further engineering work
Clinical retrieval pipeline
Retrieval-augmented pipeline over clinical documents — semantic chunking, hybrid retrieval with reranking, and LLM synthesis under PHI guardrails with enforced citations.
Full-stack lending system
A lending workflow connecting application intake, document verification, risk assessment, and underwriting review.
Data & visualization tooling
Visual data tooling for engineering teams — turning raw pipeline output into explorable, decision-ready views.
Signal & data processing
Processing infrastructure for high-volume signal data — ingestion, transformation, and analysis built for throughput.
AI monitoring system
Intelligent monitoring — anomaly detection and alerting over live operational data streams.
Security tooling
Defense-minded security tooling — policy, visibility, and enforcement primitives for hardened environments.
Writing / In the spotlight
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.

Systems
Local evidence, signed timelines, delayed transport, and the difference between a working offline prototype and a validated field system.
Archive · · 9 min

AI Systems
A source-to-answer design study of document identity, extraction, retrieval, and citations—and the information an embedding cannot preserve.
Archive · · 9 min

AI Systems
A corrective retrieval protocol that treats missing evidence, contradiction, permissions, and exhausted budgets as different decisions.
Archive · · 9 min
AI Systems
Why similar questions are not necessarily equivalent requests, and how evidence lineage changes cache lookup, invalidation, and evaluation.
Archive · · 9 min
AI Systems
A request-level design for retrieval permissions, model access, tool authorization, network boundaries, and audit evidence in AWS.
Archive · · 10 min
Systems
A design study of deadlines, backpressure, tool contracts, and ambiguous failures before deciding whether a language boundary is worth adding.
Archive · · 9 min
AI & ML
A study protocol comparing simple baselines, frozen embeddings, and learned representations under the same data, shift, and deployment constraints.
Archive · · 10 min
AI & ML
An experiment protocol connecting temporal splits, SMOTE, probability calibration, and the workload an investigator can actually handle.
Archive · · 9 min
AI & ML
A reproducible experiment for choosing distributed preparation, local iteration, and native processing around a SageMaker training workflow.
Archive · · 9 min
Backend
A migration design built around compatibility contracts, change capture, reconciliation, and a cutover that can actually be reversed.
Archive · · 9 min
Backend
Follow one entity through Postgres, Redshift, Cassandra, and a vector index to make ownership, freshness, and semantic meaning explicit.
Archive · · 10 min
AI Systems
A methods note on biomedical concept extraction, ontology, provenance, and why matching a medical term is not the same as validating a claim.
Archive · · 9 min
AI Systems
A general evaluation protocol for separating dependency coverage, impact ranking, and verification, with explicit limits on what each can establish.
Archive · · 9 min
AI Systems
A research agenda built around bounded claims, meaningful baselines, traceable experiments, and results that remain useful when a hypothesis fails.
Archive · · 10 min
AI & ML
AI runs on data, but trust is what makes that data usable. As LLMs and AI pipelines scale, cryptographic inventory is becoming essential for visibility, governance, and long-term resilience.
· 2 min
Experience & résumé
Federal, aerospace & enterprise engineering
Credentials & lessons
Formal learning and the practice behind it
The visual lab
More interactive engineering demonstrations
Writing / Notes from the work
What dependency analysis is teaching me about separating missing evidence from poor decisions.
Why provenance, data availability, and experimental boundaries belong in the first version.
A working approach to connecting research domains without pretending their problems are identical.
Contact / An open conversation
I'm interested in research engineering opportunities and collaborations in data, machine learning, and reliable AI.