Brain Engine
The technical architecture behind The Brain: memory, processes, data, models and infrastructure in one loop of understanding, acting and improving.
Overview
Brain Engine is the integrated digital mind of a business. It joins memory, processes, data, models and infrastructure into one continuous loop of understanding, acting and improving, inside the permissions, limits and budgets you set.
You describe your organisation, choose your sector, connect your systems and add your documents. Brain Engine builds an application around how your business really works, then takes part in daily operations: it takes in changes, keeps the current picture of the business, uses accumulated experience, makes forecasts, proposes solutions and carries out the actions you allow.
Status
Brain Engine is in development. This page describes the target product so teams and partners can plan around it. It is not a status report, and individual modules may arrive at different times.
The Brain and Brain Engine
The Brain is what your organisation uses day to day as part of Enterprise Mind. This page is the technical view: the architecture, modules and concepts behind it.
In one minute
- It follows the business. A demand spike, a late delivery or a customer request updates its picture and can start a calculation or an allowed action.
- It remembers with sources. Events, decisions and results stay linked, with freshness and access rules.
- It acts only inside limits. Policy, approvals and autonomy levels decide what may run.
- It checks itself. Results are compared with expectations and used to improve models and processes in a controlled way.
- It does not depend on constant LLM calls. Daily operations run on models, statistics, rules, procedures and solvers.
Operational Brain
Answers “What should be done in this situation?” day to day.
MetaModel
Answers “How should the system be built to solve this kind of task better?”
Governance
Rights, approvals, audit trail, rollback and recovery are part of the design.
The loop
Every piece of work goes through the same nine steps, so each outcome makes the next decision better.
| Step | What happens | Example |
|---|---|---|
| Observe | Changes and events are taken in. | Orders jump 30% on a Monday morning. |
| Understand | A current picture of entities, queues and resources is kept. Missing, stale or conflicting data is marked. | Which rooms are ready, which wait for cleaning, which have no recent check. |
| Remember | Events, decisions and results are linked, with sources, freshness and access rules. | How a similar fault at the same site was solved last spring. |
| Predict | Specialised models and the World Model forecast how the situation may develop, with uncertainty. | The warehouse will be overloaded on Thursday. |
| Choose | Permitted options are compared on cost, risk and benefit, and the choice is explained. | Move two tasks and rebalance staff. |
| Check permissions | Policy and autonomy rules return allowed, refused or needs approval. | Spend above the limit goes to a manager. |
| Act | Approved actions run from the action catalog with durable execution. | A maintenance task is created and linked to the guest request. |
| Observe the result | Actual results are compared with the expectation and stored with their evidence. | The forecast said Thursday, the real peak was Friday. |
| Learn | Repeated misses lead to a controlled review of a model or the solution architecture. | The demand model is retrained and shadow-tested. |
Confidence is not authority
A confident forecast or suggestion still cannot exceed a limit, touch protected data or run an action that needs approval.
Two levels of intelligence
The two levels work on different time scales. The operational level accompanies current events and tasks. The architectural level looks at accumulated problems and ways to improve, while business processes keep running on the approved version.
| Operational intelligence | Architectural intelligence (MetaModel) | |
|---|---|---|
| Question | What should be done in this situation? | How should the system be built to solve this kind of task better? |
| Works on | Current events and tasks | How tasks are solved: which components, in which order |
| Output | A decision, an action, a result check | A versioned architecture proposal with evidence |
| Who approves | Policy and, where required, a person | A responsible person, in a separate acceptance process |
Building your environment
Brain Engine settings live in your own environment. Staff see their tools, managers see their unit, system administrators see the permitted system settings.
| # | Step | What you do |
|---|---|---|
| 1 | Choose your sector | Pick one or several areas of activity. A clinic can combine intake, laboratory and diagnostics. |
| 2 | Describe the organisation | Units, sites, staff, customers, volume and business model. |
| 3 | Add connections | Your cloud, servers, databases, APIs and supported MCP services, with the access you allow. |
| 4 | Upload documents and clarify in dialogue | Brain Engine combines them with known context and sector knowledge. |
| 5 | Review the future application | Roles, processes, data, planned actions and important contradictions. |
| 6 | Pick the design | Layouts suited to the work: calendars, queues, maps, documents, analysis panels. |
| 7 | Set brand and governance | Name, visual system, access, approvals, allowed autonomy and budget. |
| 8 | Review the application and resource plan | What will be built, which integrations are needed, expected cost. |
| 9 | Receive your domain | Approved resources are prepared and checked, then your application opens. |
After launch you can ask for changes in plain language, for example “Add a second branch” or “Change the repair approval process”. Brain Engine finds the affected data, processes, screens and resources, prepares a new version and shows the changes before applying them.
What you get
Your own application
An address and a space reserved for your organisation.
Workspaces
For staff, managers and, when needed, customers or partners.
One consistent model
Data, documents, processes and access rights that fit together.
Connections
To the external systems and sources you allow.
Applied AI functions
Matched to the tasks of each role.
Infrastructure control
Service status, compute resources and budget.
History
Changes, results, decisions and approvals.
Change by conversation
Clarify requirements and evolve the application in dialogue.
Modules
A module is a functional subsystem, not necessarily a separate server or software package. Each has its own responsibility, settings, output and links to the others.
| Module | Responsibility |
|---|---|
| Domain Brain and Studio | Turns requirements into your application and its Domain Package: roles, processes, data, interface, integrations and resources. |
| Knowledge and semantic layer | Concepts, relations and requirements, each linked to its source. Flags contradictions. |
| Data Platform | Ingests, checks and prepares data, with lineage and pinned source versions. |
| Storage | Snapshots, backups, clones, retention and recovery points. |
| Memory | Sourced, versioned, time-aware context, decisions, results and experience. |
| ML Runtime / Model Fabric | Trains, versions, runs and monitors specialised models. |
| LLM and Cognitive Routing | Chooses the right tool: memory, a known procedure, a model, a solver or an approved language model. |
| Enterprise State | The observed state of the business, plus compact representations for computation. |
| World Model | Forecasts, scenarios and uncertainty. |
| Decision and Optimization | Chooses among permitted actions, solves allocation and scheduling, explains why. |
| Verification, Policy and Autonomy | Rights, approvals, limits and autonomy levels. |
| Actions and Operations | Turns permitted decisions into work items, assignments and executed actions. |
| Durability | Records progress, resumes after failures, recognises repeated requests, verifies uncertain results. |
| Fabric | Shared context, events and audit trail between all modules. |
| Control Plane | Desired versus real state of the whole environment, health and cost. |
| Infrastructure and Compute | Prepares and runs CPU, GPU, network and database resources in an approved cloud or on your servers. |
| Integration Studio | Connects databases, APIs, file systems, clouds and MCP services, separating read rights from action rights. |
| Outcome Learning and Homeostasis | Checks whether actions helped and keeps the system healthy as conditions change. |
| Brain MetaModel | Designs and verifies the architecture that solves a class of tasks. |
Brain MetaModel
The MetaModel acts as the engineer that designs how a class of tasks is solved. Organisations differ: a clinic may care most about waiting time, a warehouse about placement, a school about timetables. The MetaModel searches the approved component catalog for the combination that fits, then checks it before anything is used.
How a search proceeds
| Stage | What happens |
|---|---|
| Define the task | Goal, constraints, permitted data, the current architecture and the search budget are fixed. |
| Propose candidates | A few combinations of permitted components, or changes to the current setup, are generated. |
| Check structure | Components, inputs and outputs, parameters and versions are verified. |
| Compile | A runnable configuration is prepared. It is not yet proven to be good. |
| Evaluate | Candidates and the current solution run on comparable scenarios. Quality, delay, cost and constraints are measured. |
| Shadow run | The best candidate receives real permitted inputs in parallel with the current one, with no outside actions. |
| Approve | A responsible person reviews evidence, risks and the rollback plan. Rollout is gradual. |
| Monitor | Real results are compared with expectations. If limits are breached the system stops or returns to the previous version. |
Example: scheduling a large clinic
The clinic wants shorter waits while respecting doctor hours, room availability and equipment. The MetaModel could compare three options.
| Option | Composition | What is checked |
|---|---|---|
| A. Rules and optimisation | Fixed appointment lengths, resource calendar, rules, allocation algorithm. | Whether the simple setup is enough for normal load. |
| B. Prediction and optimisation | Appointment-length model plus the same calendar and algorithm. | Whether prediction improves the schedule on independent data once its cost is counted. |
| C. Prediction, context and scenarios | Prediction, permitted history of past delays, a World Model and optimisation. | Whether the extra context helps in heavy load and failures. |
This is an illustration of a possible comparison, not the result of a finished experiment. A more complex option is not preferred just because it has more parts: if the simple one meets the needs better on quality and cost together, the MetaModel recommends it.
The MetaModel never deploys on its own
Its output is a verified proposal with evidence. Authority and rollout stay with the responsible person and Brain Engine's own controls. Training, selection and final test data are kept apart, so fitting known examples is never taken as proof of quality.
Technical concepts
Short definitions of the terms used across Brain Engine. They are the vocabulary of the target architecture.
| Term | Meaning |
|---|---|
| Domain Package | The package that defines a customer application: composition, versions, data, processes, interface, integrations and resources. The Control Plane reads it to know what should exist. |
| Enterprise State | The observed state of the business, keeping both event time and ingestion time. Missing, stale and conflicting observations are flagged. |
| Latent State | A learned compact representation of that state for computation. Compressing data is not the same as forecasting. |
| Enterprise Epoch | A pinned set of source versions used in a calculation or training run, so it can be repeated. Missing sources are stated openly. |
| Action catalog | Actions with input schemas, conditions and access requirements. Only catalog actions can run. |
| Cognitive routing | Chooses the tool in order: memory and knowledge, a known procedure, an ML model, a solver, approved research sources, and only then an approved language model. A generated text never authorises an action by itself. |
| Durable execution | Records the start, steps and results of a job, resumes from an allowed point, recognises repeated requests, keeps execution ownership and checks an unknown outcome with the executor before any repeat. |
| MMIR | MetaModel Intermediate Representation: a machine-readable definition of an architecture (goal, components, links, parameters, versions, origin). A validator checks it and a compiler turns it into a runtime configuration. A successful compile means it can run, not that it is good. |
| Evaluation package | Tied to one exact configuration: which data and scenarios, compared with what, which measurements and which limitations. |
| Shadow evaluation | A candidate receives permitted real inputs in parallel with the current setup and performs no outside actions. |
| Data separation | Training, candidate selection and final independent test data are kept apart, so fitting known examples is never taken as proof of quality. |
Governance and limits
| Principle | In practice |
|---|---|
| Permissions first | Every read, transformation and action is checked against rights and policy. |
| People in the loop | Approval chains, limits and expiry for anything that matters. |
| Full audit trail | From source to computation, decision, action and result. |
| Tested before use | New models and architectures are evaluated and shadow-run first. |
| Recoverable | Backups, durable execution and rollback to a previous version. |
| Honest limits | When evidence is missing the system hands over to a person or keeps the current state. |
Outputs include sourced answers, decision records, forecasts with uncertainty, experiment reports, comparisons against the current solution, lists of known limitations and the approval history behind each change.