Plate A-02 · About Latentry
Built by Practitioners,
for Practitioners
We founded Latentry because the gap between academic AI literature and production reality was too wide — and too few learning programmes were honestly addressing it.
Back to HomePlate B-02 · Origin
How Latentry Came to Exist
Latentry started as a working group inside a Kuala Lumpur technology consultancy in 2021. Three engineers who spent their weeks debugging data pipelines, rewriting preprocessing scripts and cleaning up model deployments that had drifted in production began meeting on Friday afternoons to document what they were learning — not the theory, but the decisions.
The notes accumulated. By mid-2022 they had a structured curriculum for data handling and baselines that they were sharing informally with junior colleagues. The response made it obvious this should be a programme, not a set of internal documents.
Latentry was registered in 2023 with a single aim: to run the kind of learning cohorts the founders would have wanted to attend when they were starting out. Cohorts with real datasets, live feedback, peer review and no promises about what happens to your career next week.
The school now operates three programmes of increasing depth. Each one is maintained by the team that built it, updated when the relevant tooling or practice shifts, and capped at a cohort size that makes genuine peer interaction possible.
Plate B-03 · Mission
What We Are Here to Do
Our purpose is to help working developers build the kind of understanding that transfers — not just to one framework or one employer, but to the next problem they haven't met yet.
Mapped, not scattered
Every session sits in a curriculum that shows where it fits — before and after. Learners always have a sense of position, not just a list of topics.
Honest about difficulty
We do not simplify exercises until they stop being realistic. The datasets have actual problems. The feedback points at what needs improving.
Cohort over course
Learning is faster when you can see how others approach the same problem. Peer review pairings and critique sessions are integral, not optional extras.
Plate C-02 · The Team
The People Who Run Programmes
Razif Azman
Lead Instructor · Data & Baselines
Eight years building data infrastructure at scale. Razif designed the Data Handling cohort around the mistakes he most frequently saw junior engineers make in production.
Liang Suyin
Lead Instructor · Computer Vision
Spent five years on visual inspection systems for manufacturing before moving into education. Liang wrote the Computer Vision Specialisation with constraints from real deployment environments at its core.
Nadia Krishnan
Lead Instructor · MLOps
Nadia spent six years as a platform engineer before shifting to AI infrastructure. She shaped the MLOps Programme around the on-call realities and incident post-mortems she accumulated in that time.
Plate D-02 · Standards
How We Maintain Programme Quality
Curriculum Review Cycle
Each programme is reviewed after every cohort. Sessions that no longer reflect current practice are rewritten before the next intake opens.
Written Feedback on Every Submission
Exercises receive specific written feedback, not just pass or fail markers. Feedback is returned within five business days.
Engineering Review at Checkpoints
Project checkpoints in the MLOps Programme are reviewed by working engineers, keeping the bar grounded in what production environments actually require.
Data Protection
Learner data is used only for programme administration. We do not share personal data with third parties for marketing purposes. See the Privacy Policy for full detail.
Capped Cohort Sizes
Cohorts are kept small enough that peer pairings are meaningful and instructors can respond to individual questions in live sessions.
Maintained Dataset Library
The dataset library used in exercises is maintained and version-controlled. When a dataset becomes stale or unrepresentative, it is replaced before the next cohort begins.
Plate E-02 · Context
AI Education That Stays Close to Practice
The artificial intelligence field moves quickly, but the underlying discipline of working with data carefully does not. Latentry's programmes are designed around that distinction. Frameworks change; the habit of splitting data honestly before you train anything does not.
Kuala Lumpur is home to a broad technology community that spans fintech, logistics, manufacturing and infrastructure development. Practitioners across these domains are building with machine learning tools in ways that require them to understand not just model construction but data integrity, deployment stability and monitoring — the full operational picture.
Latentry sits at the intersection of those needs. The three programmes we run cover the stages of AI work that practitioners encounter in sequence: getting data right first, then building specialist visual systems, then learning to maintain and operate what has been built. Each stage has its own discipline, and each programme is designed to teach that discipline through sustained practice rather than demonstration alone.
Participants leave with a completion record and, depending on the programme, a written portfolio piece or architecture document that reflects actual decisions made and defended during the cohort. These are the artefacts that transfer — to the next team, the next project and the next domain.
Plate F-02 · Next Step
Find the Programme That Fits Your Stage
Whether you are building your first disciplined baseline or learning to keep models stable in production, there is a path at Latentry for where you are now.
Get in Touch