Technical Book a demo
technical overview

How masterVantage is built, deployed and operated

Written for whoever has been asked to check the claims on the homepage before anyone signs anything. If a question here goes unanswered, put it to us and you will get a straight answer rather than a brochure.

Architecture

Classification services
The modules that connect to source systems, determine what each record contains, and route it onward. Each one runs in its own isolated container, so components can be upgraded independently and a fault in one does not spread. They hold no state.
Graph-based store
Classified data is held with its relationships and metadata, including source of origin and the confidence score assigned at classification. Because relationships are preserved, a change in what a consuming system asks for can be served from the store without re-reading or re-processing the source.
Mapping engine
Takes what a consuming system asks for and resolves it against what is already in the store. It works from what the data means rather than from field names, which is why a mapping survives a rename or a restructure on either side of it. It produces the mapping, the confidence attached to it, and the decision path written to the audit log.
Verification
Verification is not a stage at the end. It runs at every step — classification, storage and mapping — and each result is checked before anything downstream uses it. Anything below the confidence threshold you set is held for a person to approve rather than applied.

Connectivity

Connectivity is protocol-agnostic. How the data is reached has no bearing on how it is classified.

  • APIs — REST and SOAP.
  • Databases — conventional relational systems.
  • Files — flat files and file drops.
  • Applications — ERP, CRM and line-of-business systems reachable by any of the above.
  • Legacy and mainframe systems — reached through whatever they expose, usually an export or a database.

How a mapping is decided

The engine analyses the content and context of a data element, what it means, rather than its position or its name in the source schema. Each resulting mapping carries a confidence score.

  • At or above your threshold — the mapping is applied and the decision path is written to the audit log.
  • Below your threshold — the mapping is held and routed to a named human for approval. Nothing moves until it is approved.
  • On schema change — the changed element is re-interpreted, re-scored, and the same threshold logic applies. The pipeline does not halt while this happens.
  • Reversibility — every applied mapping is logged with its inputs, its score and its timestamp, and can be inspected or rolled back.

Deployment

Every module runs inside its own self-sufficient container, on the customer's infrastructure. A typical environment goes from initial connection to live operations in weeks. Integrations built after the platform is live take a working session.

  1. Provision the host environment. Linux virtual machines or bare metal meeting the specifications below, with Docker Engine and Docker Compose installed, or Kubernetes for larger deployments.
  2. Configure network and security. Secure paths between the hosts and both your source systems and the systems that will consume output. VPC peering, VPN or secured APIs.
  3. Pull the deployment packages. Distinct images for the classification services, the graph database and the routing services, from a secure enterprise registry using credentials issued to you.
  4. Initialise via Compose or manifest. Persistent volumes are mapped for graph data and hardware is allocated to the containers that need it, including GPU passthrough.
  5. Run the setup scripts. Finalise the deployment, run the first training sequence, and verify data flows end to end.

Before you begin: hosts meeting target-tier specifications, Docker Engine and Compose or Kubernetes, secured network paths to source and consuming systems, registry credentials, persistent storage volumes, and GPU drivers where required.

Infrastructure requirements

Graph traversals are fastest when the working set is in memory, and classification scales with available parallelism. Size for both.

baseline specifications by deployment tier
TierData volumeCPURAMGPUStorage
Starter / PoC< 500 GB8–16 cores32–64 GB1× NVIDIA 8 GB (optional)NVMe SSD
Enterprise1–5 TB32–64 cores128–256 GB1× NVIDIA T4 or A10GNVMe SSD
High volume5–10+ TB64+ cores512 GB+2× NVIDIA A100 / H100Enterprise NVMe SAN

Size RAM first, so the most heavily queried portion of the graph sits in the database page cache. Add CPU for concurrent integration throughput. Add GPU when classification of high-velocity streams becomes the bottleneck. At the Starter tier a GPU is optional and mainly accelerates initial training.

Scaling

Integration logic is decoupled from data storage, so the two layers scale independently and on different models.

Application layer — horizontal
The classification services are stateless. As throughput or queue depth rises, you add more identical containers. Capacity gains are close to linear because there is no shared-state coordination.
Database layer — vertical first
Scale up by adding memory until the graph, or its most queried portion, fits in the database page cache. This is where the query performance comes from, and it carries a single instance a long way. Always the first move.
Database layer — horizontal, if you license it
Clustering, read replicas and sharding across multiple graph nodes are capabilities of the enterprise edition of the database. The community edition that ships with the platform runs a single instance with cold backups, which is enough for most deployments. Decide which you need before you size the top tier, since the enterprise licence is yours to hold.

Data handling

  • No egress of customer data. The engine runs inside your perimeter. Nothing is transmitted to external model providers, and nothing is transmitted to masterVantage.
  • We hold no copy. Not of your data, your schemas, or your history. We have no access path into your deployment.
  • Operational independence. The engine does not require a call home to function. If masterVantage ceased to exist, your deployment would continue running.
  • Source code escrow. Available on request and written into the contract. On defined release events, insolvency being the obvious one, you receive the source code and can continue to run, maintain and develop the platform without us.
  • Isolation. Each agent runs in its own container. Compromise of one component does not grant access to others.
  • Audit. Every classification and transformation writes its decision path, inputs, confidence score and timestamp.

Models, and what they learn from

The classification models are delivered inside the container set and run on your hardware. There is no call to an external inference API, which is why there is no token bill and no egress.

  • Where inference happens. On your GPUs, inside your perimeter. Nothing is sent out for scoring.
  • The initial training sequence. Run once at deployment as part of the setup scripts, against your environment. Any artifact it produces stays on your infrastructure and is never transmitted to us.
  • Model updates. Shipped as new container images through the enterprise registry. Updating the engine does not require sending us anything.
  • Your data does not improve our product. We have no mechanism to collect it. This is architectural, not a policy we could quietly change.

What the graph store holds

This is a data protection question and your DPO will raise it, so here it is up front.

  • It persists classified data. Records and their relationships, with metadata including source of origin, the confidence score and the classification timestamp.
  • That means a second copy inside your estate. It sits on storage you own, on hosts you control, subject to your existing access controls, backup policy and retention rules.
  • Why it exists. When a consuming system changes what it asks for, the data can be re-routed from the store instead of re-reading and re-processing the source.
  • If personal data is in scope, treat the store as you would any other internal system holding it, and cover it in the same records of processing.

Licensing and third-party components

  • Everything ships as containers. The classification services, the graph database and the routing services are pulled from a secure enterprise registry using credentials issued to you.
  • No external service dependencies at runtime. No SaaS control plane, no licence server to phone home to, no external model API.
  • The graph database ships with the platform, on its community edition. It is fully licensed and fully usable as delivered, and carries no cost. Nothing about it is provisional.
  • The enterprise edition is an upgrade, not a migration. Moving up to it is done in place and without losing data. It adds high availability, clustering across multiple servers, online backup, and role-based access control with LDAP or Active Directory integration. That licence is between you and the database vendor and sits outside the masterVantage licence, so if you are running this in a regulated environment, price it into your plan.

Ask us these directly

The answers depend on your systems and your volumes, so anything general we wrote here would be close to useless. Put them to us in a session and an engineer will answer for your case.

  • Transformation beyond field matching. Type conversion, date and unit formats, concatenation and splitting, lookups and conditional logic. Real integrations are mostly transformation, and you should ask us exactly what is handled today.
  • How the confidence score is derived and how it is calibrated.
  • Environments and change control. How a mapping is promoted from test to production, and whether mapping definitions can be held in version control.
  • Operations. How approvals are surfaced, whether they integrate with your service desk, delegation by domain, and replay of failed records.
  • Throughput and latency under your specific volumes.

What masterVantage does not do

Worth being clear about, since these would come up during a pilot anyway.

  • It is not instant to stand up. The platform takes weeks to reach live operations. The speed claim applies to integrations built after that, not to day one.
  • It does not remove the human entirely. Genuinely ambiguous fields fall below threshold and wait for a person. That is the design, not a gap in it.
  • It is not a replacement for your ERP, CRM or data warehouse. It moves and harmonises data between systems you already own.
  • It needs hardware, and you pay for it. Memory in particular, and GPUs. There is no serverless option, because there is no cloud of ours for it to run in. Any infrastructure cost sits with you and is separate from the masterVantage licence.
  • It is not a like-for-like iPaaS replacement on day one. It deploys alongside your existing platform. Moving everything across is a decision you take later, if at all.
  • It is early. The product is in paid production use. It is not a decade-old platform with a thousand references, and we would rather you knew that now.

Ask us the question this page did not answer

Bring an integration you already know is painful and we will run it against your systems in a working session.

Book a demo