---
title: "Update an Operation Rule"
method: PATCH
path: "/v2/org/{org}/nico/task/rule/{id}"
tags: ["Rule"]
---

# Update an Operation Rule

`PATCH /v2/org/{org}/nico/task/rule/{id}`

Patch the mutable fields of an Operation Rule: `name`, `description`, and
`ruleDefinition`. Unset fields are left unchanged. The rule definition is
re-validated server-side; validation failure leaves the rule untouched.

`operationType` and `operationCode` are immutable after creation — create a
new rule and delete the old one to change them.

Org must have an Infrastructure Provider entity. User must have authorization
role with `PROVIDER_ADMIN` suffix.

## Request body

- UpdateRuleRequest — Request body for patching an Operation Rule. All mutable fields are optional; unset fields are left unchanged. At least one of `name`, `description`, `ruleDefinition` must be provided.
  - `siteId` string, uuid, required — ID of the Site that owns the rule.
  - `name` string — New rule name. Must be non-empty when provided.
  - `description` string — New free-form description.
  - `ruleDefinition` RuleDefinition — Executable definition of a rule. Structurally identical to Flow's own rule schema, so an existing YAML rule file maps across field for field. The fields declared here use `camelCase` (`componentType`, `mainOperation`, `pollInterval`) rather than the `snake_case` of Flow's YAML; keys inside the free-form `parameters` map pass through unchanged and stay `snake_case` (`expected_status`, `component_types`).
    - `version` 'v1', required — Schema version. Currently always `v1`.
    - `steps` SequenceStep[] — Ordered execution steps. Steps with the same `stage` run in parallel, stages run sequentially in ascending numerical order. May be empty for operations whose sequencing is hardcoded in Flow (e.g. bring-up, firmware update).
      - `componentType` string, required — Component type this step targets. Validated against Flow's component-type set: `Compute`, `NVSwitch`, `PowerShelf`, `ToRSwitch`, `UMS`, `CDU`. Matched case-insensitively.
      - `stage` integer, required — Stage number; steps with the same stage run in parallel, lower stages run first. Component types must be unique within a stage.
      - `maxParallel` integer — Maximum number of components of this type processed concurrently. `0` means unlimited, `1` means strictly sequential.
      - `timeout` string — Optional child-workflow timeout for this step, as a Go duration string (e.g. `30s`, `2m`). Applies to pre + main + post combined.
      - `retry` RetryPolicy — Retry behavior for a step's child workflow.
        - `maxAttempts` integer, required — Maximum number of attempts including the first.
        - `initialInterval` string, required — Initial retry interval, as a Go duration string (e.g. `1s`).
        - `backoffCoefficient` number, required — Exponential backoff multiplier; must be `>= 1.0`.
        - `maxInterval` string — Optional cap on retry interval, as a Go duration string.
      - `preOperation` ActionConfig[] — Actions to run before the main operation.
        - `name` 'Sleep' | 'PowerControl' | 'VerifyPowerStatus' | 'VerifyReachability' | 'GetPowerStatus' | 'FirmwareControl' | 'VerifyFirmwareVersion' | 'VerifyFirmwareConsistency' | 'BringUpControl' | 'WaitBringUp' | 'InjectExpectation', required — Executor-agnostic action name. Server-side validated; unknown names fail the rule definition.
        - `timeout` string — Optional per-action timeout override as a Go duration string (e.g. `30s`, `2m`).
        - `pollInterval` string — Poll interval for actions that loop (e.g. `FirmwareControl`, `VerifyPowerStatus`) as a Go duration string.
        - `parameters` object — Action-specific parameters. Validated server-side against the action's schema. Examples: - `Sleep`: `{ duration: "30s" }` - `PowerControl`: `{ operation: "power_on" }` — an operation code, not a power state; optional within a `PowerControl` rule, where the operation is taken from the Task - `VerifyPowerStatus`: `{ expected_status: "on" }` - `VerifyReachability`: `{ component_types: ["Compute"], require_all: true }` - `FirmwareControl`: `{ poll_interval: "10s", poll_timeout: "30m" }`
      - `mainOperation` ActionConfig, required — Configuration for a single action within a step.
        - `name` 'Sleep' | 'PowerControl' | 'VerifyPowerStatus' | 'VerifyReachability' | 'GetPowerStatus' | 'FirmwareControl' | 'VerifyFirmwareVersion' | 'VerifyFirmwareConsistency' | 'BringUpControl' | 'WaitBringUp' | 'InjectExpectation', required — Executor-agnostic action name. Server-side validated; unknown names fail the rule definition.
        - `timeout` string — Optional per-action timeout override as a Go duration string (e.g. `30s`, `2m`).
        - `pollInterval` string — Poll interval for actions that loop (e.g. `FirmwareControl`, `VerifyPowerStatus`) as a Go duration string.
        - `parameters` object — Action-specific parameters. Validated server-side against the action's schema. Examples: - `Sleep`: `{ duration: "30s" }` - `PowerControl`: `{ operation: "power_on" }` — an operation code, not a power state; optional within a `PowerControl` rule, where the operation is taken from the Task - `VerifyPowerStatus`: `{ expected_status: "on" }` - `VerifyReachability`: `{ component_types: ["Compute"], require_all: true }` - `FirmwareControl`: `{ poll_interval: "10s", poll_timeout: "30m" }`
      - `postOperation` ActionConfig[] — Actions to run after the main operation.
        - `name` 'Sleep' | 'PowerControl' | 'VerifyPowerStatus' | 'VerifyReachability' | 'GetPowerStatus' | 'FirmwareControl' | 'VerifyFirmwareVersion' | 'VerifyFirmwareConsistency' | 'BringUpControl' | 'WaitBringUp' | 'InjectExpectation', required — Executor-agnostic action name. Server-side validated; unknown names fail the rule definition.
        - `timeout` string — Optional per-action timeout override as a Go duration string (e.g. `30s`, `2m`).
        - `pollInterval` string — Poll interval for actions that loop (e.g. `FirmwareControl`, `VerifyPowerStatus`) as a Go duration string.
        - `parameters` object — Action-specific parameters. Validated server-side against the action's schema. Examples: - `Sleep`: `{ duration: "30s" }` - `PowerControl`: `{ operation: "power_on" }` — an operation code, not a power state; optional within a `PowerControl` rule, where the operation is taken from the Task - `VerifyPowerStatus`: `{ expected_status: "on" }` - `VerifyReachability`: `{ component_types: ["Compute"], require_all: true }` - `FirmwareControl`: `{ poll_interval: "10s", poll_timeout: "30m" }`
      - `delayAfter` string — Deprecated legacy field — sleep duration after this step, as a Go duration string. Prefer encoding the wait as an explicit `Sleep` post-operation action.

## Response `204`

Rule was updated.

## Other responses

- `400` — Error response when request data cannot be validated
- `403` — Error response when user is not authorized to call an endpoint or retrieve/modify objects
- `404` — Error response when requested object is not found
- `504` — The Site did not return a result within the request budget allocated to Site communication within the request cycle. This can occur if the Site Controller is down or under heavy request load. Operations are in general safe to retry. In rare cases, operations that create or update resources may succeed even if timeout is returned.

## Changes

> 90 revisions in range; 4 could not be searched.

- **2026-08-14** `441cfc1afc1c` — 1 info
  - added the non-success response with the status `504`
- **2026-06-10** `9a135fa35aad` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/nvidia/apis/nvidia-infra-controller-rest-api/changes/v2/org/:org/nico/task/rule/:id/patch.md)

---

[API](https://skmtc.dev/nvidia/apis/nvidia-infra-controller-rest-api.md) · [All operations](https://skmtc.dev/nvidia/apis/nvidia-infra-controller-rest-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/nvidia/nvidia-infra-controller-rest-api/revisions/2096eb1db2c1/schema)