Record the decisions behind each change
A new file or message may contain a proposal rather than a decision. Before updating the current record, check what was accepted and by whom. Retain the earlier version when it explains the change or may be needed to understand a commitment.
Use a short change note: "The customer approved the revised installation date on June 8; the current date is June 19." Point to the confirmation and identify any related record that also needs a human update.
- Identify the matter and its current confirmed state.
- Record the proposed change and its source.
- Confirm the decision, date, and person responsible.
- Update the current record and preserve the relevant history.
An example: a customer changes the finish
A fictional cabinet shop has an approved order for a natural finish. The customer later asks about a darker finish, and the shop sends a revised price. At that point, the darker finish is a request and the price is a proposal.
Only after the customer confirms the revised version should the shop mark the new finish as agreed. Keep the original order, the change request, and the confirmation identifiable. If the response is ambiguous, resolve it before ordering materials.
Make the current state easy to find
Give the matter a recognizable name and keep the current agreement close to the work it governs. A short index can show the current version and point to the original messages; it should not replace them when their wording matters.
Decide who can update the record and how the people involved will hear about a material change. If two records conflict, mark the conflict and assign someone to resolve it rather than letting the newest file silently overwrite the earlier agreement.
Where Areinum fits
Areinum uses a company data layer and a persistent graph to help find related records. In the demo, graph searches use metadata and selected record text can be read when needed.
That architecture is intended to help an assistant work with company context. For a particular task, check which sources, attachments, and historical versions are available and how long they are retained.
Questions you may have
Should I delete an old version after a change?
Keep the history that explains the agreement or is required for your work, following your own retention needs. Make the current version easy to identify so an older document is not used by mistake.
Is the newest message always the current agreement?
No. It may contain a question or proposal. Look for confirmation that identifies the terms and the person authorized to agree them.
What if two people recorded different versions?
Preserve both sources, identify the conflict, and ask the responsible person to confirm the current state. Record the resolution and communicate any change to the people who depend on it.
Does a graph guarantee a complete company history?
No. The graph can only reflect the data and history available to it. Check access, source coverage, and retention for the records you intend to rely on.
The demo uses sample business data and is in English. Access may need to be arranged.
Explore the demo