No data migration· Four ways in· Your data stays on your side of the boundary
ARCHITECTUREno migration
Omnira does not replace your stack. It sits between it and the decision.
Your systems stay where they are. Omnira connects to them, builds a single context out of them and hands the result back - as a recommendation, an alert or a process that has already run. Below is the diagram of that installation, layer by layer.
INSTALLATION DIAGRAM
Five layers, one loop.
From the systems you already have, through a shared core, to action returning to those same systems. Click a layer to see what sits in it.
01
SOURCES
What the business has today. It stays put - Omnira reads from these systems instead of replacing them.
7 items
01SOURCES
- CRMClients, opportunities, contact history. We read the state; we do not take over the sales process.
- ERPOrders, stock, billing. This is where the number comes from that has to add up across the whole business.
- HRPeople, rotas, absences. Without this, forecasting cover is guesswork.
- ProjectsTasks, deadlines, team load - from Jira, Asana, ClickUp or a spreadsheet.
- DatabasesOperational data that only IT reaches today, with an SQL query.
- DocumentsContracts, quotes, minutes. They go into the company’s memory, not just onto a drive.
- CommunicationEmail and chat. Half the decisions that exist in no system at all are made there.
02
CONNECTIONS
Four ways into the same data. Which one we take is a rollout decision, not a technical whim - it is set out below.
4 items
02CONNECTIONS
- APIlogThe system’s official API. The shortest route, provided the system has one and has documented it.
- MCPlogModel Context Protocol: the standard an assistant uses to reach tools and data without a separate connector being written.
- WEBHOOKSlogThe system reports an event itself when something happens. Instead of polling every minute, we wait for the signal.
- CONNECTORSrolloutA dedicated connection to a system with no API. Written for the specific rollout.
03
OMNIRA CORE
One place where data from different systems becomes a single version of the number. Shared by every module - there are not six separate cores.
5 items
03OMNIRA CORE
- Shared contextOne version of the number instead of five. The same client, the same job and the same margin in every module.
- Business logicYour company’s rules: what counts as a risk, what needs approval, what may run automatically.
- MemoryWhat has already happened, what we did about it and how it ended. Without memory, every recommendation starts from zero.
- ModelsForecasts and classifications. The model runs on context, not on a raw export - which is why its output can be explained.
- PermissionsWho sees what and who may run what. The permission is checked at the data, not at the screen.
04
PRODUCTS
Six modules on one core. It starts with a single process, not the whole business - each further module adds to the same context.
6 items
04PRODUCTS
- PredictForecasts, risks, recommendations
- DeskCover and operational status
- LeadSourcing and qualification
- OfferQuoting and proposals
- FlowAutomation between systems
- VoiceVoice assistant
05
ACTIONS
The way out of the system. Every action leaves a trace in the log: who, when, at whose request and with what result.
5 items
05ACTIONS
- RECOMMENDATIONSA suggestion with its reasoning and the data behind it. The decision stays with a person.
- AUTOMATIONSA process run without asking - where the rule is unambiguous and written down.
- ALERTSA signal that something is off before it shows up in the month’s result.
- APPROVALSA gate for actions that need a signature. Who approved it stays in the log.
- WRITE-BACKThe result goes back to the system the data came from. Without that you get another island of data.
Pick a layer to see what sits in it and what comes out of it.
WAYS IN
Four ways into your data.
On the diagram they are drawn as valves, because each of them settles something: what we let in, how often, and what it costs us. We decide the route during the rollout, system by system.
01
API
logThe system’s official API. The fastest way in and the fewest surprises: the contract is documented and the vendor announces changes. This is how we go in wherever we can.
Needed on your sideAn account with read permission and an API key.
02
MCP
logModel Context Protocol - the standard an assistant uses to reach tools and data without a separate connector being written for each of them. It means a new source connects in days rather than weeks.
Needed on your sideAn MCP server on the system side, or one we stand up during the rollout.
03
Webhooks
logThe system reports an event at the moment it happens. Instead of polling every minute and still being a minute late, we wait for the signal. This is the route for the things that have to be immediate.
Needed on your sideThe ability to set a receiving address, and a secret to sign the calls with.
04
Custom connectors
rolloutFor systems with no API: an older ERP, an internal database, an export from the accounting package. We write the connection for that specific rollout and maintain it along with the rest of the installation.
Needed on your sideAccess to the database or to an export folder, and someone on your side who knows the format.
None of these routes needs a migration or a change of tools. We start with one system and one process - the rest adds to the same context.
DATA AND SECURITY
The boundary on the diagram is not decoration.
What is drawn as the system boundary is, in code, a set of rules that are hard to get around by accident. Six of them are below - the ones that can be checked, not the ones that look good on a slide.
01
Client data separated in the database
Isolation rests on rules in the database itself, not on a condition in application code. A query without an organisation context does not return an empty list - it has no right to run correctly at all.
02
The application has no master key
Credentials that bypass isolation do not exist in the application process or in the background job process. Even a successful attack on the application gives no access to another organisation’s data.
03
Personal data never reaches the shared layer
Company registry data is shared; personal data is not. This is enforced by the type of the writing function and a constraint in the database schema, not by a paragraph in the terms - writing without stripping is impossible, not merely forbidden.
04
The default state is the safe one
A missing secret closes the entrance rather than opening it. A missing source key yields sample data rather than real data. Without production mode, nothing goes out at all. A configuration mistake ends in silence, not in a leak.
05
Every action is written to the log
Who, when, at whose request and with what result - including whether the message actually went out. The log has its own retention period, and it cannot be shortened from an organisation’s settings.
06
Data comes in by the official route only
We read public registers only through their APIs, never by scraping pages. A source with no legal basis does not get through our technical gate, so it cannot be added "just for a moment".
Certifications, hosting regions and encryption claims are deliberately absent from this page. They go up here together with the document that backs them.
QUESTIONS
What comes up on the first technical call
Six questions we hear before anyone asks about price.
No. Omnira reads from the systems you already have and writes the result back to them. A migration would swap one island of data for another - and that is precisely the problem we are here to solve.
Then it is a custom connector, or a way in through the database or an export folder. That is the more expensive route and we say so plainly in the quote, because it has to be written and then maintained along with the rest of the installation.
That is a setting, not a property of the product. The same recommendation can end as a suggestion, as a request for approval, or as a process that has already run. You set the line and we write it into the rules, not into an email.
The people you grant access to, and nobody else. Different clients’ data is separated by rules in the database itself, not by a condition in the code. Our access to a rollout is a separate path, and it is written to the log.
A system with an API and documentation is usually a matter of days. A system without an API, or with an unusual data model, is weeks, because the connection has to be written and tested. Once we have the list of systems we give this per system, not as one number.
Your operational data in Omnira is deleted, and whatever Omnira wrote back into your systems stays with you - because from the outset it sits on your side of the boundary.
Want to see this diagram drawn over your own systems?
Show us the list of tools you use. After the first call it is usually clear which way in is shortest and which process is worth starting with.
