SHAYANAHMED — AI engineer building AI systems end to end: training-data pipelines, model training and evaluation, and reasoning systems for regulated work
I build AI systems end to end — scraping and cleaning the data, training and adapting the models, then putting them to work on real tasks, including the regulated ones where the system has to show its working.
Most portfolios blur what was built with what was merely proposed. This one marks every claim.
Warm marks are work that exists and I touched. Cool marks are work that was reasoned about. Use the evidence floor in the rail to strip this page down to what I personally shipped — 27 of 27 claims shown — all claims.
Client work delivered through Origins Market Place & Technology, Dubai. One product name is withheld under confidentiality; detail and references on request.
ZBX
Models → Real work
A regulated crypto exchange and payments operation. I was hired to run the work, which turned out to be the only reliable way to learn which parts of it should stop being run by a person — and, in the case of beneficial ownership, which parts should never have been left to a language model at all.
- Role
- Operations Specialist
- ORION-KYB
- Architect & lead engineer
- Status
- In development, not deployed
- Security
- Guardrails, built & tested
- Support agent
- Phase 1 live in production
- Worked with
- A Senior AI Engineer
Corporate onboarding at a regulated exchange is document work: reading incorporation papers and shareholder registers, tracing ownership up through corporate parents to the real beneficial owners, and noticing what is missing or out of date. Ownership does not stay in a tree, though. It loops — companies hold each other — and registers publish ranges rather than numbers, so the arithmetic everyone reaches for first quietly gives the wrong answer.
Support queues have the same document-work shape at a lower stake: a handful of questions where an operator checks the same three systems in the same order. Both are high volume and standardised, which makes them automatable. Both also carry regulatory risk, which means the automation may prepare the decision but must never be the one that makes it. That boundary is the design.
- Built
Ran day-to-day exchange operations: deposit and withdrawal exception handling, stalled SEPA transfers, missing crypto memos and tags, virtual IBAN reconciliation and transaction investigation. This is where the automation work came from — I had already worked every one of these queues by hand.
- Built
KYB workflow discovery: gathered the corporate onboarding workflows, identified the bottlenecks and repetitive steps, analysed the documentation requirements, and defined where automation could carry the load without touching the compliance decision itself.
- Researched
Audited the prior KYB extraction design and found the failure was structural, not tuning: its validation step required declared shareholdings to sum to exactly 100%, which measurably rewarded the model for inventing a shareholder to close the gap. Also mapped the system against the live back-office schema across ten data categories, finding seven defects — including a wrong-company document inflating an onboarding completeness score.
- Designed
ORION-KYB, the replacement architecture: a seven-stage determination pipeline — ingestion, grounded extraction, verification, entity resolution, graph reasoning, screening, review — in place of a design that had an LLM generate per-document parsing scripts and execute them in microVMs. Ingestion detects then branches, routing digital-text PDFs directly and scanned documents through OCR with page-level retrieval; extraction runs in two passes, a citation pass then a structured-output pass, because the API cannot serve both at once.
neuro-symbolic · grounded extraction · citation verification · entity resolution
- Designed
A bi-temporal, append-only ownership graph that separates when a fact was true from when the system learned it. That distinction is what lets the system answer the question a regulator actually asks after the fact: why was this change not acted on sooner?
- Built
Integrated-ownership propagation over cyclic shareholding networks, using the Brioschi input-output formulation rather than multiplying along chains — which silently under-reports whenever ownership loops back on itself. On the reference case it recovers a 91.81% effective holding from a 4.24% direct stake. Closed cross-holdings make the matrix singular; that case is flagged as a laundering typology and routed to review rather than failed.
python · numpy · matrix inversion · spectral radius
- Built
Interval arithmetic throughout the propagation, because registers publish bands rather than numbers — the UK PSC register says 25–50%, not 31%. Proved entrywise monotonicity of the inverse via its Neumann series, and the property is enforced in CI across 20,000 randomised networks rather than asserted in a comment. It also replaced the exact-equality check that had been pressuring the model to fabricate.
interval arithmetic · property-based testing · ci invariants
- Built
A versioned, effective-dated rules engine holding thresholds and jurisdiction lists as data with validity windows, so a determination made under 2026 rules can still be reproduced in 2028. It serves FinCEN CDD, EU AMLR 2024/1624, the UK PSC banded control types, AMLR Article 58 trust roles and the senior-managing-official fallback from one computation — and the same aggregation extends to OFAC's 50% Rule and the BIS Affiliates Rule.
fincen cdd · eu amlr · uk psc · ofac 50% · bis affiliates
- Designed
The threat model, covering three classes the prior design left out: untrusted code execution, prompt injection carried in adversary-supplied PDFs, and adversarial evasion — structuring a holding at 24.9%, diluting it along a chain, hiding it in a closed loop. Invisible instruction payloads are caught by diffing the text layer against what the page actually renders. The pipeline also has no tools that act, so a successful injection can corrupt one extraction but cannot cause a side effect.
threat modelling · owasp llm01 · sandbox isolation · adversarial evasion
- Built
The evaluation harness, sourced from open registers — Companies House PSC daily snapshots and GLEIF Level 2 — and scored on whether the determination was right, not on whether the JSON validated. OCR accuracy is reported separately as the declared ceiling of the pipeline, because no model downstream can exceed it.
companies house psc · gleif · precision/recall on determinations
- Designed
The compliance dossier that pipeline produces — ownership structure, document status, risk flags and supporting evidence, assembled for a compliance officer to decide on. The system recommends; it does not approve.
- Built
Designed and implemented the guardrails on the customer-facing system: defences against prompt injection, against unauthorised access and actions, and against exposure of internal secrets or sensitive information. Then tested those controls against misuse and adversarial scenarios to verify it stayed inside its authorised scope.
prompt injection defence · authorisation scoping · secrets handling · adversarial testing
- Built
Operational discovery on the support side: gathered and analysed real customer queries, identified the recurring problems, mapped how each one actually resolves, and scored the workflows on volume, standardisation and risk to decide what could be automated and what had to stay with a person.
- Built
Collected and organised the operational knowledge the system answers from — the workflows, resolution paths and support data that became its knowledge base.
- Built
Prompt engineering and testing. Wrote and refined the prompts, tested the system myself, found the weaknesses and failure cases, and improved the prompts and workflows from what testing surfaced.
- Contributed
The deployed Phase 1 support agent, built with a Senior AI Engineer who owned the implementation. I contributed through discovery, knowledge preparation, workflow design, prompts, testing and refinement, then supported production readiness and deployment — and I continue to improve it.
llm · rag · vector + bm25 · internal apis · blockchain rpc
GhostDrive
Open web → Training corpus
An agent operating system that runs on the device rather than in the datacentre. Its models are small, so its knowledge has to be dense — which makes the data the product constraint, not a preprocessing step.
- Domain
- AI training data
- Target
- On-device inference
- Output
- JSONL · Parquet · KG triples
- Downstream
- LoRA / QLoRA fine-tuning
A device-resident agent cannot carry a frontier model, so it has to carry better knowledge instead. Indiscriminate scraping produces exactly the wrong corpus for that: high volume, low density, and full of the boilerplate, duplication and leaked secrets that a distributed knowledge network can never redistribute.
My work was on the front of that pipeline — finding, collecting and curating source material dense enough to be worth the team's processing, across role-based operational playbooks, autonomous agent interaction traces, protocol and cryptographic specifications, and dense factual documentation.
- Built
Collected, scraped and curated the source corpus across four verticals — role-based operational playbooks, autonomous agent interaction loops, protocol and cryptographic specifications, and dense factual documentation for knowledge-graph use.
python · crawl4ai · firecrawl · playwright · scrapy · httpx · asyncio
- Built
Organised and prepared that data for the team's processing pipeline, and structured it for repeat ingestion rather than one-off delivery.
- Contributed
The five-stage quality gate — boilerplate removal, PII and secret filtering, exact and near-duplicate detection, density scoring, then entity and relation extraction. This was the team's pipeline. I contributed the data collection, curation and preparation that fed it, not the pipeline itself.
trafilatura · presidio · sha-256 · minhash lsh · gliner · spacy
- Contributed
The continuous refresh and orchestration strategy — incremental crawling with change detection, validation, and quarantine on quality failure. Project architecture I contributed into from the collection side; I did not implement the orchestration.
airflow · temporal · cron
- Researched
Distribution and versioning approaches for a peer-to-peer knowledge network, where datasets are content-addressed rather than served.
dvc · ipfs · filecoin · minio / s3
Generative Identity
Training data → A model that holds identity
The identity layer behind an AI companion platform — a generative image system that has to keep one person recognisably themselves across scenarios it has never seen. The hard part is not generation. It is deciding what counts as the person.
- Product
- AI companion platform
- Domain
- Generative AI · Computer vision
- Base models
- FLUX.1 · SDXL
- Adaptation
- LoRA · IP-Adapter · PuLID
- Identity gate
- ArcFace cosine similarity
Train on photographs where the subject happens to wear sunglasses in half of them, and the model learns that sunglasses are part of the face. Identity and circumstance arrive entangled in every image, and no automated captioner reliably separates them.
The training data had to encode that distinction explicitly — permanent facial structure as identity, everything else as a condition the prompt controls. Most of my work was on that separation, and on the human verification an automated pipeline could not settle.
- Built
The human verification automated tooling could not settle: disentangling temporary attributes — glasses, hats, accessories, makeup — from permanent identity, rejecting motion blur, distortion and over-smoothed skin, and checking crops preserved forehead, chin and hairline across 1:1, 4:5 and 9:16.
label studio · cvat · insightface · mediapipe
- Built
Collection, organisation, curation, labeling and metadata work across the identity anchor and scenario datasets — multi-angle, multi-light reference sets carrying landmarks, head pose, embeddings and aesthetic scores.
arcface · dlib · openpose · dwpose · midas · imagehash · laion aesthetic
- Contributed
The captioning convention that separates permanent identity from conditional attributes, and the dataset layout keeping anchors, scenario presets and control references addressable. I did hands-on work inside this structure — I was not the sole architect of the data schema.
joycaption · llava-next · blip-2 · wd14-tagger
- Contributed
Generative model training and conditioning — LoRA adaptation over FLUX.1 and SDXL, with pose and depth conditioning for scenario control.
kohya_ss · diffusers · controlnet · ip-adapter · face-id · pulid
- Contributed
Model evaluation — ArcFace similarity for identity retention, CLIP alignment for prompt fidelity, and blind A/B comparison against a defect checklist covering identity drift, eye-colour shift, skin-tone mismatch and anatomy errors.
arcface · clip
Adjacent
Work that supports the record without carrying it. Listed at the weight it deserves rather than dressed up to fill a grid.
CLiqsy
QA Engineer · Part-time, concurrent · Jul 2026 — present
Trading as Alpha A CRM — a booking platform for salons, barbers and beauty businesses, in private beta. Functional, end-to-end and regression testing across CRM workflows: defect reproduction, edge-case coverage and release validation alongside the development team, with automated regression coverage in Playwright.
playwright · manual functional & regression testing
Method
Problem → Requirement → System
I have worked every stage of the pipeline, in order
I finished a computer science degree in 2023 and started on data, because that is where the work actually begins — a model is bounded by the corpus it was trained on, and somebody has to go and find that corpus. Scraping it, cleaning it, deciding what is dense enough to keep.
From there I moved to the models themselves: preparing the training data, adapting the model against it, and building the evaluation that tells you whether it actually held. Then into an operations role at a regulated exchange, which is where I learned what happens when a model has to do real work rather than demo well — and what it takes to make one safe enough to put in front of customers.
The most recent step was partly back out of the model again. The ownership work I do now deliberately keeps the model away from the determination: it reads documents, and arithmetic decides. Some answers have to be reproducible and defensible two years later, and a model cannot give you that.
That order matters. Most of what goes wrong in an AI system goes wrong upstream of the model, and you only see it if you have stood in each part of it yourself.
How I decide what a system should and should not do
Most automation projects fail before any code is written, because the wrong process was chosen. I score a workflow on three axes rather than one: how often it happens, how much of it follows repeatable rules, and what it costs when it is wrong.
The combination decides the shape of the answer. High volume, standardised and low risk gets automated end to end. High volume, standardised and high risk gets its preparation automated and its decision left with a person. Anything genuinely varied stays human, because a system that is right most of the time fails unpredictably, and in operations that is worse than not building it.
How I work with engineers
It depends on the system. On the support agent, a Senior AI Engineer owned the implementation while I supplied the operational discovery, the workflows and knowledge it runs on, the prompts, and the testing that found where it broke. The guardrails I designed and implemented myself.
On the ownership determination engine it is the other way round: I own the architecture and I write the code. That came out of auditing the previous design and concluding its failure was structural rather than a matter of tuning — a conclusion you can only really act on if you are willing to build the replacement yourself.
Both arrangements work for the same reason. The hard input is rarely the model. It is knowing what the business actually does, in enough detail to turn it into a requirement — and then being willing to test the result honestly instead of demonstrating it.
- 01
Discovery
Sit with the real process. Read the tickets, the documents, the exceptions.
- 02
Analysis
Score each workflow on volume, standardisation and risk.
- 03
Design
Decide the shape: full automation, prepared decision, or leave it human.
- 04
Build
Build it myself, or own the problem alongside the engineers who do.
- 05
Test
Find the failure cases myself, then fix the prompts and workflows.
- 06
Production
Readiness, deployment support, and continued improvement after.
Index
Capability · Trajectory
Grouped by the system each capability serves, not by logo. Hover any entry for where it was actually used.
AI Automation
- Operational discovery
- Workflow analysis
- Agent workflows
- Prompt engineering
- Workflow orchestration
Reasoning & Compliance Systems
- Neuro-symbolic design
- Graph reasoning
- Applied linear algebra
- Interval arithmetic
- Bi-temporal modelling
- Regulatory rules engines
- Property-based testing
AI Engineering
- LLM systems
- Grounded extraction
- RAG · retrieval
- Entity resolution
- Document AI · OCR
- Model evaluation
- Production readiness
- REST APIs
- AI security
- Threat modelling
Generative AI
- Diffusion models
- LoRA adaptation
- Identity preservation
- ControlNet conditioning
- Computer vision
Data for AI
- Scraping at scale
- Curation
- Annotation
- Metadata & structuring
- Knowledge graphs
Engineering
- Python · NumPy
- TypeScript · React
- Playwright
- Test design
- CI invariants
I worked the AI engineering curriculum end to end, from systems and mathematics through to distributed inference. Filled marks are where that knowledge appears in the work above. Hollow marks are studied, not shipped — I would rather you knew which was which.
- Programming & systemsPython, Linux, Git, CLI, networking, HTTP and API fundamentalsApplied in the work above
- Mathematics for MLCalculus and gradients, probability and statistics, optimisationStudied, not shipped
- Applied linear algebraMatrix inversion, spectral radius, Neumann series, interval arithmeticApplied in the work above
- Data engineeringNumPy, Pandas, SQL, ETL, validation, Parquet and columnar formatsApplied in the work above
- Classical MLSupervised and unsupervised methods, trees and boosting, bias/varianceStudied, not shipped
- Deep learningPyTorch, backpropagation, training loops, CNN/RNN architecturesStudied, not shipped
- Transformers & LLM internalsTokenisation, embeddings, attention, encoder/decoder, KV cacheStudied, not shipped
- RetrievalEmbeddings, similarity, hybrid and dense retrieval, ANN indexesApplied in the work above
- RAGChunking, metadata filtering, reranking, query rewriting, groundingApplied in the work above
- Agents & tool useTool calling, agent loops, memory, human-in-the-loop, permissionsApplied in the work above
- Fine-tuning & adaptationLoRA, QLoRA, PEFT, dataset preparation, when not to fine-tuneApplied in the work above
- EvaluationGroundedness, hallucination, LLM-as-judge, regression testing, red teamingApplied in the work above
- Multimodal & visionDetection, segmentation, OCR, document understanding, vision-language modelsApplied in the work above
- Production & LLMOpsDocker, CI/CD, model serving, autoscaling, cost and latency controlStudied, not shipped
- AI securityPrompt injection, RAG poisoning, tool abuse, authz, secrets handlingApplied in the work above
- GPU & distributed inferenceQuantisation, batching, memory bandwidth, tensor and pipeline parallelismStudied, not shipped
Applied in the work above Studied, not shipped
Computer Science
BS Computer Science, COMSATS University Wah Campus.
Data
Learned that model quality is bounded by corpus quality.
Generative AI
Moved from preparing training data to training and evaluating on it.
Operations
Ran regulated exchange operations and found where the manual cost sits.
Automation
Document automation, guardrails and a support agent to production, against processes I had worked by hand.
Reasoning systems
Architecting an ownership determination engine where the model reads and the arithmetic decides, because the answer has to be defensible years later.
Intelligent systems
Agents that hold context, call real APIs and know when to hand back to a person.
Engage
What I can be hired to build, and what working together actually looks like. Everything here traces to work above.
Discovery and build
I work your actual process — the queue, the inbox, the document pile — score each workflow on volume, standardisation and risk, then build the automation for whatever clears the bar. Scoping and implementation, not a report.
You getA ranked view of what to automate and what must stay human, followed by the working system for the parts worth automating.
Ownership & onboarding automation
OCR and grounded extraction over registration documents and registers, entity resolution, ownership propagation through corporate layers to the real beneficial owners — including the circular structures chain multiplication gets wrong — and gap detection for missing or expired filings. Thresholds and jurisdiction rules held as versioned data, so an old determination stays reproducible.
You getA dossier assembled for your reviewer to decide on, with the evidence trail behind every figure. The system recommends; it does not approve.
Training data pipelines
Sourcing, scraping, curation and structuring — selecting for density rather than volume, with PII and secret filtering and deduplication built in.
You getA corpus your ML team can actually train on, prepared for repeat ingestion rather than delivered once.
Model evaluation
Similarity and alignment scoring, blind comparison, and adversarial testing against a defect checklist written for your failure modes.
You getAn honest read on whether the system holds up, and a repeatable way to check it again after the next change.
Hardening and guardrails
Defences against prompt injection, unauthorised actions and leakage of internal data, then adversarial testing to confirm the system stays inside the scope you gave it.
You getA system you can put in front of customers, with the failure cases found before they find you.
AI support agents
Intent classification, account context, retrieval over a knowledge base I help you assemble, and hard escalation rules for anything touching funds or risk.
You getAn agent that resolves the repetitive questions and hands the rest to a human with the case already prepared.
These are where I have done the work before, not the limit of what I take on. I build as well as scope — most of what is marked Built above is implementation. If your problem sits next to one of these, or is not on the list at all, describe it and I will tell you honestly whether I am the right person for it.
- How do you work alongside an existing engineering team?
- Either way round. Sometimes I own the problem — discovery, workflows, knowledge, prompts, testing — while your engineers own the implementation, which is how the production support agent in Chapter 01 was built. Sometimes I own the architecture and write the code, which is how the ownership determination engine in the same chapter is being built. I will tell you which one a given problem needs.
- What does a first project look like?
- A short scoping conversation, then a discovery pass over one real workflow — the one you already suspect is wasting the most time. That produces a written assessment of whether it should be automated and how, which is useful whether or not you continue.
- What do you need from me to start?
- Access to the real process rather than a description of it: a sample of actual tickets or documents, whoever currently does the work for an hour, and a clear statement of what must never be decided without a human.
- How quickly do you reply?
- I answer project enquiries myself, usually within two working days.
- What won't you do?
- I won't build automation that makes a compliance, funds or eligibility decision without a person in the loop. I will automate everything that prepares that decision. I also won't quote a system I haven't scoped.
- Availability and rates?
- Part-time and project-based only — I am currently engaged and not available full-time. Remote, any timezone by agreement. Rates on request, once I know the scope.
Got a problem that needs the whole pipeline, not just a model?
Available for part-time and project-based AI engineering and automation work.
Currently engaged, so full-time roles are not open. Remote, working to any timezone by agreement; on-site possible for short periods where a project needs it.
Every claim on this site carries a provenance mark: built, contributed, designed, researched or proposed. Where work was done with a team, the mark says so — the support agent was built with a Senior AI Engineer, and Phase 1 is live in production. ORION-KYB I architect and lead, and it is still in development: its architecture and threat model are marked designed, and only the parts that exist and run are marked built. Client work is delivered through Origins Market Place & Technology in Dubai; one product name is withheld under confidentiality, and references are available on request. No metrics, dataset sizes or business outcomes are stated anywhere on this page, because none are public.