Skip to content

SOP-021 — Rename a unit

Guide

<!-- last-reviewed: 2026-06-01 · owner: human-resources -->

SOP-021 — Rename a unit

SOP · owner: Human Resources. Layer: SOP/Runbook (docs/canon.md). Renaming units is explicitly an HR responsibility (ORG.md HR section; JD). A rename is a single, atomic structure change touching every ORG.md reference plus dependents that name the unit. GR-4 need-analysis: beyond the minimum SOP set, a rename is documented separately because it is a distinct recurring procedure with a different blast radius from a roster row edit (SOP-020) — it touches the controlled trigger vocabulary and frozen Interface Contracts (R5).

Interface Contract

  • Inputs: rename request ← from Principal · trigger: “staffing request approved”
  • Outputs: renamed-unit ORG.md → to Documentarian · trigger: “document changed”
  • Outputs: approved ORG.md → to Archivist · trigger: “artifact approved”
  • Handoff trigger (in): an authorized request to rename a unit reaches HR
  • Handoff trigger (out): every reference is updated, prior name noted, chart validates, approved for preservation
  • Definition of Done before handoff:
    • [ ] Rename authorized by the Principal (touches ORG.md — program RACI §7)
    • [ ] Roster-freeze checked — renames are held during the program; proceed only via the exception path
    • [ ] Every ORG.md reference updated: chart node, unit heading, roster, coverage, cross-refs
    • [ ] Prior name noted once for traceability (the status banner / unit note)
    • [ ] Dependents that name the old unit flagged (Handoff Register edges, registry phrases, cross-links)
    • [ ] Mermaid chart validated; affected wave reconciliation re-run flagged to COO/PMO
    • [ ] Learnings captured to docs/knowledge/ if the rename surfaced one

"document changed", "artifact approved", and "staffing request approved" are verbatim registry phrases (staffing request approved is a Wave 1 addition, Operations-approved 2026-06-01).

Purpose

Change a unit’s name (e.g. a provisional name chosen at creation) everywhere it appears, so the org has exactly one current name with no dangling references and a traceable record of the prior name.

When to use

The Principal authorizes renaming a unit. During the Documentation & Knowledge Program the roster is frozen and renames are held (hr/policies/roster-freeze.md) — this SOP documents the steady-state process; execute it only via the freeze exception path while the program is active.

Flow

flowchart LR
  A["Authorized<br/>rename"] --> B["Freeze check +<br/>find all refs"]
  B --> C["Rename in ORG.md<br/>(chart/heading/roster)"]
  C --> D["Note prior name +<br/>flag dependents"]
  D --> E{"Chart<br/>validates?"}
  E -->|yes| F["Hand off +<br/>flag reconciliation re-run"]
  E -->|no| Fix["Fix nodes/edges"]
  Fix --> C
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  classDef g fill:#0f766e,color:#fff,stroke:#134e4a
  class A,B,C,D,F,Fix s
  class E g

Text fallback: from an authorized rename → check the freeze and find every reference → rename across the chart, unit heading, and roster → note the prior name once and flag dependents (Handoff Register edges, trigger registry, cross-links) → validate the chart; fix if needed → hand off (document changed, artifact approved) and flag the affected wave’s reconciliation re-run to COO/PMO.

Steps

  1. Confirm Principal authorization and the freeze exception (renames are held during the program — hr/policies/roster-freeze.md).
  2. Find every reference to the old name: ORG.md chart node, unit heading, roster rows, coverage table, and cross-references elsewhere that name the unit.
  3. Rename consistently across all ORG.md references.
  4. Note the prior name once (status banner or unit note) for traceability — mirror the existing CGEO rename precedent in ORG.md.
  5. Flag dependents: any Handoff Register edge, trigger-registry entry, or doc cross-link that names the old unit as a counterparty — these are Operations/owner updates, not HR edits.
  6. Validate the Mermaid chart.
  7. Hand off: "document changed" (Documentarian), "artifact approved" (Archivist); notify COO/PMO that the affected wave’s reconciliation must re-run for the renamed edges (roster-freeze exception requirement).
  8. Confirm to the requester.

Roles / approvers

HR performs the rename. The Principal authorizes (it touches ORG.md). COO/PMO owns the reconciliation re-run on the renamed edges. Documentarian refreshes the canon index; the Archivist preserves.

Guardrails

  • Renames are frozen during the program — never rename outside the exception path.
  • HR updates ORG.md and the affected agent file(s) only; it flags but does not edit Operations-owned register/registry entries.
  • A rename is atomic — do not leave a half-renamed ORG.md (mixed old/new names is a defect).

See also: hr/hiring-playbook.md (Renames/role changes/offboarding), SOP-020, the charter, hr/policies/roster-freeze.md, interface-contract-spec.md (R5, frozen-edges note).