A companion update needs a change log that names the relationship cost

When a calculator changes, users want correctness. When a companion changes, they may also lose a familiar voice, style, memory pattern or boundary. “Performance improvements and bug fixes” is therefore inadequate release communication. A useful change log treats continuity as a product property without pretending the system is a person.

Name the changed layer

Use stable headings: base model, system instructions, character definition, memory and retrieval, moderation, voice, avatar, interface, pricing and data practice. State whether the change affects new sessions, existing characters or both. Google’s model-card work recommends documenting intended uses, performance conditions and relevant limitations; a product release note can apply that transparency at a smaller operational scale.

Describe impact, not internals alone

“Upgraded retrieval” tells a user little. Better: “Older saved facts may be selected differently; saved items were not deleted; users can review them at this path.” For moderation changes, name the policy area and appeal route. For voice changes, state whether the actor, synthesis model or only audio quality changed. Do not promise unchanged personality unless regression evidence supports it.

Give users a transition path

Announce material changes before they arrive where feasible. Offer export, memory review, a preview or opt-out window, and a way to report regressions. NIST’s Generative AI Profile recommends structured governance, measurement and documentation across the lifecycle. It is voluntary guidance, but its map-measure-manage logic fits a release process: identify affected users, test defined risks, deploy controls and watch outcomes.

Use a minimum release record

• Version and effective date.
• Layers changed and reason.
• Expected user-visible effects.
• Tests run, sample scope and known limits.
• Rollback trigger and owner.
• Data, billing or policy implications.
• Feedback and appeal routes.

For a hypothetical memory update, include a small before-and-after correction test, disclose that it cannot establish every conversation outcome, and preserve the prior version long enough to investigate severe regressions.

Keep history available

Do not silently rewrite yesterday’s note. Append corrections and link superseded versions. A dated archive lets creators correlate user reports with actual releases and lets users decide whether a change explains a sudden shift.

Show the decision consequence

Imagine a voice update improves expressiveness but removes the slower speaking-rate option used by some customers. The release note should not bury that loss under audio quality. The team can delay release, preserve the old voice as an accessibility option, or ship only to users who opt in. Naming the trade lets support recognize reports and lets users choose. A change log becomes governance when an observed loss can still alter the rollout.

A good log does not eliminate disappointment; it makes change contestable. Pair it with the memory correction protocol for a reproducible check and the rollback drill for the decision behind release.