---
title: "Machine monitoring solution architecture governance"
slug: "machine-monitoring-governance"
updated: 2025-12-22T17:32:00Z
published: 2025-12-22T17:32:00Z
canonical: "support.tulip.co/machine-monitoring-governance"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.tulip.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Machine monitoring solution architecture governance

*Learn about when to centralize your machine monitoring solution and change management best practices.*

## When to centralize

Use centralized architecture (single app for a Machine Type) when:

- **Standardized processes** exist across all machines of same type
- **Full-time development team** manages applications
- **Rapid iteration is needed** - changes must propagate quickly
- **Compliance requirements** demand version-controlled, auditable app changes

**Example**: Pharmaceutical manufacturer with 20 identical tablet presses. FDA requires a validated process. A single app ensures all machines follow an identical, validated procedure.

## When to decentralize

Use decentralized architecture (separate apps per machine) when:

- **Custom workflows** per machine instance
- **Citizen developers** in different departments own their machines
- **Proof-of-concept** or pilot projects with unclear requirements
- **Low change frequency** - apps rarely need updates

**Example**: Job shop with 5 different CNC mill models. Each has unique tool libraries, part programs, and operator workflows.

## Change management best practices

### Machine types and triggers are global

- Changes to a machine type **immediately affect all machines of that type**
- Machine types do not have a versioning system (unlike apps)
- **Best practice**: Test machine type changes in a development instance first

### Version control strategy

1. **Dev instance**: Test new machine types and triggers
2. **Staging instance** (if available): Validate with production-like data
3. **Production instance**: Deploy only after validation
4. Document changes in release notes

### Rollback plan

- You cannot roll back machine triggers - you must manually revert them
- As Machine configurations are not versioned, consider creating duplicates (e.g. of Machine Types and Machine Type Triggers) or offline documentation before making high-impact changes.

---

Did you find what you were looking for?

You can also head to [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) to post your question or see if others have solved a similar topic!

**Machine Type**

**Machine Types** are global definitions of what data to expect from machines of different types. Each Machine Type will have different states, **triggers**, and **attributes**. *EX. We have 5 makes/models of CNC mill, but they all have the same set of attributes (Spindle speed, feed rate, etc.) These can all be combined into a single "CNC Mill" Machine Type*