# Object Description Enrichment The `` on a Custom Object must read like human-written documentation. --- ## When & How — always compose, confirm the text, write A `` is **mandatory** — always compose one. Do it when **creating** the object and again on **any** change: adding, updating, or deleting a field **or a validation rule** (keeps it from going stale). Validation-rule changes count exactly like field changes — the change isn't done until the description is refreshed. Never ask *whether* to add a description; the only thing to confirm is the **wording**. **Confirm per change.** Propose and confirm on **each** change separately. A prior "keep current" applies to that one change only — it is never standing permission to skip the proposal on a later change. Why confirm the wording: an existing description may be hand-authored by an admin (carrying context the schema can't reveal) or generated earlier — you can't tell which from the file, so don't overwrite it silently. **Compose** the description (Steps 1–2 below). If one already exists, use it as a **strong signal** — preserve its business context and fold the new field/rule in; don't discard good prose. Then branch: - **No existing description (brand-new object):** nothing to overwrite — just write the composed description. **Do not prompt.** - **An existing description (update / delete / any re-enrichment):** never overwrite it silently. Show the proposal, ask, and **STOP — wait for the user's reply before writing:** ```text Proposed description for