Editing a memory
You can change the text of a memory and the tags it carries, from the viewer or the memory sheet in the grid. The change governs the next piece of work and nothing already done: replies already sent stay as they were, and the decision log still shows what was decided under the rule that applied at the time. Edit when the wording was wrong; supersede when the truth changed.
What an edit reaches#
- The text
- The claim itself. This is what a reply is written against, and what a live call spends its budget on.
- The tags
- Including
block:<channel>. Editing the tag list is how a block is widened, narrowed or lifted, because directives are read from tags and nowhere else. - The tier
- Moving a line to a different scope is the fix for a rule that applies too broadly or too narrowly. In practice it is written where it belongs and forgotten where it was.
What an edit does not reach is anything that already happened. A message that went out yesterday was written against yesterday's memory and stays exactly as sent; the audit trail keeps what was decided, by what, and under which rule. That is deliberate — a record you can retroactively rewrite is not a record, and "why did it say that" has to remain answerable after the line has been corrected.
Edit, supersede, or forget#
| Situation | Do this | Because |
|---|---|---|
| The line says what you meant, badly | Edit | There is one truth here and only the wording was at fault |
| The line was simply mistaken | Edit | Nothing about the mistake is worth preserving as history |
| It was true and is no longer | Supersede | A reply sent under the old truth needs the old truth to stay readable |
| It should never have been recorded | Forget | There is no version of it you want future work to read |
| It is right but applies too widely | Rewrite it at a narrower tier | The wording is not the problem; the scope is |
The distinction between editing and superseding is not bureaucratic. A business that corrects a stale delivery time by editing it in place loses the ability to explain a quotation it sent last month. A business that supersedes every typo accumulates a history nobody can read. The question to ask is whether anyone will ever need to know what the row said before.
Editing a directive#
Guidance and blocks are ordinary memory rows with special tags, so they are edited the same way — with one difference worth stating in full. A block lives in the tag list as block:<channel>, never in the body, because directives() reads only the tags. Rewriting the body of a block to say "this no longer applies" changes nothing at all: the tag is still there and the block still holds.
After the change#
Save, and re-read the row in the viewer as it now stands.
Result What you see is what the next piece of work will read. There is no separate published version and no propagation delay.
Trigger the behaviour again — send the next reply, or place the next call.
Result A call already in progress will not pick it up: the brief is rendered once per call, so the change lands on the following one.
If the behaviour has not changed, check the tier and then check for a narrower row saying the opposite.
Result A contact-tier line beats the channel-tier one you just corrected, and nothing announces that. Connect ignored what I told it goes through the four causes in order.
Questions#
Does editing a memory change replies that were already sent?
No, and it could not: a sent message has left through the send boundary and been acknowledged by a provider. The memory governs what is written next. The trail of what was decided under which rule stays intact, which is what makes an old reply explainable after the rule has changed.
Can two people edit the same memory?
Anyone in the workspace with access to the record can change it, from the viewer or the grid, and the last save is what future work reads. For anything contentious — a block, or a standing instruction about an account — say so in the row itself, so the next person sees the reasoning rather than guessing at it.
I edited a block's wording and it is still blocking. Why?
Because the block is the tag, not the sentence. directives() reads only the tag list, which is exactly what makes a block hold across channels and future conversations. Remove or change the block:<channel> tag to change the behaviour.