FREQUENTLY ASKED QUESTIONS
Clear answers for teams evaluating a Factory OS.
Learn how Merikh approaches industrial connectivity, operational data, performance measurement, AI, deployment, security, and customer evaluation.
What is Merikh?
Merikh is a Factory OS and industrial intelligence platform. It connects machines, systems, production context, and operational roles in one shared model, then helps teams move from data to insight, recommendation, action, and measured outcome.
Is Merikh an OEE dashboard?
No. OEE and production visibility can be important starting points, but Merikh is designed to connect performance data with loss analysis, role-based decisions, operational workflows, and continuous improvement.
Does Merikh replace our ERP, MES, SCADA, PLCs, or maintenance system?
Merikh is designed to work with the systems and equipment a factory already operates. It adds a shared operational context and coordination layer. The exact relationship with existing systems is defined during technical assessment.
Who is Merikh built for?
Merikh is designed for factory leadership, production, maintenance, quality, continuous improvement, operators, engineering, and IT/OT teams that need to work from the same operational reality.
Can Merikh connect to legacy machines?
Legacy equipment can often be included through an appropriate data path, which may involve a controller, drive, gateway, sensor, database, camera, or operator input. Compatibility and signal quality are assessed for the actual machine and scope.
Which industrial protocols does Merikh support?
Merikh is being designed around common industrial integration paths including OPC UA, MQTT, Modbus, supported APIs, camera streams, and edge gateways. Exact protocol, device, and version compatibility is confirmed through the current compatibility matrix and technical assessment.
Do we need to replace existing equipment?
The goal is to use the factory’s existing assets wherever a reliable and safe data path is available. Additional gateways, sensors, cameras, or edge equipment may be recommended when the required signal is not otherwise accessible.
Will integration require changes to our PLC program?
It depends on the machine, controller, available signals, access policy, and chosen integration path. Merikh does not make a universal no-change claim; the technical approach is reviewed before deployment.
What happens if our data is incomplete or inconsistent?
Data quality is validated before KPIs or recommendations are treated as trustworthy. Missing context, stale signals, conflicting mappings, and manual gaps should be made visible and resolved as part of the baseline.
How does Merikh calculate OEE?
OEE is calculated through deterministic logic using agreed definitions for Availability, Performance, and Quality. The formula, source data, planned-time rules, and relevant context should be visible and reviewable. A language model is not used as the calculation engine.
What data is required for OEE?
The exact requirement depends on the process, but typically includes planned production time, run and stop states, ideal or target rate, total output, and accepted versus rejected output. Product, order, shift, and reason context improve interpretation.
Can operators add downtime reasons or production context?
Operator input can be part of the operational evidence when machine signals alone cannot explain an event. The workflow, permissions, reason taxonomy, and validation rules are configured for the deployment.
Does Merikh only focus on OEE?
No. OEE is one signal. Depending on the solution, Merikh can organize work around downtime, utilization, throughput, schedule attainment, maintenance response, quality, waste, and other approved operational measures.
What does AI do in Merikh?
Merikh’s AI direction is to help users investigate factory conditions, explain evidence, prioritize issues, recommend next actions, and coordinate workflows using operational context.
Does AI calculate industrial KPIs?
No. Industrial KPIs should be calculated through deterministic, versioned logic. AI may help explain a result or investigate contributing factors, but it should not replace the calculation engine.
Can Merikh control machines automatically?
Direct physical control is not assumed. Any action must be limited by the available capability, approved integration, role and asset scope, safety requirements, and explicit permission. Human approval remains part of the design wherever required.
How can we trust an AI recommendation?
A trustworthy recommendation should be connected to supporting evidence, show relevant context and uncertainty, operate within defined authority, and preserve the approval and action history for review.
How does a Merikh deployment begin?
We begin with the factory context, the operational problem, the available data, and the people responsible for the decision. The initial scope is usually a measurable line, machine group, process, or loss—not the entire transformation at once.
How long does deployment take?
Timing depends on asset access, integration paths, data quality, operating constraints, security review, and pilot scope. We confirm a realistic plan after assessment rather than promising a universal deployment time.
Can Merikh support multiple factories?
The platform direction supports standardized capabilities with factory-specific configuration. Multi-site scope, data boundaries, governance, and rollout sequencing are confirmed during evaluation.
Is Merikh cloud, edge, or on-premises?
Deployment topology depends on the current product release, factory network, data policy, latency needs, and approved architecture. The available options are reviewed during the technical assessment; no topology should be assumed from marketing copy alone.
How is access controlled?
Access is intended to follow role, responsibility, workspace, and asset scope. Current authentication, administration, audit, and permission details are provided during technical evaluation.
Does Merikh have security certifications?
Only current, formally verified certifications are published. Ask our team for the latest security overview and compliance roadmap relevant to the release you are evaluating.
What will we see in a demo?
The demo is structured around your factory context and priorities. We review the relevant operating problem, show the applicable platform workflow, discuss available data and integration paths, and identify what would need validation before a pilot.
How is pricing determined?
Pricing is based on the approved scope, including factors such as sites, assets, solutions, integration requirements, deployment model, and support needs. We do not publish a generic price before understanding the factory context.
What happens after we request a demo?
Our team reviews the information you provide, confirms the most relevant technical and operational participants, and proposes the appropriate next conversation. Any pilot scope is defined only after fit, access, and measurement requirements are understood.