Architecture overview
mDecide is delivered as a managed service, one deployment per customer. This page describes the shape of that deployment — what runs where, what is dedicated to you, and where the boundary sits between what metricsIQ operates and what you use. It stays at the altitude an evaluating architect needs; the control details behind it are covered in Trust and security.
Your own instance
Every customer engagement runs on its own mDecide instance. An instance is a complete system — application, data store, message broker, and agent runtime — deployed into a dedicated cloud account allocated to your organization. Instances are not carved out of a shared pool of application servers or a shared database.
| Dimension | How it works |
|---|---|
| Tenancy | Single-tenant. One instance per customer engagement. |
| Cloud | Amazon Web Services. |
| Account | A dedicated AWS account is allocated to your organization, which gives account-level separation of billing and blast radius. |
| Region | Selected per customer, so data and compute can sit in a region appropriate to your organization. |
| Availability zones | Two zones within the selected region. |
| Access | Over HTTPS, at a hostname dedicated to your instance. |
| Operated by | metricsIQ. You do not provision or manage cloud accounts, containers, databases, or network configuration. |
Where an engagement wants separate environments — for example, a place to try configuration changes before they reach the people making real decisions — each environment is its own instance with its own data, deployed the same way.
What runs inside an instance
An instance is organized into three layers. The split matters to an evaluator for one reason above all: the agents that do the work of a decision cycle run in a container that is created for that cycle and torn down after it, separate from the system of record.
| Layer | What it is | What it holds |
|---|---|---|
| Control plane | The service that orchestrates decision work: it holds the definitions of what should happen, starts and supervises executions, and records what happened. | Your decision records, workstream and agent definitions, messages, and the platform API. |
| Execution runtime | An isolated container started for each execution and stopped when it finishes. Agents, their tools, and their working files live here for the duration of the run. | Transient working state for a single execution. |
| Frontend | The web application your people use. It presents both a per-decision working surface and a portfolio view across decisions. | Nothing persistent; it reads and writes through the control plane’s API. |
Runs are not long-lived shared workers. One execution gets one runtime container, which is why the work of one decision cannot read the working files of another.
Agent reasoning uses foundation-model APIs reached from your instance. Which model provider is used is set during scoping and recorded in your engagement statement of work, along with the boundary of what content is sent to it. The data handling section describes that boundary.
How traffic reaches your instance
The network inside an instance is tiered. Public-facing load balancing sits in one tier, application and runtime containers in a private tier with no inbound route from the internet, and the application database in an isolated tier with no internet route at all. Outbound traffic from application services leaves through a controlled egress path.
Ingress is HTTPS only. Certificates are managed by metricsIQ, HTTP is redirected to HTTPS, and HTTP Strict Transport Security is set.
How your network reaches the instance is a choice made during scoping: either over the public internet, or over a dedicated private link from your own estate into the instance’s network. Transport layer security applies on both paths — a private link is a connectivity and bandwidth decision, not a substitute for encryption in transit.
What is dedicated, and what is not
Single-tenant is a claim about the boundary, so it is worth being precise about where the boundary falls.
| Dedicated to your instance | Shared across metricsIQ customers |
|---|---|
| Cloud account | The container images the platform runs from. Your configuration and your data are not in the images. |
| Application database. Your data is never co-located in a database serving another customer. | The engineering team that operates instances, and the operator access paths they use. |
| Application and runtime containers | The release pipeline that builds and publishes platform versions. |
| Message broker and its persistence | |
| Secrets and credentials | |
| Hostname and internal service discovery | |
| Log streams |
The consequence of the right-hand column is that metricsIQ operators can administer any instance as part of routine operation, incident response, and recovery. That access is deliberate and it is governed; the controls on it are described in Trust and security.
Why single-tenant
Running a separate deployment per customer costs more to operate than a shared multi-tenant service. mDecide is built that way anyway, for four reasons that matter to the kind of decision the platform is used for.
- Data isolation. Decision-making in regulated industries — energy, pharmaceuticals, finance — routinely involves classes of data that cannot sit on shared infrastructure.
- Performance isolation. A decision cycle should not slow down because another organization is running a heavy workload. Capacity decisions are made per instance.
- Bounded compliance scope. Your instance is the audit boundary, which makes assessments tractable for both sides.
- Region choice. Because the deployment is yours, its region can be chosen to suit your data residency preference rather than a vendor’s default.
Where to go next
- Trust and security — compliance posture, data handling, access control, and the shared responsibility split.
- Adopting mDecide — what standing up an instance looks like from your side.
- Core concepts — the vocabulary used above: decisions, decision value loops, packs, agents, and runtimes.