> For the complete documentation index, see [llms.txt](https://engineering.umh.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engineering.umh.app/product/who-we-build-for/production-ot-team.md).

# Production: OT team

The people who keep the machines running, know their data, and connect them to UMH.

OT (operational technology) is what controls the machines, such as PLCs, sensors and the screens next to them. The OT team builds and maintains it. It is made up of automation technicians, PLC programmers, and electrical and mechanical engineers. They keep the machines running and change the control logic.

## Connecting and contextualizing

**The OT team knows which data a machine has and what it means.** It connects the machines in the Management Console and adds that knowledge. For example, it states in the [bridge](https://docs.umh.app/usage/data-flows/bridges) that the S7 address DB1.DBD4 is the temperature in degrees Celsius.

20 machines of the same model can each use different variable names. Only the responsible OT person knows which is which.

## Why the OT team needs the UI

**The power user's apps depend on what the OT team knows about the machines.** So the OT team has to work in UMH too. It only does that if it likes the UI.

People in the OT team are usually not [power users](/product/who-we-build-for/the-power-user.md). Most systems they work with have a UI. They avoid a new tool that looks like code, because it feels like one more thing to learn.

[Platform teams](/product/who-we-build-for/it-platform-and-data-teams.md) want all configuration as YAML in Git, like the rest of their code. That is exactly where the OT team switches off. So platform teams often struggle to get the OT team to use their tools. In UMH, the platform team writes the configuration in YAML. Because of [code and UI](/product/product-standards/code-and-ui.md), someone from the OT team can open the same configuration in the UI and add what they know about the machines.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://engineering.umh.app/product/who-we-build-for/production-ot-team.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
