Hsu Myat MonBangkok, Thailand

Tailor this page

The full page: working demos, decisions and essays.

Data & AI Platform Engineer who designs and ships end-to-end platforms solo.

From medallion architecture and PySpark pipelines to AI agents and production UIs. I currently own the full data and AI stack for a manufacturer on Microsoft Fabric, where an advanced planning system I built from scratch lifted on-time delivery from 70% to 97.6%.

AI Systems · Azure & Microsoft Fabric

97.6%
on-time delivery

up from 70% once the planning engine replaced manual scheduling

25K+
production orders / week

each with a routing, 200K+ operations in total

50%
faster claim processing

AI document pipeline at a life insurer

$38K
saved in one year

workflow automation at a life insurer

At a glance

2.5+ years of experience

Visa sponsorship required · open to relocating

Experience

  • Data & Machine Learning Engineer · EnnovieSept 2025 – Present
  • Data Engineer · AIA MyanmarSept 2024 – Sept 2025
  • Data Analyst · Dauntless Discovery InternationalFeb 2024 – Sept 2024

Core stack

  • Python
  • SQL
  • PySpark
  • Microsoft Fabric
  • Azure
  • TypeScript / Next.js
  • Power BI
  • LLMs

Education

Bachelor of Information Technology

James Cook University, Singapore · Distinction

Full experience ↓Download CV

01Selected work

Production systems, rebuilt small enough to touch.

What I've built, in one line each.

  • Production planning engine

    Replaced manual planning for 25,000+ weekly production orders with a scheduling engine that never plans above real capacity.

    70% → 97.6%on-time delivery

  • 3D CAD review portal

    Customers and designers review the real 3D model in the browser, pin comments to it, and see the weight change as they swap metals and stones.

    3 teamscustomer, CS and CAD on one model

  • Invoice → sales order pipeline

    Emailed PDF orders become ERP sales orders automatically, and anything the system is unsure of is held for a person.

    30 min → secsper order, up to 3 days in a backlog

  • Routing rule engine

    Generates the factory route for every new design from rules the planners edit themselves, checked against the ERP before anything ships.

    0deployments to change a rule

  • Product development platform

    Takes a new design from sketch to a costed ERP item through six role-gated stages, priced in each customer's own currency.

    ±1%casting weight, measured from the 3D model

01

Production planning engine

PySpark · Microsoft Fabric · Business Central

Weekly demand never arrives level. The rule that matters is the one planners insisted on: capacity is never exceeded. A full week is full, work cascades forward, and if it is late it is late. What cannot fit at all becomes the overtime and outsourcing requirement instead of quietly disappearing.

Drag the gates. Watch which one actually binds. It is rarely the plant-wide number.

ReadA full week is full

97.6%
on time · this run
0
pcs needing OT / outsource
9/12
weeks bound by cell minutes
01.1k2.2k123456789101112plant 1,635
On timeLatePlant gate

Raise the plant gate on its own and the plan barely improves, because the cell's minutes are usually what bind. That is the entire argument for scheduling against real cell capacity instead of a plant-wide number.

Never over cap
A full week is full. Work cascades to the next week with genuine room rather than being force-placed into a virtual overflow lane.
Gates compete
Plant pieces, cell minutes and per-family sub-caps all bound the same week. Every blocked quantity records which gate stopped it.
Nothing disappears
What will not fit inside the horizon is reported as the overtime and outsourcing requirement.
Why not a solver
CP-SAT or MILP is the obvious reach, and it optimises for the wrong thing here. Planners have to be able to argue with a schedule, so every blocked quantity has to name the gate that stopped it, and an optimum arrives as one number with no such account. A deterministic forward cascade also re-runs over 25,000 orders on demand and returns the same plan twice, which matters more on a shop floor than the utilisation it gives up.
02

3D CAD review portal

three.js · rhino3dm · Next.js

Design approval used to happen over email screenshots. Reviewers now open the real model in the browser, pin a comment to the exact point on the geometry they mean, and try materials themselves. The stone list is built from the ERP's own stone master, so a customer can only pick something the factory can actually source. And because each entry carries its density, swapping a stone moves the carat weight, not just the colour.

Orbit it, click to drop a pin, and change the metal or the stone, then watch the weights move.

ReadDensity is not a swatch

Loading the 3D viewer…

Pins are geometry
A pin stores a point in the model's own local space plus its surface normal, so it stays welded to the part and hides when that face turns away.
Materials carry physics
Every catalogue entry has its own density and optical properties, so a swap changes the reported weight and carat, not just the colour.
Sourceable only
The list is built from the ERP's stone and alloy masters, so a customer cannot choose something the factory cannot buy.
03

Invoice → sales order pipeline

Azure Document Intelligence · Python · Business Central

A customer emails a PDF order. Previously a person retyped it: about 30 minutes, up to 3 days during backlogs. The pipeline extracts the lines, maps each barcode to ERP item master data and writes the sales order in seconds.

Run the pipeline and step through what each stage does to the document.

ReadThe cheapest classifier is a business rule

  1. Ingest
  2. Extract
  3. Normalize
  4. Map
  5. Create
  6. Notify
Customer PDFPO-44182.pdf
8851234500179Ring, 18K YG, RD 2.0mm24
8851234500186Pendant, 18K WG, halo12
8851234500193Earring, 14K RG, huggie36
8851234500209Bangle, SS, brushed8
Sales order
ItemQtyMatch
·
Ring, 18K YG, RD 2.0mm
24·
·
Pendant, 18K WG, halo
12·
·
Earring, 14K RG, huggie
36·
·
Bangle, SS, brushed
8·
~30 minutes of retyping, replaced
Barcodes, not guesses
Each extracted line is resolved against ERP item master data by barcode, and the match confidence travels with it.
It refuses to guess
Anything under the confidence threshold is held for a human instead of being written to a plausible-looking item number.
Minutes, not days
The same work took about thirty minutes by hand, and up to three days once a backlog formed.
04

Routing rule engine

TypeScript · Python · Microsoft Fabric · Business Central

Every new design needs a routing: the ordered steps it takes through the factory. Instead of someone writing one by hand, the engine starts from a template mined out of the ERP's own certified routings, then applies rules the planners edit themselves, with no deployment. Every step on the result names the template or rule that put it there.

Change the design, switch rules off, then flip R5 from ordering a step to booking one.

ReadA rule that only moves things

Product
Metal
Stones
Finish
Rules (data, not code)0 deployments
  • R1when stones ∈ {natural, lab} → book SETTINGbooks
  • R2when stones = natural → book DIAMOND TESTbooks
  • R3when finish = rhodium → book PLATINGbooks
  • R4when metal = gold → book HALLMARKbooks
  • R5when always → HALLMARK precedes POLISH
Generated routing8 steps
  1. 010WAXtemplate
  2. 020CASTtemplate
  3. 030FILEtemplate
  4. 040DIAMOND TESTbooked by R2
  5. 050SETTINGbooked by R1
  6. 060POLISHtemplate
  7. 070PLATINGbooked by R3
  8. 080QCtemplate
5 from the template, 3 booked by rules. Every step names its source, so when a planner disagrees with a routing they can point at the rule, not at the engine.

Set the piece to gold and R5 pulls the hallmark ahead of polishing, but it never adds one to silver. Now flip R5 from orders to books and look at the silver piece again.

Templates are mined
The baseline chains come from the routings the ERP already runs, grouped by product scope. Retired work centres are folded onto live ones first, or every difference between two routings is noise.
Books versus orders
A rule that books adds a step. A rule that orders only says where an existing step goes. They look almost identical in an editor, and keeping them apart caught a change that would have added a step to hundreds of templates that correctly had none.
Graded against the ERP
A simulator runs the rules over the real catalogue and aligns each result with the certified routing, step by step. The first honest run matched exactly 0% of the time, and the alignment put most of the error on three specific rules. A bad number that points somewhere is worth more than a demo that looks right.
Undecided is not false
When a rule depends on a fact the ERP does not hold, it reports undecided rather than quietly not firing. A gap in the data never passes for a decision.

Around the rule engine

From sketch to a costed, buildable item

Product development · 2025–2026

A new design goes through CAD, gets a bill of materials and a routing, is priced for the customer, and only then becomes an item in the ERP. I built the platform that carries it along that path: a role-gated flow where each stage sees only what it owns, a costing engine that prices in the customer's own currency, and the geometry that turns a 3D model into weights and areas a costing can rely on.

How it works: 5 decisions
Nothing reaches the ERP before the customer says yes
Six stages, from CAD support to customer service, each gated by role. Drafts live in a cache while people work, and every stage change publishes one record to the warehouse, so the queue's status is exact rather than approximate. The ERP item, its BOM and its routing are created only after the customer approves the quote.
It costs what was confirmed
Costing reads only the BOM frozen at a checkpoint, and every snapshot records the engine version that priced it. Anything added after the freeze shows in the tree but costs nothing, and says so: a zero cost always carries a flag.
Priced in the customer's currency
Direct exchange pairs instead of converting through a pivot currency, which had inflated every baht cost by about ten percent. Metal is costed per BOM component at its real fineness, which fixed an assumption that had halved the gold on every 18K design.
Weight is measured, not estimated
Hollow castings are voxelised, and a distance transform keeps only the wall. The two textbook estimates were 23% heavy and 30% light. The measurement lands within 1% of an independent reference in about a quarter of a second. Plated area is one geometric rule shared by the customer's spec sheet and the cost, so the two cannot disagree.
Approval decides what a customer sees
3D, 2D and print files are versioned separately. Anything uploaded after the manager's last approval stays hidden from customer service and the customer. That boundary is enforced in the query, not by hiding a tab in the browser.

Next.js · TypeScript · Microsoft Fabric · Redis · Business Central · rhino3dm

6
role-gated stages, sketch to ERP item
±1%
hollow-casting weight against a reference
10%
currency error removed from every baht cost
19%
plated-surface over-count removed

Before this

Document intake and claims automation

Life insurance · 2024–2025

Insurance work arrives as an email attachment: a scanned form, a policy number, no structure. Azure Vision AI classifies each attachment by the form ID and title it can detect, resolves the policy number and files it into the CMS. Seven workflows that used to be somebody's entire morning. Extended with YOLOv8 and Document Intelligence for claim documents, the same intake path halved claim processing time.

No demo for this one. It was built on real policy documents and real claims, and there is no version of that I can put in a browser.

Azure Vision AI · YOLOv8 · Azure Document Intelligence · Azure OpenAI

$38K
saved in one year, business-unit-wide
7+
intake workflows automated
50%
faster claim processing
95%
accuracy on non-complex claim decisions

The four demos above are working reconstructions of systems running in production. The mechanics are real; the data inside them is synthetic, and no customer name, live figure or proprietary rule appears in one.

02Approach

Decide it's easy, then make it easy

The first half is a trick I play on myself. 'This is hard' is the thought that stops me starting, and while it sits there my effort goes on the size of the problem instead of on the problem. Deciding it is easy gets me moving. The second half is the part I have to earn: the only way to keep that promise is to break the thing down until the pieces genuinely are easy. I have done that enough times now that most things do look easy to me. That is the trick working, not the work being small.

It also means I think around a problem rather than straight at it, because a route I have decided is easy is one I will actually try. And I have almost always been the only data person in the room, which leaves no team to absorb a bad abstraction and nothing I ship maintained by anyone but me. Five decisions that come out of working this way:

01

Start at the constraint, not the schema

Before I design anything, I find the one rule the work turns on, next to the people doing it.

Read the reasoning
The default
Model the domain first (entities, tables, relationships) and work out later what anyone actually needs from it.
The problem
I can spend a month building the wrong thing very precisely. Nobody on a production floor ever asked me for a schema; they asked for a plan they could trust, and a tidy model is not evidence that I understood the work.
What I do
I find the one rule the work genuinely turns on before I design anything, and I find it next to the people doing the work rather than in their data. On the planning engine that rule was a sentence a planner said out loud, 'a full week is full', and every table, parameter and Spark job after it exists to enforce that sentence. They did not stop being involved once I had it: the eighty parameters and twelve rule tables they edit are the same levers we argued over at the whiteboard, so the engine keeps changing in their hands rather than mine. The cost is that I start slower and my first data model is usually worse than it should be.
02

Whatever will keep changing shouldn't be code

Rules that move with the business live in data the business can edit, with tests that reject a bad change.

Read the reasoning
The default
Business rules get written into the code that applies them, because that is the easiest and fastest place to put them.
The problem
Every later change to a rule then needs me, a deployment and a release window. And these rules change constantly, not because they were wrong, but because the business moved. I become a queue that the business has to wait in.
What I do
I try to work out early which parts will keep moving, and put those in data that someone else is allowed to edit. In the scheduler that is roughly eighty parameters and twelve rule tables the planners change themselves, with zero deployments. It is genuinely harder to build and much harder to test, which is why it has an automated harness that rejects an invalid rule change rather than quietly producing a bad plan.
03

A system should be allowed to refuse

I would rather a system hold a case for a person than guess, because one confident wrong answer costs more trust than it saves.

Read the reasoning
The default
An automation is judged on how much it gets through without a human: the coverage number is the headline.
The problem
Chasing coverage pushes a system into guessing, and a confident wrong answer is worse than no automation at all. The manual process had somebody checking; the automated one does not. Being wrong two percent of the time destroys trust in the other ninety-eight.
What I do
I give it a confidence threshold and a way to say I don't know. The invoice pipeline holds a document for a human rather than writing a sales order against an item number it is unsure of. It automates less than it could. It gets believed, which is the thing that actually determines whether anyone keeps using it.
04

Data layers are about who is allowed to be wrong

Bronze may be wrong, gold may not, and silver is where the corrections happen in the open.

Read the reasoning
The default
Bronze, silver and gold are taught as three stages of progressively cleaner data: raw, tidied, ready.
The problem
Described as a cleaning process it sounds like housekeeping, and it gave me no way to decide what belonged in which layer. On the first platform I built, I could not tell.
What I do
I think about permission to be wrong. Bronze is allowed to be wrong: it holds whatever the source really sent, faithfully, including the mistakes. Gold is not allowed to be wrong, because people make decisions on it. Silver is where that gets corrected, deliberately and visibly. Once the layers mean that, a disagreement about a number stops being an argument and becomes a lookup: we can point at the layer where it went wrong.
05

I ship the interface too

I take the work all the way to the screen people use, and accept being worse than a specialist at each layer.

Read the reasoning
The default
A data engineer delivers correct tables, and somebody else builds the thing people actually look at.
The problem
The handover is where most data work quietly dies. A number nobody can see is a number nobody trusts, and if I never watch someone use it I never find out that the answer I was so pleased with is unusable at 7am on a Monday.
What I do
I take it all the way to the screen: Spark job, API, and the page the planner opens. What this costs is real and worth saying plainly: at each individual layer I am worse than a specialist would be. What I get for it is that nothing is lost in a handover, and it is the only way one person covers this much ground.
04Experience

Where I've built things.

Sept 2025 – Present

Data & Machine Learning Engineer

Ennovie

Core data architecture & algorithmic engines

  • Joined a manufacturer with no data infrastructure: reporting ran on Dataflows pulling straight out of Business Central, with no warehouse, no history and no model underneath it.
  • Architected the company's inaugural Medallion data platform on Microsoft Fabric, giving Finance, Inventory, Sales, Product Development and Production one queryable history of the business where every report had previously been rebuilt by hand against the live ERP.
  • Built a custom PySpark Advanced Planning & Scheduling engine that lifted on-time delivery from 70% to 97.6%, replacing manual planning for 25,000+ weekly production orders (200K+ operations) and reverse-syncing schedules into the ERP via custom AL extensions.
  • Moved scheduling policy out of code and into the planners' hands: they change how the plant is scheduled without a deployment or a developer, across roughly eighty parameters and twelve rule tables, guarded by an automated invariant-checking harness that fails the change rather than the plan.

Full-stack enterprise platforms & 3D web apps

  • Shipped the company's enterprise operator platform (Next.js / React / TypeScript), now the system the plant is run from day to day: planning, casting, RFID tracking, outsourcing approvals and production tracking, all behind one Microsoft Entra sign-in.
  • Architected a collaborative 3D CAD customer portal (three.js + rhino3dm) for native Rhino .3dm files: 3D spatial pinning and commenting across client, CS and CAD teams, alloy weight estimation, AI spec-sheet population and automated stage-gate notifications.

Product development platform

  • Built the platform that takes a new design from sketch to a costed ERP item: a six-stage role-gated flow from CAD to customer service, a costing engine that prices in each customer's own currency from the confirmed bill of materials, and ERP item creation that runs only once the customer has approved the quote.
  • Built a routing rule engine that generates each design's manufacturing routing from templates mined out of the ERP's certified routings plus rules the planners edit themselves, with a simulator that grades every rule against the ERP's own routings before it ships.
  • Replaced estimated casting weights with a voxel distance-transform measurement of hollow shells, landing within 1% of an independent reference where the two textbook formulas were 23% heavy and 30% light.

Intelligent automation & AI systems

  • Cut customer order creation from ~30 minutes (up to 3 days during backlogs) to seconds with an Azure Document Intelligence pipeline that ingests email invoices, normalizes and extracts line items, maps barcodes to ERP item master data, auto-generates sales orders and notifies sales and CS.
  • Embedded an enterprise Claude AI layer (conversational planning assistants, CAD computer-vision tools and automated executive briefings), giving non-technical stakeholders natural-language access to proprietary data.

Analytics & performance

  • Optimized analytical reporting, delivering near real-time Power BI semantic models and applications that cut dashboard query latency from minutes to seconds.

Sept 2024 – Sept 2025

Data Engineer

AIA Myanmar

  • Automated 7+ workflows with Azure Vision AI (classifying email attachments and routing them to CMS by detected form ID/title and policy number), saving over USD 38,000 business-unit-wide in the first year.
  • Built an AI-powered OCR pipeline (YOLOv8, PyTorch, Azure Document Intelligence) that cut claim processing time by 50%.
  • Piloted Azure OpenAI to automate claim decisions, reaching 95% accuracy on non-complex claims.
  • Supported AML compliance by mapping and transforming key risk data from EDW sources and designing secure, scalable ingestion pipelines in Azure Data Factory.
  • Developed a policy renewal system with Python, SQL and Power Automate, improving retention and cross-sell conversion.

Feb 2024 – Sept 2024

Data Analyst

Dauntless Discovery International

  • Led daily eDiscovery over 100,000+ rows of breached data, using advanced ELT techniques in SQL and Excel to identify PII and maintain privacy-regulation compliance.
  • Consistently ranked top-two on the team's daily productivity charts.

2021 – 2023

Bachelor of Information Technology

James Cook University, Singapore · Graduated with Distinction, GPA 6.08 / 7

1st Prize, JCUS Design Sprint · Top 15 Finalist, Splash Awards 2023 · Head of Logistics, Wallstreet Club

05Toolkit

What I work with.

Languages
PythonSQLTypeScript
Data platform
Microsoft FabricPySparkAzure Data FactoryDatabricksPower BI
ML & AI
PyTorchAzure OpenAIAzure Document IntelligenceOpenCV
Product
Next.jsReactthree.jsFastAPI
Platform ops
Azure DevOpsMicrosoft Entra SSOLinux
06Contact

Let's talk.

Bangkok-based. I need visa sponsorship anywhere I work, Thailand included, and I'm open to relocating for the right role.