# Editing before approving

The subject, the body and the recipients of a held reply are all editable, and what you leave behind is exactly what goes out — Connect does not re-write over your changes. The mailbox it is sent from is not editable, because that was settled by the mailbox's role and the thread. Heavy editing is a signal worth acting on rather than a habit worth keeping.

- **Status:** Available
- **Audience:** both
- **In the app:** #/approvals, #/needs-you
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/autonomy/editing-before-approval/

## What you may change

- **The body.** Rewrite as much or as little as you like. The text at the moment of release is the text sent.
- **The subject.** Editable on a new thread; on a reply it usually should not move, because a changed subject can break threading in the recipient's client.
- **The recipients.** Adding somebody who should have been copied is an ordinary correction, not an override of anything.
- **Nothing about the sending identity.** Which mailbox the message leaves from follows from that mailbox's role and the thread it belongs to, so it is fixed on the card.

> **Note** Your edit is final in both directions: the engine will not improve on it after you save, and it will not quietly restore what you deleted. If you cut a paragraph because it was wrong, it stays cut.

## What the change records

An edited release is still one decision, and the decision log keeps it as one: what was decided, by whom, under which rule, and what happened. That record is the difference between "Connect sent this" and "a person sent this, having changed it first", which is exactly the distinction anybody reviewing the account later needs.

It also matters for reading the queue as a quality measure. A month of releases with almost no edits is evidence a channel could run unattended. A month of heavy rewrites is evidence of something else, and the useful response is not to keep rewriting.

## Make the correction stick

1. Notice what you keep changing — a greeting, a price you never quote, a promise about turnaround.
   - Result: A repeated edit is a rule the workspace holds and Connect has not been told.
2. Write it once as a standing instruction, or as a memory entry at the tier it belongs to.
   - Result: Contact tier for one counterpart, channel tier for a whole channel, workspace tier for a house rule — the same four tiers autonomy resolves through.
3. Watch the next few items on that thread or channel.
   - Result: If the correction has landed, the edits stop. If it has not, the instruction was written at the wrong tier or is too vague to act on.

The alternative — editing every reply forever — costs more each month and teaches nothing. It is also invisible: a rewrite leaves no trace in what Connect knows, only in what one person sent on one afternoon. [Memory](/docs/memory/) is where a correction goes to survive.

## Edit or regenerate?

| Situation | Do this | Why |
|---|---|---|
| The tone is slightly off | Edit | Faster than regenerating, and you know what you want |
| A fact is wrong | Fix the source, then regenerate | An edited fact is corrected once; a corrected knowledge entry is right next time too |
| The customer has written again since | Regenerate | Editing does not give the model the newer messages; the reply would answer the older one |
| The reply answers the wrong question entirely | Regenerate | Rewriting from a wrong start is slower than starting again |
| It should not be sent at all | Reject | A rejection is recorded as a decision; deleting the text and releasing an empty message is not |

## Questions

### If I edit a draft, does Connect learn from the change?

Not on its own. An edit changes one message. To change future messages, write the correction as a standing instruction or a memory entry at the tier it applies to — that is the mechanism designed to carry it forward.

### Can I change which mailbox the reply is sent from?

No. That follows from the mailbox's role and the thread the message belongs to, so it is fixed on the card. If the wrong mailbox is answering a kind of message, the fix is in the mailbox roles rather than in the queue.

### Does editing reset the decision, or does it need approving again?

It is still one decision. You change what you want and release it; the log keeps the release against you, and there is no second round of sign-off.

## Related

- [Approvals](https://connectbyjbrh.com/docs/autonomy/approvals/)
- [Rejecting an action](https://connectbyjbrh.com/docs/autonomy/rejecting/)
- [Standing instructions](https://connectbyjbrh.com/docs/autonomy/standing-instructions/)
- [The decision log](https://connectbyjbrh.com/docs/autonomy/audit-trail/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Making a correction actually change behaviour](https://connectbyjbrh.com/research/memory-correction-that-sticks/)

## What this page is based on

- Connect source pack §5 — approvals and the audit trail (`docs-source/sources/GENERAL.md`)
- Connect source pack §6 — memory tiers and correcting what Connect knows
- Connect capability registry (`docs-source/facts.py`) — `held_draft_approval`, `memory_editing`, `mailbox_roles`
- `backend/app/outbound.py`, `backend/app/connect_memory.py`