Industries & Systems
We have delivered production management and data systems in semiconductor test and packaging, apparel manufacturing and printing. The processes differ, so the systems differ. Below is what each system actually delivered, by industry — nothing we have not built is listed.
Apparel production management system (Manufacturing execution / MES)
Export apparel manufacturer, both woven and knit lines
Modules delivered
Document import
- AI fabric-sheet import
- AI order import
Master data and materials
- Customer records
- Style records
- Fabric and trim management
- BOM integration
- AI parsing profiles
Production flow
- Production work orders
- Cut-piece bundling
- Packing
Handheld (PDA)
- Trim receiving
- Trim issue
- Print and embroidery in/out
- Bundle pick-up
- Finished-goods receiving
Management boards
- Order production board
- Cutting board
- Sewing board
- Packing board
AI document parsing: one parsing profile per brand
The AI document parsing that Jixing Software built for this export apparel plant deals with fabric sheets and purchase orders: different brands, PDF and Excel mixed together, different field names, different header positions, different units. They used to be retyped by hand off the screen, an hour or more per document. That is what the module list means by “AI fabric-sheet import” and “AI order import”.
We do not hand the whole file to a large model. Anything that can be read deterministically is not left to the model to guess: the data rows of a fabric Excel sheet are read by code, row and column, and the model is used only to recognise the header, which differs for every brand. Some brands’ PDF invoices are parsed straight off the table rules and never reach a model at all. For order PDFs the text is extracted locally first, and only then does a model pull out the order and PO line items.
Each customer’s parsing profile — which fields to look for, which model to use, how the prompt is written — is stored in the database per customer, not hard-coded. Taking on a new brand means configuring a profile, not changing the code.
Model temperature is set to 0. An extraction task needs the same file to give the same answer every time; it does not need creativity.
Retyping a fabric sheet or an order went from being measured in hours to being measured in minutes.
Data boundaryThe data rows of a fabric Excel sheet never leave the server; only a header sample is sent to the model. The body text of an order PDF is parsed through a cloud large-model API.
Not built yetNot delivered, still at the design stage: extending AI from the import step to the system’s operating surface, so that the MES or ERP can take instructions rather than being used once at data entry.
CP wafer-sort line management and test-data system (Manufacturing execution / MES)
Modules delivered
Orders and work orders
- Customer and product master data
- Orders and work orders
- AI parsing of order files, checked automatically against the routing, the station (CP1–CP4) and the test program bound to it
- Routing configuration (station / program / prober / tester / probe-card bindings)
- Test programs resolved and downloaded from the machine’s bound IP and its current station
Data collection
- Automatic pickup of prober MAP files
- Tester-side agent uploads incrementally, skips files still being written using a quiet period on modification time, verifies size and keeps a local mirror
- Binary MAP parsing and validation
Yield and exception handling
- Yield written back to the work order
- Threshold comparison
- Low yield auto-locks the lot and is logged
- Exceptions summarised per wafer and pushed to a WeCom group
Data conversion and map processing (desktop)
- Format conversion for multiple customers
- Tester data analysis and processing
- Gross-die composition
- Fail-die cluster handling on the map
- Laser inker file generation
Handheld (PDA) shop-floor work
- QR-code receiving and shipping
- Work-order configuration and cancellation
- Station check-in and check-out at CP, QA and other stations
- Incoming, visual and inner-box inspection
- Repair and equipment loan
- Lot close and reopen
Warehouse and shipping
- Inner boxes and outer cartons
- Delivery notes and forwarding
- Reconciliation statements
- WIP and inventory
Equipment and probe cards
- Equipment register and loans
- Checks and maintenance
- Probe-card life
FT final-test packing and shipping management system (Manufacturing execution / MES)
Modules delivered
Orders and work orders
- Customer and product master data
- Grade and bin definitions
- Orders, work orders and routing
- Receiving, lot creation and lot close
Test operations and repair
- Station check-in and check-out for test
- Equipment and station records
- Repair
Inspection and packing
- Visual inspection
- Inner boxes
- Outer cartons
- Bag / reel / box / carton labels generated as one set
Shipping and settlement
- Delivery notes
- Forwarding
- Reconciliation statements
Equipment management
- Equipment register and loans
- Checks and maintenance
Shipping labels: four levels in one pass, with no hand-editing in between
Final-test shipping labels come in four levels: bag, reel, box and carton. The hard part is not printing them, it is mixing — a reel may carry a main lot and a secondary lot; a box may hold several full reels plus one partial reel. Whether lot numbers are mixed and whether markings are mixed splits into several further cases, and the quantity-rollup rule is different in each. Editing those labels one at a time by hand, against the rules, goes wrong sooner or later.
This system generates all four levels as one set: packing data is entered once, and what each of the bag, reel, box and carton labels shows, which lines merge and how quantities roll up are all derived from that same data. There is no hand-editing step in between, so the four levels cannot drift apart and reach the customer disagreeing with one another.
Printing production management system (Manufacturing execution / MES)
Printing plant running two process lines, sheet-fed and roll
Modules delivered
Master data
- Customer records
- Paper stock records
- Roll stock records
- Station setup
Orders and production orders
- Create and amend orders, with line items using one of two field sets depending on order type
- Production orders raised from an order
- Production rule execution: runnable and completed work orders, machine on and machine off
Shipping
- Create shipping line items
- Create and manage inner boxes
- Delivery note management
Billing and reconciliation
- Create billing line items
- Billing statement management
- Reconciliation statements generated from billing line items
Handheld (PDA)
- Scan to pull up a production order
- Station check-in and check-out
- Repair
Desktop client at the machine
- Current machine: scan the work-order QR code to see which order this machine is running and which station it has reached
- Past records
Whether billing lines merge is a switch on the customer record
At month end some customers want every billing line itemised; others want lines of the same batch and specification merged into one. Both are reasonable and neither side will convince the other — which is a far more common kind of problem on the floor than a technical one.
So the merge rule does not live in the export code, it lives on the customer record. With the switch on, billing lines that match on all five of contract number, item name, specification, batch number and unit price merge into one, with quantity and amount summed; the remark is cleared only where a merge actually happened — more than one line in the group — and a single line is left as it was. With the switch off, nothing merges.
A different customer means changing one field, not the program.
Semiconductor: the engineering behind the module list
The modules delivered by the CP and FT systems are listed above. What follows is what a module list cannot show — how it is done, and where the boundaries are. For this line of business we disclose no project narrative, no client name and no production data.
- Binary prober MAP parsing and validation: per-die bin results are read out and checked item by item against lot number, total tested and good count; a mismatch stops the run and is logged
- Rule-based treatment of fail dies: the surroundings of a fail cluster, a good die isolated inside failures, GDBN 3×3 weighted scoring, controlled margins around particular bins, and fail regions that persist across a stack of wafers from the same lot. Connectivity is configurable — 8-neighbour including diagonals, or Manhattan distance D=N, a diamond. Rules are applied in order, then merged and de-duplicated before being written back to the map.
- The rules do not depend on one another: each runs against the original map independently and merging happens in exactly one place. Adding a rule cannot disturb the existing ones — which is what makes people willing to change a rule on a running line.
- How a first test and a retest are merged is configurable per tester model: which run takes precedence, whether the header comes from the earliest or the latest, and whether bin totals and the overall count are recalculated. Plants do this differently; it does not belong in code.
- Automatic collection of tester data: an in-plant agent scans and uploads incrementally, verifies size, keeps a local mirror and recovers by itself after a dropped link. When dozens of testers change lot at the same moment, transfers are staggered so the plant’s uplink does not saturate.
- Automatic alerting: anomalous dies found during conversion are summarised per wafer and pushed to a WeCom group, so nobody has to go looking through a report
- Automatic test-program delivery: the right program is resolved from the machine’s bound IP and its current CP1–CP4 station, so nobody has to remember which machine runs which version
- One representation for many sources: prober MAP files, tester CSV and fab text maps are normalised into a single intermediate form, which is what makes the reports above them comparable
- Yield thresholds are configured per product and per station, with CP1–CP4 and the ring test each independent; below threshold the lot is flagged low-yield, locked for engineering review and logged
- Multi-tenant deployment: the platform database, each tenant’s business database and the cross-tenant equipment database are kept separate
- The data boundary has three parts. Raw test data — prober MAP files and tester files — moves over FTP or SMB within the plant network and into a local database; it does not travel over the internet. Order files are uploaded to a cloud large-model API to be parsed. Alerts, summarised per wafer, are pushed to a WeCom group.