> 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/product-standards/code-and-ui.md). # Code and UI Everything in UMH can be configured in YAML or in the UI. Owner: Jeremy Everything in UMH can be configured in YAML or in the UI. When a power user or an LLM writes the YAML in the background, production management and the OT team can still read and change it in the UI. ## Rules * We limit the YAML to what the UI can render. We accept that some things are then not possible in the YAML. * When we build a feature, we always start with the code and add the UI afterwards. UMH is built on [infrastructure as code](https://en.wikipedia.org/wiki/Infrastructure_as_code). The whole configuration of an instance lives in a single YAML file. ## Why we start with code **We build UMH on IT and OT best practices first.** For example, you can keep the YAML file in Git. The data follows the ISA-95 levels, from the enterprise down to the work cell. Other vendors often start with easy usability and try to add best practices later. Many of them never manage it. That is why UMH feels a little more complex at the start than those products. Because we at UMH start with best practices, we can scale more easily across lines and plants. What we then do in our daily business is make those best practices easier to use and less error-prone by pouring them into a product with [opinionated simplicity](/product/product-standards/opinionated-simplicity.md). ## Why the UI **Production management and the OT team work in the UI.** The [power user](/product/who-we-build-for/the-power-user.md) usually prefers code, because they do so much in the system that code scales better for them. The [OT team](/product/who-we-build-for/production-ot-team.md) knows the machines. Because the power user's apps depend on that knowledge, the OT team has to work in UMH too. Most systems the OT team works with have a UI. The OT team avoids a new tool that looks like code, because it feels like one more thing to learn. For example, an LLM can use a CLI to fill in the tables you see in the UI. Someone can then guide the non-developers in the plant, such as production management or the OT team, through the results in the UI. --- # 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/product-standards/code-and-ui.md?ask=&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.