Production & Quality
Inspection, process checks, non-conformance, correction, and release decisions connected to each unit.
Mekai Platform
Intelligence to
automate factory work.
Inspect an assembly. Verify an SOP. Adapt a PLC program. Run a commissioning test or prepare a shift report.
We’re building one platform to turn your requirements and existing equipment into the automation your factory needs.
For Quality, controls, engineering, production and maintenance teams.
QUALITY AND PRODUCTION
Inspect parts and verify the work at each station.
ENGINEERING AND CONTROLS
Adapt programs, reuse checks and test production changes.
OPERATIONS AND SERVICE
Connect reports, alarms, maintenance and machine performance.
What do you want to automate?
Find the work
your team does today.
Explore the applications we’re building toward. Each one starts with your process, the inputs available and a result your team can use.
01Inspection and QualityIs the right part fitted, in the right place, the right way?
Inspect every required point on the assembly.
- Check component presence, count, position and orientation.
- Compare appearance with accepted examples and flag the region that needs review.
- Associate the result with the part, variant and operation; connect an agreed OK, NOK or hold signal where the station permits.
What we start withAccepted parts, drawings, inspection criteria, camera views and relevant station signals.
What your team getsAn OK, NOK or review result with the image, location, reason and inspection time.
Inspection is our first application under validation. Hidden engagement or strength may need a measurement or process signal as well as a camera.
02SOP and operator verificationDid the operator complete the required steps before the next cycle?
Turn the SOP into checks at the station.
- Check that the required component, tool or operation appears at the expected step.
- Flag skipped steps, incorrect order and work completed outside the allowed time.
- Request operator review or a station hold when required evidence is missing.
What we start withThe approved SOP, work sequence, camera views, tool results and machine events.
What your team getsA record of completed, missed and unresolved steps, with timestamps and supporting evidence.
The agreed checks cover observable work; a visible action alone may not prove torque, force or correct engagement.
03PLC and machine programmingThe requirement changed. What needs to change in the program?
Carry a production change into PLC logic, recipes and machine programs.
- Prepare candidate logic, recipe or parameter changes for the required sequence.
- Check timing, interlocks, I/O behavior and abnormal cases against the process.
- Review the differences, test the candidate and retain the approved program and recovery version.
What we start withThe new requirement, existing program, I/O list, sequence, interlocks and equipment limits.
What your team getsA proposed program change with a change list, test results and a release decision.
Program generation and adaptation are in development. Controller support and live changes are qualified with the plant Controls team.
04PLC-to-PLC transferCan we carry this machine sequence to a different controller?
Reuse the process when the controller changes.
- Map the sequence, signals and interfaces to the target controller.
- Identify instructions, timing behavior and functions that need controller-specific engineering.
- Compare normal operation and fault handling before commissioning the target.
What we start withThe source program, process sequence, source and target I/O, libraries and controller constraints.
What your team getsA target program candidate, a list of differences and tests for the behavior that must stay the same.
Controller transfer is a development direction. Compatibility must be established for the specific source, target and application.
05Requirements and engineering checksWhat must this machine do, and how will we check it?
Turn specifications into reusable engineering checks.
- Extract requirements for review and link them to the original document.
- Identify missing or conflicting criteria before the test or build.
- Prepare reusable calculations, sequence checks and reports; replay them on recorded or simulated inputs.
What we start withRFQs, drawings, specifications, calculations, I/O lists and acceptance criteria.
What your team getsA reviewed requirement list, the checks to run and a record of pass, fail or missing evidence.
Engineers review assumptions and calculations before they are used for a design or machine decision.
06Commissioning, FAT and SATWhich acceptance tests passed, and what still needs closing?
Connect the test plan to the result and sign-off.
- Check sequences, cycle times, handshakes and agreed fault cases.
- Track deviations, punch points, corrective actions and retests.
- Assemble the evidence for FAT, SAT, UAT and customer handover.
What we start withThe test protocol, interface specification, machine data, measurements and witness records.
What your team getsAn acceptance pack with test results, open items, reviewer decisions and the accepted configuration.
Customer acceptance and engineering sign-off stay with the authorized people.
07Production and shift reportingWhere did we lose time this shift?
Turn machine events into reports the plant can use.
- Calculate availability, utilization, throughput and cycle-time trends on agreed definitions.
- Separate waiting, blocking, charging and equipment stops where the signals support it.
- Compare shifts, machines and vendors; prepare exception and management reports.
What we start withPLC and SCADA events, production counts, MES records, stoppage reasons and shift calendars.
What your team getsA shift or operations report with the losses, exceptions and source records behind each figure.
Metric definitions and data coverage are agreed for each site.
08Alarms and maintenanceWhat happened before the machine stopped?
Connect alarms to the events that explain them.
- Build a timeline across the machine and connected systems.
- Find repeated alarms, deteriorating performance and changes around the incident.
- Prepare an alert, maintenance ticket or investigation report with the relevant evidence.
What we start withAlarms, controller events, configuration history, measurements and maintenance records.
What your team getsAn incident timeline, supporting records and actions for the responsible team.
Root-cause conclusions need engineering review when the available signals cannot establish the cause.
09Robots and material flowWhy is a robot waiting, or material not reaching the next station?
Connect the handoffs between equipment.
- Follow missions and material movements across systems.
- Check handshakes, waiting time, blocking and missed transfers.
- Develop dispatch and intervention workflows around permitted interfaces and equipment rules.
What we start withRobot or fleet events, WMS/WCS orders, conveyor states, doors, lifts, chargers and station requests.
What your team getsA material-flow record, the reason for a delayed handoff and a workflow for the agreed response.
Dispatch and machine action require application-specific integration, testing and authorization.
10Service levels and vendor performanceDid the system deliver the uptime and throughput we agreed?
Calculate performance against the actual agreement.
- Calculate uptime, throughput, MTTR and response time using agreed definitions.
- Show shortfalls and exclusions alongside their supporting records.
- Compare vendors and periods without mixing incompatible calculations.
What we start withContracted targets, metric definitions, system events, exclusions and service records.
What your team getsA service-level report that both the customer and supplier can review.
The report supports the contract review; it does not decide contractual disputes.
11Change, revalidation and handoverA part, program or machine changed. What do we need to test again?
Keep the next change connected to the accepted version.
- Compare the new setup with the accepted baseline.
- Identify affected requirements, checks and results that need fresh evidence.
- Track reinspection, retests, approval and handover of the next version.
What we start withThe accepted setup, new drawings, program or recipe changes and previous test results.
What your team getsA focused retest list and a new accepted record of what changed and who approved it.
The responsible engineers confirm the impact and the tests needed for release.
The complete process
From a requirement to a result you can act on.
Follow the work through four phases. Open a stage to see what goes in, what happens, and what carries forward.
01
Understand
A requirement grounded in the actual site
01Define the outcomeStart with the task, product variant, and result you need.
Bring drawings, SOPs, specifications, and acceptance criteria. Review proposed requirements against their cited original pages. Resolve conflicting instructions and missing criteria.
Carries forwardReviewed requirements with links to their sources.
02Connect the siteKnow which equipment and evidence the task depends on.
Register machines, stations, tools, sensors, documents, and permitted data sources. Keep exact configurations and access limits attached to the work.
Carries forwardA site and source record tied to the right configuration.
03Make the data usableGive each signal a meaning that engineers can check.
Inspect samples, map fields and units, validate the interpretation, and publish a reviewed version. Keep commanded values separate from measurements and missing evidence.
Carries forwardVersioned mappings and an explicit evidence plan.
02
Prepare
Reusable checks, data, and candidate models
04Build the checkTurn the requirement into an inspectable calculation or workflow.
Compose reusable calculations, checks, reports, or rules in Function Studio. Connect named sources and typed blocks, add reviewed custom operations, and validate before running.
Carries forwardA versioned check with its inputs, criteria, and outputs.
05Prepare the evidenceCapture, replay, and label the cases the check must handle.
Plan source coverage and calibration. Preserve originals, synchronise available signals, record data loss, and review annotations and dataset rights before admitting a dataset.
Carries forwardTraceable evidence and separate training and test sets.
06Prepare a candidateChoose or adapt a model for the defined task.
Select a compatible method and runtime, retain the training recipe and exact dataset version, and record candidate outputs. A new candidate stays separate from the active station version.
Carries forwardA reproducible candidate ready for evaluation.
03
Qualify
Evidence for an authorised deployment decision
07Test before releaseCompare against the agreed criteria and a fixed baseline.
Evaluate held-out cases, difficult variants, and known failures. Use replay, simulation, and physical trials as the task requires. Review false accepts, false rejects, and missing coverage.
Carries forwardAn evaluation record showing where the candidate meets the criteria.
08Approve the exact versionKeep qualification, promotion, and activation as separate decisions.
Review the candidate, configuration, evidence, and exclusions. Pin the authorised version to its station, preserve the previous baseline, and define rollback conditions.
Carries forwardAn approved configuration with release and rollback history.
09Run and verifyConnect each unit and operation to its measured result.
Resolve the product and variant, apply the pinned check, and retain the evidence. Keep model observations, deterministic rules, and the physical result distinct; route uncertainty for review.
Carries forwardAn inspection or process result with supporting evidence.
04
Operate & improve
A result that informs the next change
10Review and correctCarry a finding through hold, correction, and reinspection.
Let Quality inspect the evidence, assign corrective work, and link a fresh result to the original finding. Keep release, rejection, and continued hold under the authorised reviewer.
Carries forwardA complete decision and correction history.
11Monitor and reconstructSee performance, investigate incidents, and assess changes.
Follow shared KPIs, alarms, and service levels. Reconstruct the event sequence, compare against the accepted configuration, and identify affected checks and evidence.
Carries forwardAn incident record or a focused revalidation worklist.
12Improve and reuseBring accepted knowledge into the next variant or site.
Reuse eligible mappings, checks, and deployment history. Evaluate candidate improvements against retained baselines before another release. Keep private learning and cross-customer reuse under separate permissions.
Carries forwardA reviewed improvement with its next qualification steps.
Example · a new product variant
A revised drawing changes the inspection criteria. Review the requirement, prepare the affected check, test it on the new variant, then approve its station version. Each result stays linked to the drawing and check that produced it.
One connected site
Production, machines, materials, and Quality share the same context.
Engineering & commissioning
Reusable checks, FAT, SAT, UAT, acceptance baselines, and revalidation after a change.
Operations & material flow
Fleet and site performance, alarms, incident review, service levels, and qualified dispatch workflows.
Physical AI & adaptation
Outcome-linked episodes, simulation and policy evaluation, approved interventions, and controlled model improvement.
Deployment scope is agreed around the task, available interfaces, and required qualification. People approve consequential decisions; existing machine controls and certified safety systems retain their authority.
Model adaptability
A new product.
Less work repeated.
Keep what the previous application taught us. Adapt the examples, criteria and setup for the next part, station or machine.
Start with accepted parts.
Use existing examples, drawings and inspection criteria. Evaluate pretrained models before deciding what needs extra training.
Combine the checks the job needs.
Check appearance with vision, verify a sequence with machine events and use tool or sensor readings where an image is not enough.
Improve from your team’s feedback.
Collect corrections from Quality and operators. Test the next version for missed faults, false rejects and cycle time before release.
Measure the engineering saved.
Track what can be reused and what still needs changing when we add the next product or station.
Work with the equipment you already have
Connect the machine,
the process and the records.
Start with available exports and recordings. Add live connections where your site permits them. Each interface is checked for the application.
Machines
What the equipment reports
Robot controllers, ROS 2, MCAP, rosbag2, VDA 5050, MQTT, PLCs, OPC UA, doors, lifts, conveyors, chargers, and cells.
Operations
What the site and business systems know
WCS, WES, WMS, FMS, MES, SCADA, historians, databases, APIs, files, orders, missions, alarms, and maintenance events.
Project record
What the deployment must achieve
Requirements, interface specifications, drawings, risk controls, test procedures, measurements, media, witness records, deviations, and approvals.
Inspection can also use cameras, lighting, measurement tools and force, displacement or tool-result signals. Data access, training and reuse rights are agreed with your team.
The full capability catalogue
From the first requirement
to daily operation.
Explore the detailed work we can discuss for your application. The delivery plan identifies the capabilities, integrations and validation needed for your site.
Requirements and preparation
- Original document retention and page-level citations
- Requirement proposals, contradictions and human review
- Source samples, mapping validation and version publication
- Function Studio: reusable calculations, checks, reports and rules
- Typed graph authoring and reviewed custom operations
Data, models and qualification
- Capture planning, calibration and synchronised replay
- Dataset admission, annotation review and permitted use
- Training recipes, model versions and candidate evaluation
- Held-out tests, variant comparisons and qualification evidence
- Separate promotion, station activation and rollback
Inspection and Quality
- Unit and variant identity with pinned inspection criteria
- Model observations separated from deterministic decisions
- Evidence review, hold and non-conformance
- Corrective work linked to fresh reinspection
- Authorised release, rejection and decision history
Data and context
- Source and asset inventory with access limits
- Vendor tag mapping into reviewed system concepts
- Data-quality, coverage and provenance reporting
- Configuration, firmware and layout versioning
- Session capture, storage and replay
Operations
- Cross-vendor KPI and exception reporting
- Availability, utilisation and throughput
- Waiting, blocking and charging analysis
- Alarm definition, routing and suppression
- Trend and degradation detection
- Shift, site and management reporting
Verification
- Sequence, timing and invariant checks
- Interface and handshake verification
- Fault-matrix and edge-case checks
- Regression checks against a reference period
- Replay against recorded or simulated data
- PASS, FAIL and NOT VERIFIABLE results
Project and assurance
- System boundary and responsibility matrix
- Requirement, risk, control and evidence matrix
- Evidence-readiness planning before a test
- Commissioning and FAT, SAT, UAT execution
- Deviations, punch items, retests and closure
- Witness review, sign-off and approval history
After acceptance
- Accepted deployment baselines
- SLA and contracted-performance records
- Change-impact paths across the baseline
- Stale-evidence detection and retest scope
- Incident timelines across systems
- Revalidation governance and history
Output and integration
- Acceptance, handover and audit packs
- Traceability from criterion to signature
- HTML, PDF, DOCX, JSON and API exports
- Notifications, tickets and work orders
- Multi-site and multi-tenant management
- Private, on-premises or air-gapped deployment
Qualified operations and Physical AI
- Remote intervention and teleoperation with defined authority
- Dispatch, material flow and approved control workflows
- Episodes linking requirements, actions and measured outcomes
- Simulation, benchmark and policy evaluation
- Private improvement with separate cross-customer reuse permissions
SOP and operator verification
- Required-step and sequence checks
- Tool results and machine events linked to an operation
- Missed-step alerts and operator review
- Unit-level work history and evidence
Machine programs and controller transfer
- Candidate PLC logic, recipes and parameter changes
- I/O, sequence, interlock and timing checks
- Source-to-target controller mapping
- Program differences, test cases and approved versions
Your first application
Bring the task.
Define what working means.
Start with a part to inspect, an SOP to verify, a program to adapt or a report your team prepares manually. Bring the drawings, criteria and records you already have.
01 / Agree the resultName the decision, cycle time and conditions the application must meet.
02 / Test on your workRun the agreed workflow on actual parts or process records. Retain the inputs and results.
03 / Review togetherLet your team challenge the result, close gaps and agree the next release.
Inspection is our first application under validation. Broader automation is developed and qualified for the agreed equipment and process. Machine changes remain under your Controls team’s authority.
Before we begin
The practical questions.
Can we start with one task?
Yes. Start with the work you need to automate and the result that would make it useful. We review the equipment, available data and acceptance criteria, then agree the application and its tests.
Do we need to replace our PLCs or existing systems?
We first assess the equipment and interfaces you already use. The application may work from exported files or recorded data, or need live signals and additional capture equipment. Required changes are identified before implementation.
Do we need a fully labelled defect dataset?
Start with existing accepted examples, criteria, drawings, available parts and independently confirmed challenge cases. We establish what is missing for the specific decision and arrange collection where needed.
Can a camera verify every assembly condition?
No. Presence and appearance may be visible while engagement, strength or a hidden step may require another view, measurement or process signal. The inspection must name what its evidence can establish.
Will Mekai automatically reprogram our machines?
We are developing program generation and adaptation for PLC logic, recipes and machine programs. Each controller and application needs testing. Your Controls team approves live changes, and existing machine protection remains in place.
Can our factory data stay private?
Data access, storage, training rights and any reuse are agreed for your site. Private and on-premises deployment needs are assessed as part of the application.
Can our engineering team access the technical tools?
Existing open tools remain a technical foundation within the broader Mekai Platform direction. Discuss access, integrations and your team’s requirements with us.
Ask about the technical toolsMekai Labs
What does your team need to automate?
Bring the task, the equipment you use and the result you need. We’ll work through the application with you.
Schedule a call