Memory keeps what your organisation decided, said and learned, with the original source, every version and the people involved. It shows conflicts instead of hiding them, and forgets on a schedule you set.
Memory stays inside your tenant. Nothing is kept that you did not switch on.
| Entry | Source | Version | Class | Keeps until |
|---|---|---|---|---|
| Room 214 cleaning | Task T-102 | v2 | Public | Sep 2028 |
| Housekeeping policy | Document | v3 | Internal | Sep 2027 |
| Booking call | Voice | v1 | Public | 90 days |
| Supervisor note | Message | v4 | Internal | Sep 2027 |
Every number comes from the same place: the work your team already does inside TotalApp.
Illustrative figures from a sample workspace.
Notes get edited, chats scroll away and people leave. Memory keeps the evidence, not just the summary.
Open the record, message, document or call that an answer came from.
An edited note keeps its earlier versions and when each applied.
A result can show the exact sentence it relied on.
Each entry notes who was involved, so you see what a person could have known.
When sources disagree both are shown, never averaged away.
Retention periods archive or remove entries nobody needs any more.
Fewer delivery delays. Better clinic utilization. Lower document-processing cost. Higher-quality planning. The business goal sets the criteria for the architecture.
A guest asks for a garden-side room in a chat message, changes the dates on a call, and gets a revised booking. Months later, the same guest writes again and a different colleague answers.
Pick up the relationship with its history intact. Find the promise, the reason for the change, and the experience that matters for the next stay.
Keep the original wording, its date and who was part of the conversation.
The earlier version stays available, so the change is visible rather than overwritten.
Who approved, under which role, and the reason they wrote down.
The result is tied back to the decision that led to it, so the next case starts from it.
The person who managed a fleet service plan moves to another team. Their replacement inherits a vehicle record, a folder of documents and decisions scattered across messages.
Give the next colleague the reasoning behind the plan. Spend the handover on the next decision, with the earlier constraints and lessons at hand.
Start with the requirement and the source that set it.
Constraints are kept with the document version that applied at the time.
Rejected alternatives are recorded with the reasons they were rejected.
What happened is attached to the plan, so it is found when someone plans again.
An approval is questioned a year later. The policy has changed twice since, and the person who approved it has left.
Replay any past day as it looked then: the policy version in force, the information that was recorded by that time, and the roles that could access it.
Filter by person, action class and date to reach the entry.
The as-of date shows version 2, not the newer version 4.
The same role rules that protected the record protect its memory.
Administrators export the trail as a spreadsheet file for the review.
A delivery was completed after the team changed its plan. The final status says done; the manager needs to understand the choices and the actual result.
Follow the path from a business event to a decision and a result backed by evidence. Review what worked, what is uncertain and what deserves another look.
Keep the event that made the team revisit its plan.
Both options, their cost and risk, and who approved.
Predicted and actual are shown side by side.
A pattern becomes a rule only when an administrator approves it.
Every entry points to the record, message, document or call it came from and keeps every version of it.
Each entry keeps when it happened and when it was recorded, so the past can be replayed as it looked then.
Real organisations hold conflicting information. Memory shows both sides and lets a person settle it.
An entry belongs to one tenant, one module and, where it matters, one role or record.
Retention periods per data class archive or remove entries nobody needs any more, and requests to erase a person are handled and logged.
Each layer only adds to the one below it, so an answer can always be traced back to a source.
The original text, document or call is never replaced.
Edits create a new version; the old one stays.
One entry per decision, call or outcome, with reason and time.
Entries are tied to the task, order, booking or case.
Search and as-of views sit on top of the layers below.
Roles, data classes and retention apply to every layer.
Memory remembers your business. It follows your rules, understands your experiences and keeps an audit trail.
Yes. It is a core engine inside TotalApp, but it is also sold as a stand-alone service.
Only business decisions, calls, documents and outcomes from modules you switched on, for the retention period you set.
Collections are classed public, internal or sensitive. Sensitive data is off by default and personal information is masked before it reaches any model.
Yes. An administrator removes the entries linked to the person and the deletion is logged without personal details.
Yes. It uses the AI engine selected in Settings, cloud or local; memory behaves the same either way.
Start in observe mode today and see what your organisation already knows.