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

# Change Management (GMUD)

> Plan, approve, and execute changes to your environment through a governed workflow — standard changes and update patches alike, each with a full audit trail.

import { CardGroup, Card, Note, Tip, Warning, Steps, Step } from '@mintlify/components';

**Change Management** is where every change to your environment is planned, reviewed, approved, and executed under control. Each change is recorded as a **GMUD** (*Gestão de Mudança* — a change record), and nothing that touches a system runs until the right people have approved it. It's the same principle as the rest of Myrmex — **the AI proposes, you approve** — applied to the moment a change actually lands.

<Note>
  A **GMUD** is a single change request: what will change, why, on which systems,
  when, how it will be rolled back, and who signed off. It carries the change from
  a draft all the way through to a completed, audited execution.
</Note>

## Two Kinds of Change

Change Management handles two kinds of change, and the difference is mainly *how each one runs*:

<CardGroup cols={2}>
  <Card title="Standard change" icon="clipboard-check">
    A change you (or the AI) plan out — a configuration edit, a firewall-rule
    change, a maintenance task. It has an **implementation plan** and a
    **rollback plan**, and once approved you start it explicitly with **Execute**.
    The agents then carry out the steps.
  </Card>

  <Card title="Update patch" icon="download">
    An operating-system patch rollout that originates in the
    [Updates](/documentation/agent-endpoint-security/patch-management) area. The AI
    schedules the pending patches into a **maintenance window**; once approved, the
    agent **installs them automatically in that window** — no manual Execute.
  </Card>
</CardGroup>

Both kinds share the same lifecycle, the same approval gate, the same change window, and the same audit trail. They differ only at execution time: a standard change is triggered on demand, a patch runs inside its scheduled window. The [approval workflow](/documentation/change-management/approvals) covers both.

## The Lifecycle of a Change

A GMUD moves through a fixed set of states. The happy path is six stages; a handful of exception states close a change that didn't complete normally.

<Steps>
  <Step title="Draft">
    The change is being written — identification, justification, risk, window,
    and the implementation/rollback steps. Fully editable.
  </Step>

  <Step title="Submitted">
    Sent for approval. It now waits on approvers according to the matching
    [approval rule](/documentation/change-management/approvals#approval-rules).
  </Step>

  <Step title="Approved">
    Enough approvals were recorded. A standard change is now ready to **Execute**;
    a patch is ready to run in its window.
  </Step>

  <Step title="Scheduled">
    The change is queued for its **change window**. While scheduled, the record
    auto-refreshes every 60 seconds.
  </Step>

  <Step title="Executing">
    The agents are running the steps. For a patch, the packages are installing on
    the target hosts.
  </Step>

  <Step title="Completed">
    Every step finished successfully. The change is closed and fully audited.
  </Step>
</Steps>

Outside the happy path, a change can also end as:

| State           | Meaning                                                                               |
| --------------- | ------------------------------------------------------------------------------------- |
| **Rejected**    | An approver declined it during the approval gate — the flow ends.                     |
| **Cancelled**   | Called off before execution (allowed while draft, submitted, approved, or scheduled). |
| **Partial**     | Execution finished but only some steps/items succeeded.                               |
| **Failed**      | Execution did not succeed.                                                            |
| **Aborted**     | Execution was stopped in flight.                                                      |
| **Rolled back** | The rollback plan was applied to undo the change.                                     |

<Warning>
  **Editing a change after it's been submitted resets it.** Editing a change that
  is submitted, approved, or scheduled cancels any dispatched execution and reverts
  it to **Draft** — it has to be submitted and approved again. This is deliberate:
  an approved change is approved *as written*.
</Warning>

## Anatomy of a Change

Every GMUD is a structured document. When you open one, it's organized into the sections a change-advisory board would expect:

<CardGroup cols={2}>
  <Card title="Change Identification" icon="tag">
    Title, status, **change type**, technical **category**, and **kind** (standard
    change or patch).
  </Card>

  <Card title="Context and Justification" icon="circle-info">
    The problem or motivation, the goal and expected outcome, and what is
    explicitly **in scope** and **out of scope**.
  </Card>

  <Card title="Risk and Impact Assessment" icon="triangle-exclamation">
    Probability, impact, and the **final risk level**; impacted services and users,
    expected downtime, security/compliance risks, and dependencies.
  </Card>

  <Card title="Affected systems (CIs)" icon="server">
    The devices and integrations the change touches, each linked as **affected** or
    **dependent** — so the blast radius is explicit.
  </Card>

  <Card title="Change Window" icon="calendar-days">
    Start and end of the maintenance window, plus stakeholder communication. The
    record shows when the window opens and closes.
  </Card>

  <Card title="Implementation & Rollback Plans" icon="list-ol">
    The ordered **steps** to make the change and the steps to undo it — see below.
  </Card>
</CardGroup>

### Implementation and rollback steps

The plan is a list of ordered **steps**, each tagged **Implementation** or **Rollback**. A step records the activity, its order, an owner, an expected duration, and — optionally — a **target** (a specific device or integration) and an action to run there. During execution, each step shows its own status, so you can see exactly how far the change got and what remains if something needs to be undone.

<Tip>
  A solid rollback plan is what makes a change safe to approve. Ask the AI to draft
  it for you — *"add a rollback plan that reverts this firewall rule change."*
</Tip>

## How You Get There

Open **Change Management** from the **Directory** on the left of the console. It lists your changes for the [context](/documentation/get-started/concepts#how-your-account-is-organized) you have selected — standard changes and patch changes are shown with distinct icons — and each one opens as a tab in the Workspace. Viewing it requires the `gmuds.read` permission.

You can also bring a change into a conversation: **`@`-mention** a change (or a patch) as a [context entity](/documentation/multi-agent-system/overview) and ask the AI about it, or ask it to draft or adjust one.

## Where the AI Fits

Change Management is deeply tied to the agents:

* **Drafting** — ask [Centurion](/documentation/multi-agent-system/agent-orchestrator) to prepare a change and it fills in the identification, risk, window, and a first implementation/rollback plan for you to review.
* **Proposing patches** — the AI reviews pending updates and proposes a patch change (a patch-kind GMUD) with a maintenance window (see [Patch & Update Management](/documentation/agent-endpoint-security/patch-management)).
* **Execution** — once you approve (and, for a standard change, click **Execute**), the agents run the steps, driven from the Workspace.

Throughout, **you hold the gate**: no change leaves the approval stage without a human decision, and every action — human, agent, or system — is written to the change's history.

## Activity Trail and Export

Every GMUD carries an **Activity** timeline: when it was created and by whom, each approval or rejection (with the reason given), each step as it executed, and the last update. It answers *"who did what, and when?"* on the record itself. You can also **export the change as a PDF** — for a change-advisory board or an auditor — straight from the record.

## Next

<CardGroup cols={2}>
  <Card title="Approval workflow & rules" icon="user-check" href="/documentation/change-management/approvals">
    How submit → approve → execute works, and how to govern who must approve what.
  </Card>

  <Card title="Patch & Update Management" icon="download" href="/documentation/agent-endpoint-security/patch-management">
    Review pending OS updates and approve the patch schedules the AI proposes.
  </Card>
</CardGroup>