Least necessary access
- Public copy
- People and services should receive only the access required for their assigned responsibility and scope.
SECURITY & DATA TRUST
Merikh is designed for environments where reliability, safety, and accountability matter. Our approach connects data quality, role-based access, traceability, and governed AI so teams can understand not only what the platform shows, but why they can trust it.
Every factory has a different network, risk profile, and operating model. Merikh begins by mapping the approved data sources, connection paths, asset scope, users, and decision boundaries for the deployment. The final architecture is confirmed with the customer’s technical stakeholders before implementation.
| Principle | Public copy |
|---|---|
| Least necessary access | People and services should receive only the access required for their assigned responsibility and scope. |
| Traceable data | Operational values should be connected to their source, timestamp, quality state, and relevant context. |
| Accountable action | Recommendations, approvals, assignments, and outcomes should remain reviewable. |
| Bounded AI | AI behavior should be limited by role, asset scope, permitted actions, and explicit approval rules. |
Industrial data can be stale, incomplete, mislabeled, duplicated, or disconnected from production context. Merikh is designed to make those conditions visible before a KPI, alert, or recommendation is treated as reliable.
Signal quality, availability, freshness, mapping, and calculation logic should be validated as part of the operational baseline.
Merikh’s role model is intended to govern who can view information, make decisions, approve actions, and act within a defined factory, line, asset, or workflow scope. Workspace access and administrative responsibilities are confirmed during deployment.
Where AI is used, the experience should make the supporting evidence, confidence, applicable scope, required approval, and action history available to the user. Deterministic industrial calculations remain separate from language-model reasoning.
Deployment topology, network segmentation, data movement, retention, encryption, remote access, and integration permissions vary by scope. Merikh provides the current architecture and control details during technical evaluation. We do not publish deployment or compliance claims until they are verified for the relevant release and customer environment.
If your team has a security questionnaire, architecture review, or data-governance requirement, share it with us. We will answer against the current product and approved roadmap, clearly separating what is available today from what is planned.