Enterprise Mind
The full service that gives your organisation memory, judgement and governed autonomy.
Overview
Enterprise Mind is the complete service we provide so that your organisation remembers what it decided and why, learns from results and automates step by step, under your control. It is not a single screen or engine. It is the set of parts that work together: The Brain, Memory, the Decision Ledger, Recall, Outcome Learning, Autonomy & Approvals, and Governance, Privacy & Voice.
When you switch it on for a module, we set the parts up around the records, roles and AI engine you already use. It follows your rules, your experiences and your expectations, and it works with whichever LLM you choose to work with.
The parts of Enterprise Mind
| Part | What it does for you | Read more |
|---|---|---|
| The Brain | The thinking part. Compares options, suggests with evidence, checks limits and learns from results. | The Brain |
| Memory | Keeps decisions, conversations, calls, documents and outcomes, each with its source. | Memory |
| Decision Ledger | Records every approval, override and outcome: who decided, under which role, and why. | Decision Ledger |
| Recall | Brings similar past cases and their results back when a record opens. | Recall |
| Outcome Learning | Compares what was expected with what happened and proposes rules for an administrator. | Outcome Learning |
| Autonomy & Approvals | The ladder from observe to limited auto-run, and the approval queue that guards it. | Autonomy & Approvals |
| Governance, Privacy & Voice | Data classes, masking, retention, audit trail and the rules for voice calls. | Governance, Privacy & Voice |
What we set up with you
- Where to start. Choose the modules that begin with Enterprise Mind. Each one starts at observe and suggest.
- Connections. Link it to your records, roles and the AI engine you chose.
- Rules. Agree data classes, retention and who may approve what.
- Limits. Set the starting autonomy level for each action class, and the limits it may never cross.
- Review. Look at the first results with your administrators and widen the scope one step at a time.
Technical readers can find the architecture behind The Brain in Brain Engine.
In one minute
- It listens to decisions, not people. Approvals, overrides, outcomes and call summaries are recorded; clicks and screen time are not.
- It remembers with sources. Every answer points back to the record, message or document it came from.
- It suggests with evidence. A suggestion shows its confidence, the cases behind it and the options it ranked lower.
- It acts only where allowed. Actions come from a fixed catalog and run at the level an administrator granted.
- It learns from results. What actually happened feeds the next suggestion, and proposed rules wait for an administrator.
What changes day to day
| Situation | Without Enterprise Mind | With Enterprise Mind |
|---|---|---|
| A new colleague meets a rare case | Asks around, or guesses | Sees the last similar cases with their reasons and results |
| An approver is asked to sign off | Opens three screens to understand the request | Reads one card with evidence, confidence and the policy check |
| A manager asks "why did we do that?" | Nobody remembers | Opens the ledger entry with the reason and who decided |
| An auditor traces a result | Reconstructs it from emails | Follows the trace from outcome back to evidence |
A day with Enterprise Mind
| Time | Who | What happens |
|---|---|---|
| 08:02 | Voice agent | Answers a booking call, remembers the guest's quiet-room preference from last spring and writes it back. |
| 09:12 | Supervisor | Opens room 214, sees a recall card, approves one extra cleaner and writes a one-line reason. |
| 11:30 | Fleet planner | Overrides a service interval because of a mountain route. The override and reason go into the ledger. |
| 14:05 | Enterprise Mind | Closes a renewal outcome and compares it with its earlier prediction. |
| 17:40 | Administrator | Reviews a proposed rule built from three weeks of cases and approves it for one module. |
Principles it follows
| Principle | In practice |
|---|---|
| Every answer has a source | No source, no result. |
| Reading is not acting | Being allowed to recall something never allows running an action. |
| Limits beat confidence | A confident suggestion still stops at a limit. |
| Unknown is not failed | An action with no reply is shown as unknown and checked, never guessed. |
| Nothing promotes itself | Rules, methods and autonomy levels all wait for an administrator. |
What it is, and what it is not
Most companies lose the reasoning behind a decision within days. The person who decided moves on, the chat thread scrolls away, and the next person starts from scratch. Enterprise Mind keeps that reasoning attached to the record it belongs to, and puts it back in front of the next person at the moment it matters.
| It is | It is not |
|---|---|
| A long-term memory for decisions, calls and outcomes, with the source attached | A chatbot that answers from general knowledge |
| A way to compare options and show the evidence behind a suggestion | A black box that tells you what to do |
| A ladder from observe to limited auto-run, controlled by administrators | An on/off switch for "autonomous mode" |
| Built into TotalApp and bound by your roles and tenant isolation | A separate service with its own users and data |
"Mind" is a metaphor
The name describes an architecture: memory, judgement and action working together. It does not claim awareness. Every suggestion can be traced to records, and every action needs an approval or a limit you set.
What it remembers
Memory is built from the work your team already does. Each source keeps its original wording, its versions and the people involved, so an answer can always be traced back.
| Source | Examples | What is kept |
|---|---|---|
| Decisions | Approvals, rejections, edits, overrides | Who, role, reason, evidence shown, time |
| Conversations | Messages and notes on a record | Original text, every edited version, exact quotations |
| Calls and meetings | Voice agent calls, logged meetings | Summary, language, preferences, follow-ups |
| Documents | Policies, contracts, procedures | The document version that applied at the time |
| Records | Tasks, orders, bookings, cases | State changes with when they happened and when they were recorded |
| Confirmed outcomes | Won or lost, on time or late, passed or failed | The result, linked to the decision that led to it |
What a memory entry always carries
- The original source, never only a paraphrase.
- Versions. If a message or document is edited, the earlier version stays available.
- Who was involved and what was known to them at the time.
- Access rules. The same role and data-class rules that protect the original record protect its memory.
- A retention period after which the entry is archived or removed.
Building blocks
Behind the parts above, Enterprise Mind is built from six building blocks. Each is explained in more detail on the other pages of this group.
| Part | Job | Detail page |
|---|---|---|
| Memory | Stores decisions, conversations, calls and outcomes with their sources. | Memory |
| Option comparison | Scores allowed options on your own history. | Autonomy & Approvals |
| Prediction | Estimates risk and likelihood with a range. | Outcomes |
| Policy gate | Checks limits, data classes and approver roles before anything is shown or run. | Autonomy ladder |
| Action catalog | The only list of actions that can ever run. | Action catalog |
| Audit and privacy | Records every recall, suggestion and approval; applies masking and retention. | Governance |
Screens
Enterprise Mind adds a small set of screens to each module that has it switched on. Settings and autonomy controls sit in the Administration & Access group and are visible to administrators only; everything else is open to staff who already hold a role in that module.
| Screen | What it is for | Who sees it |
|---|---|---|
| Overview | Events recorded, suggestion acceptance, open approvals and the current autonomy level. | Module staff |
| Decision Ledger | Browse and filter every recorded decision. Details | Module staff |
| Recall | Ask what happened in a similar case. Details | Module staff |
| Suggestions and Approvals | Review, approve, edit or reject. Details | Approver roles |
| Autonomy | Set the level per action class and use the kill switch. Details | Administrators |
| Outcomes | Predicted versus actual and proposed rules. Details | Administrators and approvers |
| Settings | Data classes, retention, masking and audit. Details | Administrators |
Getting started
- Open Settings and switch Enterprise Mind on for one module. Start with the module where decisions repeat most.
- Review the data classes. Public and internal collections are shared by default; sensitive collections stay out until you allow them.
- Leave every action class at Observe for the first two weeks. The ledger fills up and Recall starts to work.
- Move chosen classes to Suggest. Approvers see suggestions with their evidence in the approval queue.
- When the acceptance rate holds, promote a class to Approve and later to limited auto-run, always inside limits you set.
Tip
You never have to move past Observe or Suggest. Recall and the ledger are useful on their own.
Roles and permissions
Enterprise Mind adds no separate user list. Access follows the roles you already assigned in each module, extended by four capabilities.
| Capability | What it allows | Default holders |
|---|---|---|
| Read | Open the ledger, Recall and suggestions for the module. | All module staff |
| Propose | Create a suggestion from a record or a call. | Operators and approvers |
| Execute | Approve a suggestion so the action runs. | Approver roles (for example Plant Manager, Senior Partner) |
| Administer | Change autonomy levels, data classes, retention and the kill switch. | Module administrators |
Related pages: Access model
Module coverage
Each module starts at Observe and Suggest and you decide how far it climbs. The table shows the highest level offered per module.
| Module | Recall | Suggest | Approve and act | Auto within limits |
|---|---|---|---|---|
| Hospitality | Available | Available | Available | Available |
| FleetOps | Available | Available | Limited | Not offered |
| RevOps / CRM | Available | Available | Available | Limited |
| FinAudit | Available | Available | Limited | Not offered |
| Customs | Available | Available | Limited | Not offered |
| Patent & R&D | Available | Available | Not offered | Not offered |
| Insurance | Available | Available | Limited | Not offered |
| Healthcare | Available | Available | Not offered | Not offered |
| Manufacturing | Available | Available | Limited | Not offered |
| Project Management | Available | Available | Available | Limited |
| Maintenance | Available | Available | Available | Limited |
| Call Center | Available | Available | Available | Limited |
Always a person
In Healthcare, Patent and R&D the approve and auto levels are not offered. A person decides every action there.
Rolling it out
Start small and let the numbers decide how far to go. A typical rollout for one module takes four phases.
| Phase | Typical length | What you do | Exit signal |
|---|---|---|---|
| 1. Observe | 2 weeks | Switch on one module, review data classes, leave every class at Observe. | The ledger shows realistic volume; masking looks right. |
| 2. Suggest | 4 weeks | Move chosen classes to Suggest. Approvers use the queue and write reasons when they reject. | Acceptance holds steady and rejections have clear reasons. |
| 3. Approve | 4 to 8 weeks | Promote proven classes to one-click approval. Define the action catalog. | No wrong action ran; unknown results are rare. |
| 4. Limited auto | Ongoing | Allow low-risk, reversible classes to run inside limits. Review weekly. | The weekly review finds nothing to demote. |
Run a bounded pilot first
Pick one module, one team and one or two action classes. A pilot of six to eight weeks is enough to see whether acceptance and time saved justify going further.
What it does not do
- It does not act outside the approved action catalog, ever.
- It does not exceed a spending limit, touch sensitive data or run an action that cannot be reversed without a person.
- It does not track clicks, screen time or individual productivity. It records business decisions.
- It does not activate learned rules on its own. An administrator approves every rule.
Who uses what
| Person | Typical use | Most useful screens |
|---|---|---|
| Operator or agent | Opens a record, glances at similar past cases, follows or ignores the suggestion. | Recall, Suggestions |
| Approver or manager | Works through the approval queue and writes a reason when rejecting. | Approvals, Overview |
| Administrator | Chooses data classes, sets autonomy levels, reviews proposed rules and the audit trail. | Autonomy, Outcomes, Settings |
| Auditor | Traces a past decision from outcome back to evidence. | Decision Ledger, audit trail |
Glossary
| Term | Meaning |
|---|---|
| Action class | A named kind of action, for example "Assign housekeeping task". Autonomy is set per class. |
| Action catalog | The list of actions an administrator allows for a module. Nothing outside it can run. |
| Acceptance | Share of suggestions approved without changes. |
| As-of date | A date you pick in Recall to see what the system knew on that day. |
| Confidence | How sure the engine is about a suggestion, from 0 to 100. |
| Data class | Public, internal or sensitive. Decides what is shared and shown. |
| Demotion | An automatic drop of one autonomy level when quality falls. |
| Escalation | Sending a low-confidence suggestion to a more senior approver role. |
| Kill switch | One control that returns a module or the tenant to Observe. |
| Trace | A reference attached to each suggestion for later questions and audits. |