The questions your IT manager would ask, with the answers.
Before a company's data goes into a new service, someone has to check where it ends up, who can see it and what happens when something goes wrong. Here are the answers, stated plainly.
- Where
- AWS, Milan region
- Engine
- Built on ClickHouse, one database per company
- Sign-in
- Two-step verification and passkeys
Where the data lives
Muvia is a cloud service. Each company's data is kept apart from everyone else's, down to the engine.
- Infrastructure
- Muvia runs on Amazon Web Services in the Milan region (eu-south-1) and is offered as a cloud service.
- Separation between companies
- In the analytics engine, built on ClickHouse, every company has its own database and its own credentials.
- Users' SQL
- Queries written by users run on a read-only login that can only read (SELECT): they cannot change or delete data.
- Connected databases
- Tables from your databases are copied into Muvia over an encrypted (TLS) connection, on a schedule. Muvia does not query your database every time someone asks a question.
- Connection user
- To connect a database we recommend creating a dedicated read-only user: Muvia only needs to read.
Who gets in
A password on its own is not enough. Muvia offers several ways to confirm who is signing in, and each company decides how strict to be.
Email code
A one-time code sent to the user's address at sign-in.
Authenticator apps
TOTP codes from an app like the ones your colleagues already use for other services.
Passkeys
Sign in with the key stored on the device, with no codes to copy.
Recovery codes
A way back in when a phone is lost, without opening an unlock request.
Trusted devices
A device that has already been verified can be remembered, so the check doesn't repeat at every sign-in.
A policy per company
Each company sets its own two-step verification policy for its users.
Who can do what
Everyone sees and changes what their job needs, and nothing more.
- Custom roles and permissions
- Create the roles your organisation needs and decide, permission by permission, what they can read and change.
- Teams
- Group people into teams and manage access per group instead of user by user.
- Support access on record
- When our support team signs in as a user to help them, the access is recorded.
What stays on record
When something changes, it must be possible to work out who did it and when.
- Activity log
- User actions are written to an activity log.
- Nightly seal
- Every night the log is sealed. If anyone later altered an entry that was already sealed, the change would be detectable.
AI and data: your call
The AI assistant is useful, but it should never arrive in a company unannounced. That is why it only works if you switch it on.
How the AI assistant works- Modules you switch on
- Each AI feature is a separate module. The company chooses which ones to turn on; the ones left off are not used.
- Models from external providers
- The AI features rely on language models from third-party providers. It's something to know before turning them on, and we would rather tell you ourselves.
Safe trial runs
The Python functions in flows can be tried in a test mode before they go into production. A test run touches nothing real.
- Databases
- No writes
- Machines
- No commands to PLCs
- Nothing sent
The effects of a test run are recorded, not carried out: you see what would have happened without it happening.
Bring us a question you can't answer today.
We start from a real question your business has and walk the path from source to dashboard with your systems, not a demo dataset.